Если вам повезет, у вас будет документация или, по крайней мере, встроенные комментарии. Может быть, один или два из первоначальных авторов все еще будут рядом, чтобы помочь. Но в большинстве случаев вам не повезет.
Давай поговорим о том, что ты собираешься делать в таких неудачных случаях.
Во-первых, вам нужно быть скромным. Уважайте код и разработчиков, которые его написали.
Легко взглянуть на предыдущую работу и решить, что она бесполезна и что вы можете сделать лучше. Это неправильное отношение. Это приведет вас по очень опасному пути.
Если вы пойдете по этому опасному пути, вы начнете вносить изменения, прежде чем должным образом осознаете влияние этих изменений. Вы будете «исправлять» то, что не сломано, потому что они написаны в стиле, который вам не нравится, или основаны на старых способах ведения дел. В конце концов, с таким отношением вы потратите невероятное количество времени.
Так что хватит. Сделайте шаг назад и поймите, что все в этой кодовой базе было сделано определенным образом по определенной причине.
Пока вы не знаете код вперед и назад, вы должны предположить, что были веские причины для того, чтобы он был написан таким, как он есть, и что вы просто еще не поняли их.
Это гораздо более продуктивный подход, и он избавит вас от того, чтобы все сломать, а затем просто захотеть выпрыгнуть из окна, когда вы не можете собрать все вместе достаточно быстро.
Не забивай свою кодовую базу Шалтай-Болтай.
Лучший способ, который я нашел для изучения кодовой базы, - это начать с уровня пользовательского интерфейса, а затем вернуться в код.
Выберите один пользовательский поток, например, вход в систему, размещение заказа, написание обзора или что-то еще, что имеет отношение к вашему конкретному приложению. Пройдите через поток как конечный пользователь. Затем посмотрите на код, начиная с кода пользовательского интерфейса - его должно быть легче всего распознать - и выполните каждый шаг назад, вплоть до базы данных.
По мере продвижения нарисуйте диаграмму последовательности, чтобы проиллюстрировать, что происходит. Если вы не знаете, что такое диаграмма последовательности или как ее нарисовать, ознакомьтесь с этим бесплатным руководством. Если у вас нет хорошего инструмента для рисования UML, вот вам бесплатный.
После того, как вы закончите свою первую диаграмму последовательности, используя локальную копию кодовой базы, которую вы можете легко восстановить, начните вносить небольшие изменения в некоторые из компонентов, с которыми вы столкнулись. Посмотрите, сможете ли вы предсказать влияние ваших изменений на приложение. Это хороший способ проверить свое понимание.
Продолжайте повторять этот процесс, добавляя к своим диаграммам, пока у вас не будет полной картины всего приложения (или, по крайней мере, всех частей, за которые вы несете ответственность).
Чтобы получить бонусные баллы, не забудьте поделиться своими заметками и диаграммами. Поместите их на видное место, где следующий разработчик сможет их легко обнаружить. Не беспокойтесь о том, чтобы сделать их идеальными или даже красивыми. Просто делай, что можешь. Любая мелочь помогает.
В целом, самое главное - набраться терпения и не избивать себя. Код - вещь сложная. Чтобы понять устаревший код, нужно время. Успокойся.
Как исправить устаревший код
Самая большая проблема, с которой вы столкнетесь при исправлении устаревшего кода, - это решить, как далеко зайти с исправлением. Я настоятельно рекомендую вам сначала внести минимально возможное изменение. Это означает, что перед попыткой очистки и рефакторинга какого-либо кода вам следует внести наименее разрушительные изменения, которые полностью устранят проблему.
Это дает вам аварийный выход. В худшем случае, если вас отвлекут, чтобы заняться каким-то другим приоритетом - или если у вас очень сжатые сроки, - по крайней мере, вы соберете рабочий код, на который сможете вернуться.
После того, как ваш код заработает, если у вас еще есть время, вы можете приступить к небольшим, постепенным улучшениям.
Мартин Фаулер составил каталог рефакторингов, который даст вам хорошее представление о типах изменений, которые вы можете внести для постепенного улучшения кодовой базы. Посмотрите здесь. Идея состоит в том, чтобы всегда оставлять код в лучшей форме, чем когда вы его нашли.
Иногда вы сталкиваетесь с ошибкой, которая на самом деле является результатом структурного дефекта. Эти ошибки нельзя исправить простым изменением условной логики. Они требуют более инвазивных изменений.
Вот где все становится волосатым. Вы должны быть предельно честны с самим собой в отношении минимального жизнеспособного изменения. Каждая фибра вашего существа захочет разобрать код и переписать все заново. Не делай этого!
Придерживайтесь быстрого исправления, за которым следует постепенное улучшение, которое реорганизует его и очищает настолько, насколько позволяет время. Ваша цель - каждый раз делать код немного лучше. Чем дольше вы будете поддерживать кодовую базу, тем лучше она станет.
Чтобы этот подход действительно работал, убедитесь, что вы всегда дополняете свои оценки, чтобы было время для небольшого рефакторинга.
Иногда структурные дефекты настолько серьезны, что стратегия постоянного исправления просто не работает. На самом деле такая ситуация встречается гораздо реже, чем вы думаете.
Опять же, вы должны быть предельно честны с самим собой в отношении затрат / выгод переписывания или редизайна. Вы должны принять тот факт, что в конечном итоге это будет бизнес-решение, а не техническое.
Приготовьтесь изложить свою позицию в деловых терминах. Сколько будет стоить серьезная реструктуризация кода? Каковы реальные риски для бизнеса, если этого не сделать? Если у вас есть надежное дело, вас рано или поздно услышат. Однако не удивляйтесь, если сначала потребуется еще несколько циклов установки исправлений.
Помните: если вы проводите капитальный ремонт, сначала убедитесь, что изменение поддерживается и есть разумный бюджет. Не пытайтесь оставаться незамеченными с этим. Если, конечно, вы не наслаждаетесь неловкими разговорами с руководством, когда начинаете ломать дела и срывать сроки.
Как добавить новые функции в устаревший код
Наконец, в конечном итоге вас попросят добавить функции в унаследованный код. На этом этапе вам нужно принять важное решение. Вы «плывете по течению» текущей кодовой базы или идете в новом направлении?
Опять же, я советую вам быть предельно честным в оценке. Будет ли дальнейшее следование шаблонам и практикам, очевидным в существующей кодовой базе, усугубить ситуацию или накапливать существующую проблему?
В большинстве случаев вам нужно, чтобы все было стабильно. Просто делайте инкрементальные дополнения, используя существующие шаблоны и практики кода. Повторно используйте существующие элементы. Сделайте как можно менее разрушительные изменения, внося при этом небольшие, постепенные улучшения путем очистки и рефакторинга.
Если вы считаете, что новое направление абсолютно необходимо, вам нужно будет найти способ изолировать свои изменения и как можно более свободно связать их с существующей кодовой базой.
Попробуйте выделить новую функцию в отдельный проект. Затем вы можете предоставить API, который позволяет устаревшему коду подключаться к вашему новому коду. Благодаря этому вашему новому и старому унаследованному коду не нужно много знать друг о друге.
Это начинает становиться немного сложнее, когда вам нужно использовать функциональность из унаследованного кода для реализации новой функции. Лучший способ изолировать старый код от нового - использовать шаблон адаптера.
В DO Factory есть хорошее объяснение паттерна адаптера:
«Шаблон адаптера переводит один интерфейс (свойства и методы объекта) в другой. Адаптеры позволяют программным компонентам работать вместе, чего в противном случае не было бы из-за несовпадения интерфейсов. Шаблон адаптера также называется шаблоном оболочки.
Один из сценариев, в котором обычно используются адаптеры, - это когда новые компоненты необходимо интегрировать и работать вместе с существующими компонентами в приложении.
Другой сценарий - рефакторинг, при котором части программы переписываются с улучшенным интерфейсом, но старый код по-прежнему ожидает исходного интерфейса ».
Вот несколько ссылок на объяснения и примеры на разных языках.
Ключевые выводы
Таким образом, вот ключевые моменты, которые помогут вам справиться с любой кодовой базой и в конечном итоге победить ее:
- Никогда не осуждайте устаревший код и не меняйте его, пока не найдете время, чтобы полностью его понять.
- Диаграммы последовательности - ваш друг.
- Предпочитайте небольшие постепенные улучшения массовым переписыванию или изменениям.
- Каждое изменение должно пытаться сделать код немного лучше, чем когда вы его нашли.
- Если вам нужно внести большие изменения, сначала составьте экономическое обоснование и получите одобрение.
- Добавляя новые функции, старайтесь «плыть по течению».
- Если вам нужно направить код в новом направлении, изолируйте свои изменения и используйте шаблон адаптера для интеграции.
Надеюсь, вы нашли эту статью полезной. Моя миссия - помочь как можно большему количеству разработчиков. Пожалуйста, порекомендуйте ❤ эту историю, используя зеленое сердце ниже, чтобы помочь распространить информацию.
Хотите лучше писать код? Присоединяйтесь к тысячам разработчиков, которые каждую неделю получают от меня ценные статьи и информацию бесплатно. Просто щелкните здесь.
