Что такое legacy-код и как с ним работать
Источник: Dou Рано и поздно программисту наверняка придется встретиться с legacy-кодом. Чтобы облегчить последствия этого знакомства, я подобрал несколько практических советов и примеров из собственного опыта — в частности, работы с унаследованной Java-системой.
Особенности legacy
Legacy (наследство) — это чужой код, который часто бывает ужасен настолько, что оказывается вообще непонятно, как с ним работать. И если вам придется работать с legacy-системой, кроме старого кода вы также встретитесь:- с устаревшей технологией;
- неоднородной архитектурой;
- недостатком или даже полным отсутствием документации.
Мы не можем неуважительно относиться к системе, которая зарабатывает миллионы, или к которой обращаются тысячи людей в день. Как бы плохо она ни была написана, этот отвратительный код дожил до продакшена и работает в режиме 24/7.
Раз эта система приносит реальные деньги, работа с ней сопряжена с большой ответственностью. Это не стартап в стол, а то, с чем пользователи будут работать уже завтра. Это подразумевает и очень высокую цену ошибки, причем дело здесь не в претензиях клиента, а в реальном положении вещей.
Обратный инжиниринг
Для успешной работы с legacy-кодом придется пользоваться приемами reverse engineering. Для начала, нужно внимательно читать код, чтобы точно понимать, как именно он работает. Это обязательно, ведь документации у нас, скорее всего, не будет. Если мы не поймем хода мыслей автора, будем делать изменения с непредсказуемыми последствиями. Чтобы обезопасить себя от этого, нужно вникать еще и в смежный код. И при этом двигаться не только вширь, но и вглубь. Откуда вызывается метод с ошибкой? Откуда вызывается вызывающий его код? В legacy-проекте «call hierarchy» и «type hierarchy» используется чаще, чем что-либо еще. Придется провести много времени с отладчиком: во-первых, чтобы находить ошибки, и, во-вторых, чтобы понять, как все работает. Что касается документации, не лишним будет прибегнуть к промышленной археологии. Очень полезно бывает откопать где-нибудь старую документацию и поговорить с теми, кто помнит, как писался доставшийся вам код. Используя эти приемы, рано или поздно вы начнете более или менее понимать код. Но чтобы ваши усилия не пошли прахом, вы должны обязательно сразу же документировать результаты своих изысканий. Для этого я советую рисовать блок-схемы или диаграммы последовательности (sequence diagrams). Конечно, вам будет лень, но делать это точно нужно, иначе через полгода без документации вы сами в этом коде будете копаться как в первый раз.
Не переписывайте код
Самое важное в процессе разработки — вовремя бить себя по рукам и не пытаться переписать весь код заново. Прикиньте, сколько человеко-лет для этого потребуется. Вряд ли заказчик захочет потратить столько денег на переделывание того, что уже и так работает. Это касается не только системы в целом, но и любой ее части. Вам, конечно, могут дать неделю на то, чтобы во всем разобраться, и еще неделю на то, чтобы что-то исправить. Но вряд ли дадут два месяца на написание части системы заново. Вместо этого реализуйте новый функционал в том же стиле, в каком написан остальной код. Иными словами, если код старый, не стоит поддаваться соблазну использовать новые красивые технологии: такой код потом будет очень тяжело читать. Например, вы можете столкнуться с ситуацией, которая была у нас: часть системы написана на Spring MVC, а часть — на голых сервлетах. И если в части, написанной на сервлетах, нужно дописать еще что-то, то дописываем мы это так же — на сервлетах.Соблюдайте бизнес-интересы
Нужно помнить, что любые задачи обусловлены, прежде всего, ценностью для бизнеса. Если вы не докажете заказчику необходимость тех или иных изменений с точки зрения бизнеса, этих изменений не будет. А для того, чтобы убедить заказчика, вы должны попробовать встать на его место и понять его интересы. В частности, если вам хочется провести рефакторинг только потому, что код плохо читается, вам не дадут этого сделать, и с этим нужно смириться. Если совсем уж невмоготу, реорганизовывать код можно по-тихому и понемногу, размазывая работу по бизнес-тикетам. Либо убедить заказчика в том, что это, например, сократит время, необходимое для поиска ошибок, а значит, в конечном итоге сократит расходы.Тестируйте
Понятно, что тестирование необходимо в любом проекте. Но при работе с legacy-системами тестированию нужно уделять особое внимание еще и потому, что влияние вносимых изменений не всегда предсказуемо. Тестировщиков потребуется не меньше, чем разработчиков, в противном случае у вас должно быть все просто невероятно хорошо с автоматизацией. В нашем проекте тестирование состояло из следующих фаз:- Верификация, когда реализованный функционал фичи проверяется в отдельной ветке.
- Стабилизация, когда проверяется ветка релиза, в которой все фичи слиты вместе.
- Сертификация, когда все то же самое прогоняется еще раз на немного других тест-кейсах в сертификационном окружении, максимально приближенном к продакшену по характеристикам железа и конфигурации.
Формализуйте DevOps и релиз
Релизная процедура может быть, например, следующей. Когда заканчивается разработка и пройдены две или три фазы тестирования, мы пишем письмо DevOps-команде за 36 часов до предполагаемого времени релиза. После этого созваниваемся с девопсами и обсуждаем все изменения окружений (мы сообщаем им обо всех изменениях в БД и конфигурации). На каждое изменение у нас есть документ (тикет в Jira). Затем во время релиза все причастные к этому собираются вместе, и каждый говорит, что он сейчас делает: «Мы залили базу», «Мы перезапустили такие-то серверы», «Мы пошли прогонять регрессионные тесты в рабочем окружении». Если же что-то идет не так, запускается процедура отката релиза, точно описанная в изначальном документе на релиз — без такого документа мы обязательно что-нибудь забудем или напутаем.Контролируйте качество кода
И наконец, code review — практика, к которой прибегают почему-то далеко не во всех проектах. Очень хорошо, если каждая часть кода проверяется более чем одним человеком. Даже в очень сильной команде в процессе code review обязательно обнаруживаются какие-то косяки, а если смотрят несколько человек, количество выявленных косяков возрастает. Причем иногда самое страшное находит третий или четвертый ревьюер.Инструменты, которые облегчают написание технической документации
Источник: Dzone Большинство программистов не любят писать техническую документацию. Эксперт по психологии Джеральд Вайнберг даже назвал документацию «касторовым маслом программирования»: разработчики любят ее читать, но сами писать просто ненавидят.
Отсутствие руководства или пустая дорожная карта приводят к нехватке информации о том, как работают различные части программного обеспечения. В конечном итоге это ухудшает восприятие ситуации конечными пользователями кода, поскольку при отсутствии документации они не могут полагаться на точность и полезность продукта.
Чтобы программисту было легче сформировать у себя привычку писать документацию, я рекомендую обратить внимание на четыре отличных инструмента, доступных сейчас практически каждому.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ