JAVASCRIPT
Как исправить устаревший монолит JavaScript?
5 шагов, чтобы разгадать запутанный, спагетти и дерзкий код болоньезе
Слова «унаследованный код» часто вызывают в воображении образ какой-то древней реликвии из прошлых времен, когда разработка программного обеспечения жила в виде водопадов, неуклюжих интерфейсов на основе Java и странных творений, которые шепчут Я стар и пронизан уязвимостями безопасности .
React, Angular, Vue и Node.js должны быть молодыми, крутыми и модными вещами, которые должны спасти нас от всего этого. Стартапы используют его слева, справа и по центру. В настоящее время на JavaScript строятся целые предприятия - интерфейс, бэкэнд и вплоть до оркестровки облачной инфраструктуры.
Но в том-то и дело - это JavaScript, а JavaScript существует достаточно долго, чтобы накопить серьезное наследие, которое проще отбросить и начать заново, чем пытаться спасти. Однако это легче сказать, чем сделать. Представьте, что вы подойдете к своему боссу и скажете ему правду - что парень, которому он платил более 100 тысяч долларов в год в течение последних трех лет, построил ему чушь, и что вам нужно начать все сначала. На самом деле вы говорите ему, что его вложения в 300 тысяч долларов бесполезны. Если он заплатил нескольким из них, чтобы они составили команду, то это как минимум миллион или два на ветер.
Начальнику - все работает. Они знают, что он работает, и задача разработчика - сделать все необходимое, чтобы оно продолжало работать. Его не волнует внутренняя работа, чистая архитектура кода, низкая взаимосвязь, модульность, реализация шаблонов - для него все это чепуха. Босс заботится о том, чтобы он мог продолжать вести свой бизнес.
Короче говоря, вы каким-то образом унаследовали наследство - иногда рожденное из-за недостатка навыков или общего понимания того, как на самом деле работает JavaScript. Может быть, парень до того, как ты получил код от кого-то другого. Кто знает, что на самом деле происходит с тем, как все закончилось так, как они были, - только то, что теперь это в ваших руках.
Вы смотрите на него и обнаруживаете, что это чудовищный монолит со сковывающим уровнем жесткой связи, странным синтаксисом и вложенными циклами. Ситуация похожа на спагетти и болоньезе, и нет никакого способа не запутаться, если вы начнете прыгать - или есть?
Вот пять шагов, чтобы исправить устаревший монолит JavaScript.
Шаг 1. Возьмите щипцы и переложите все в миску.
Одна вещь, которую я узнал об устаревшем коде, заключается в том, что иногда нет никакой надежды на его спасение. Скорее всего, вы потратите больше времени, пытаясь разгадать его тайны, чем на самом деле пытаясь найти решение, которое работает.
Иногда нужно просто признать, что проделанная работа - это невозвратные затраты. Руководителям проектов бывает сложно продать это своему боссу. Есть шанс, что они эмоционально привязаны к этому, потому что именно они подписываются на системы, которые оказались плохими лимонами.
По опыту, уловка состоит не в том, чтобы подчеркнуть, насколько плоха реальность на самом деле, а в том, чтобы продать то, что вы собираетесь делать дальше, как обновленную версию. Вы по-прежнему собираетесь использовать старую систему, но превратите ее во что-то, что в конечном итоге принесет им больше денег. Как? Потому что скорость разработки будет выше, вместе с удобством доставки и меньшим количеством ошибок.
На самом деле вы собираетесь отделить весь старый код от всего старого и работать над планом параллельной разработки, чтобы весь бизнес не остановился. Вы по-прежнему можете вносить «улучшения» и выпускать новые функции, но также находите время для восстановления старых компонентов в соответствии со стандартом, который вам нужен, вместо того, чтобы заставлять себя работать с тем, что у вас есть.
Шаг 2: используйте кольцевое ограждение
Прелесть JavaScript в том, что существует множество фреймворков, библиотек и модулей, направленных на то, чтобы упростить и ускорить жизнь разработчиков. Используйте их. Используйте их как строительные блоки лего, но убедитесь, что вы четко представляете свой стек технологий. не смешивайте и не сопоставляйте внешние и внутренние интерфейсы. Придерживайтесь пары вещей, которые ваша команда действительно понимает.
За прошедшие годы я обнаружил, что есть уловка, позволяющая превратить устаревшую холодную работу в проекты, и заключающуюся в том, чтобы использовать шаблоны мост и адаптер везде, где только можно, когда мало времени. Когда что-то нужно доставить, вам просто нужно подключить старый код и довольствоваться тем, что у вас есть.
Основным преимуществом использования этих двух шаблонов является то, что они помогают создать защитную ограду вокруг кода, который вы хотите поэтапно исключить, в то же время позволяя вам двигаться вперед чисто и продуктивно. Это также позволяет вам создавать слои кода и четко отмечать, какие части являются старыми, новыми и функциями, которые уходят из унаследованных.
Когда вы действительно смотрите на приложение, оно состоит из нескольких слоев. Даже внутри вашего спагетти-кода есть функции и элементы, которые вписываются в эти слои. Самый простой способ оказать влияние - это продвигаться вниз по уровням, начиная с представлений для внешнего интерфейса и API и возвращаемых структур данных для внутреннего интерфейса. Например, при переходе к веб-интерфейсу вы можете просто сначала разобраться со своими представлениями. Это означает, что вы соединяете и адаптируете свои логические уровни (которые уже каким-то образом связаны с уровнем данных) с вашими новыми представлениями.
Как только часть этого будет завершена, вы можете работать над переносом данных и логических слоев. За это время, поскольку у вас есть отсортированный один слой, ваша способность быстро вносить изменения возрастает, и вы можете адаптировать самый верхний слой к своим потребностям.
Шаг 3: убедите начальника, что вы добиваетесь прогресса
В зависимости от того, насколько плоская ваша организация, ваш босс может быть фактическим владельцем бизнеса или вашим ведущим менеджером по продукту. Кто бы это ни был, есть шанс, что они не настолько в технических вопросах.
Уловка состоит в том, чтобы сосредоточиться на положительных моментах. Не лгите им прямо. Вы знаете, что код спагетти плохой, но им не нужно знать, насколько плохой. Это скорее игра в жанре офисной политики, в которой вам нужна тактика и способность видеть вещи с их точки зрения. Помните, что деньги, потраченные на найм разработчиков, - это невозвратные затраты. Вы не хотите, чтобы случайно изобразили себя следующей невозвратной ценой - из-за чего люди могут перестать относиться к вашей тяжелой работе и реальному прогрессу.
Этот шаг часто оставляют на усмотрение руководителей групп и владельцев продуктов. Однако время от времени вы можете встретить у власти нетехнических людей, которым просто нужны хорошие новости, а не очередной поток плохих. Вас нанимают в качестве разработчика для решения проблем, а не для того, чтобы переоценивать свои чувства по поводу них.
Шаг 4: аккуратно выведите старый код из эксплуатации
Основываясь на предыдущих шагах, первая задача включает в себя ограждение всего и завершение хотя бы одного слоя или хотя бы части одного слоя. Для приложений вы можете разбить стек на разные домены, что означает, что вы можете работать над его переходом по частям.
Вывод из эксплуатации старого кода - это процесс избавления от исходного кода. Одни называют это «рефакторингом», другие - «переписыванием». В любом случае вы получите новый код, который лучше подходит по шкале сплоченности и имеет гораздо более модульную структуру и дизайн. Эти черты часто практически отсутствуют в спагетти-коде.
Стоит отметить, что мосты и адаптеры, которые вы пишете, также со временем станут ненужными. Почему? Потому что они должны быть лишь временными приспособлениями кода, предназначенными для разделения вашей рабочей нагрузки, поэтому вам не нужно создавать все с нуля сразу. Использование мостов и адаптеров также может помочь прояснить предположения и создать точки обучения для вас и вашей команды по мере развития вашего проекта.
Шаг 5: переоцените свою ситуацию
да. В конце концов, вы, по сути, перестраиваете все приложение - только по частям. Именно это сделала PayPal в начале 2010-х, когда перешла на node.js.
Что вам нужно иметь в виду, так это то, что код имеет тенденцию стареть, как собачьи годы. По мере того, как вы приобретете больше опыта и поймете проект, вы начнете замечать трещины и складки в только что созданном коде. Не бойтесь их исправить или хотя бы запланировать их рефакторинги. Для этого не требуется наличие ошибки. Скорее, признание и принятие того, что вещи можно кодировать лучше. Легче обновлять и обновлять код, который еще свежий, чем код, который существует так давно, что на нем образовалась грязь из невыполненных работ.
Вывод
В какой-то момент вы создадите достаточно нового приложения, чтобы полностью отключить старое. Между тем, вы также добавляете новые функции и опережаете старое приложение по темпам доставки и количеству функций. Вот тогда вы знаете, что ваша работа по борьбе с монолитом-спагетти-монстром сделана.
Стоит отметить, что во время процессов перехода и разработки также должны быть внедрены практики и правила, чтобы этого больше не повторилось. Архитектура кода имеет значение и по умолчанию часто приводит к более чистому коду.
Более тонкие детали разгадки кода спагетти требуют более подробного обсуждения и содержат гораздо больше нюансов. Вот несколько статей, которые могут вам помочь:
Переосмысление разделения ответственности в React
Декларативное и императивное мышление в контексте JavaScript, простое объяснение
Модули в ваших JavaScript-проектах
В чем суть функционального JavaScript?
Спасибо, что прочитали, и я надеюсь, что вы нашли эту статью полезной.
