Legacy: что нужно знать о работе с чужим кодом
Доходчивый гайд по работе с legacy кодом, который раскроет тонкости взаимодействия с не всегда понятным плодом чужих рук.
Пожалуй, первое правило звучит так:
«Если в коде что-то реализовано не так, как вы привыкли – это не значит, что оно реализовано неправильно.»
Каждый опытный программист найдет недостатки в чужом коде. Из этого может последовать решение переписать код «под себя», ведь можно сделать лучше. «Правильность» кода в этом случае понимается исключительно субъективно, исходя из собственного опыта.
Прежде чем приступить, подумайте, что вы пытаетесь сделать, и есть ли причины не делать этого. Используйте Итеративный подход, а главное помните: возможно, код, над которым вы работаете, написан командой в течение многих лет. Наверняка там исправлено много багов, и, скорее всего, это целостное решение, которое не пишется за неделю.
О рефакторинге есть не одна книга. Поэтому вторым советом будет обратиться к литературе, например, Working Effectively With Legacy Code.
Главная идея книги построена на тестах, которые помогают понять и улучшить систему. Книга организована по принципу «вопрос-ответ», помогает разобраться в сложном коде и решить проблемы.
Уважайте чужой труд
Есть очень важный момент – уважение к чужому коду и коллегам, работавшим до вас. Сложно быть эффективным без соблюдения этого правила.
Легко критиковать чужую систему, но от этого она не станет понятней. Поэтому при вхождении в новый проект приложите максимум усилий к пониманию внутреннего устройства и заложенных знаний. Вам помогут официальные или собственные юнит-тесты. Задокументируйте все, что слышите от людей, связанных с проектом, анализируйте ссылки и документацию проекта, сверяйте с собственными результатами. Фундаментальные знания помогут понять сложную систему.
Привыкните к тому, что люди редко жертвуют временем ради того, что уже работает, и предпочитают сосредоточиться на новых тасках. Но в legacy часто нужен человек, который способен внести ясность. Решение этой проблемы может не входить в прямые обязанности действующих или бывших сотрудников. Так что «новичку» приходится разбираться самому: разворачивать среду разработки, искать повторяющиеся конфигурации, процессы, улучшать виртуальную среду или контейнеры, подключать внешние службы к локальной среде или использовать заглушки, проводить тесты.
Изучение системы может забрать недели или месяцы. Но безрезультатным это не будет. В итоге вы узнаете систему, поймете процессы и всё задокументируете.
Работа с legacy-кодом открывает большие перспективы. И не спешите углубляться в критические проблемы, которыми озадачены другие люди. Очищайте и документируйте код. Помните, люди рассказывают гораздо больше о том, как работает код, когда критикуют, чем когда вы спрашиваете напрямую.
Кончено, не обойдется без собственных ошибок в процессе, поэтому придется часто начинать заново.
Учитывайте интересы бизнеса
Есть поставленные цели и задачи: их нельзя игнорировать. Учитывайте интересы бизнеса и вносите изменения, когда:
- приняты правила того, как никто не должен делать;
- есть негативное влияние на показатели бизнеса, такие как производительность, безопасность, etc.;
- текущая система мешает бизнесу выйти на новый левел.
Умение правильно определять решения – тоже навык. Поэтому вместе с утверждением, приведенным в начале, спросите себя:
«Открою ли я новую возможность, которая была нереализуема до этого, и принесет ли это пользу кому-то, кроме меня?»
Если нет уверенного «Да», отложите изменения. Улучшение одного или нескольких показателей стоит немалых усилий.
Проблема абстрагирования
Абстрагирование – это важный инструмент ООП наряду с полиморфизмом, наследованием и инкапсуляцией. Абстракция позволяет работать с объектами, не вдаваясь в подробности их реализации.
Но разработчики часто неверно полагают, что можно «спрятать» сложности кода за абстрактный слой. Это не так. Лучше мириться с явными сложностями существующей системы, чем выдумывать абстрактный уровень над этими сложностями.
Проблемы начинаются когда команда первых разработчиков становится недоступной. В этом случае невозможно овладеть теоретической базой в полной мере и, как следствие, выбрать правильные абстракции.
Правильный способ – упрощение существующего кода или рефакторинг.
Общайтесь
Да, бывает откровенно плохой код.
Но нужно сперва разобраться.
Общение – важный навык. Без него тяжко разобраться в сложной системе. Поэтому, прежде чем проводить рефакторинг и тесты, спросите других разработчиков:
- «Какой используется шаблон проектирования?»
- «Как производятся тесты?»
- «Каким образом разворачивается среда разработки?»
- «Как получить доступ к данным?»
- «Каким способом происходит миграция данных?»
- «Как обеспечивается масштабирование, параллелизм, безопасность, аутентификация?»
Если разработчики недоступны, ищите ответы в коде.
Столкнулись с незнакомым паттерном? Ищите информацию о странных на первый взгляд наименованиях, встречающихся в коде.
А еще помните, что разработчики часто копируют код из интернета, и реализовывают идеи, которые изучили недавно (все этим грешат, верно? :) ). Для подозрительных отрывков кода используйте поисковики.
Следуйте сценарию использования для анализа уровней приложения с помощью debugger’а. Возьмите на заметку непонятные фрагменты и набросайте диаграмму архитектуры.
Читайте также:
- Налаживаем отладку или улучшаем свой скилл дебаггинга
- Отладка программы: 3 типа ошибок
- Хороший код: писать так, чтобы потом не было мучительно больно