Legacy: что нужно знать о работе с чужим кодом
У вас бывало так, что вы смотрите на чужой код и не знаете, с чего начать? В этом лабиринте чужих решений не придет на помощь и нить Ариадны: полагайтесь только на свои силы. А мы подскажем 🙂
Пожалуй, первое правило звучит так:
«Если в коде что-то реализовано не так, как вы привыкли – это не значит, что оно реализовано неправильно.»
Каждый опытный программист найдет недостатки в чужом коде. Из этого может последовать решение переписать код «под себя», ведь можно сделать лучше. «Правильность» кода в этом случае понимается исключительно субъективно, исходя из собственного опыта.
Прежде чем приступить, подумайте, что вы пытаетесь сделать, и есть ли причины не делать этого. Используйте Итеративный подход, а главное помните: возможно, код, над которым вы работаете, написан командой в течение многих лет. Наверняка там исправлено много багов, и, скорее всего, это целостное решение, которое не пишется за неделю.
О рефакторинге есть не одна книга. Поэтому вторым советом будет обратиться к литературе, например, Working Effectively With Legacy Code.
Главная идея книги построена на тестах, которые помогают понять и улучшить систему. Книга организована по принципу «вопрос-ответ», помогает разобраться в сложном коде и решить проблемы.
Уважайте чужой труд
Есть очень важный момент – уважение к чужому коду и коллегам, работавшим до вас. Сложно быть эффективным без соблюдения этого правила.
Легко критиковать чужую систему, но от этого она не станет понятней. Поэтому при вхождении в новый проект приложите максимум усилий к пониманию внутреннего устройства и заложенных знаний. Вам помогут официальные или собственные юнит-тесты. Задокументируйте все, что слышите от людей, связанных с проектом, анализируйте ссылки и документацию проекта, сверяйте с собственными результатами. Фундаментальные знания помогут понять сложную систему.
Привыкните к тому, что люди редко жертвуют временем ради того, что уже работает, и предпочитают сосредоточиться на новых тасках. Но в legacy часто нужен человек, который способен внести ясность. Решение этой проблемы может не входить в прямые обязанности действующих или бывших сотрудников. Так что «новичку» приходится разбираться самому: разворачивать среду разработки, искать повторяющиеся конфигурации, процессы, улучшать виртуальную среду или контейнеры, подключать внешние службы к локальной среде или использовать заглушки, проводить тесты.
Изучение системы может забрать недели или месяцы. Но безрезультатным это не будет. В итоге вы узнаете систему, поймете процессы и всё задокументируете.
Работа с legacy-кодом открывает большие перспективы. И не спешите углубляться в критические проблемы, которыми озадачены другие люди. Очищайте и документируйте код. Помните, люди рассказывают гораздо больше о том, как работает код, когда критикуют, чем когда вы спрашиваете напрямую.
Кончено, не обойдется без собственных ошибок в процессе, поэтому придется часто начинать заново.
Учитывайте интересы бизнеса
Есть поставленные цели и задачи: их нельзя игнорировать. Учитывайте интересы бизнеса и вносите изменения, когда:
- приняты правила того, как никто не должен делать;
- есть негативное влияние на показатели бизнеса, такие как производительность, безопасность, etc.;
- текущая система мешает бизнесу выйти на новый левел.
Умение правильно определять решения – тоже навык. Поэтому вместе с утверждением, приведенным в начале, спросите себя:
«Открою ли я новую возможность, которая была нереализуема до этого, и принесет ли это пользу кому-то, кроме меня?»
Если нет уверенного «Да», отложите изменения. Улучшение одного или нескольких показателей стоит немалых усилий.
Проблема абстрагирования
Абстрагирование – это важный инструмент ООП наряду с полиморфизмом, наследованием и инкапсуляцией. Абстракция позволяет работать с объектами, не вдаваясь в подробности их реализации.
Но разработчики часто неверно полагают, что можно «спрятать» сложности кода за абстрактный слой. Это не так. Лучше мириться с явными сложностями существующей системы, чем выдумывать абстрактный уровень над этими сложностями.
Проблемы начинаются когда команда первых разработчиков становится недоступной. В этом случае невозможно овладеть теоретической базой в полной мере и, как следствие, выбрать правильные абстракции.
Правильный способ – упрощение существующего кода или рефакторинг.
Общайтесь
Да, бывает откровенно плохой код.
Но нужно сперва разобраться.
Общение – важный навык. Без него тяжко разобраться в сложной системе. Поэтому, прежде чем проводить рефакторинг и тесты, спросите других разработчиков:
- «Какой используется шаблон проектирования?»
- «Как производятся тесты?»
- «Каким образом разворачивается среда разработки?»
- «Как получить доступ к данным?»
- «Каким способом происходит миграция данных?»
- «Как обеспечивается масштабирование, параллелизм, безопасность, аутентификация?»
Если разработчики недоступны, ищите ответы в коде.
Столкнулись с незнакомым паттерном? Ищите информацию о странных на первый взгляд наименованиях, встречающихся в коде.
А еще помните, что разработчики часто копируют код из интернета, и реализовывают идеи, которые изучили недавно (все этим грешат, верно? 🙂 ). Для подозрительных отрывков кода используйте поисковики.
Следуйте сценарию использования для анализа уровней приложения с помощью debugger’а. Возьмите на заметку непонятные фрагменты и набросайте диаграмму архитектуры.
Что такое legacy code?
Не могу найти перевод. Можете объяснить в двух словах что это такое? Что за понятие?
Legacy code — тяжелая наследственность : ) Устаревший код, который более не поддерживается и не обновляется, но используется. Второе значение — код от сторонних разработчиков, или из старых версий.
Суммирорав все определения, которые встречались, для себя вывел следующее.
Legacy code — код, подпадающий под один или несколько признаков:
- написан другими разработчиками, возможно, уже недоступными для контакта;
- не покрыт юнит-тестами;
- сохранён для совместимости с предыдущими версиями системы;
- устарел и/или более не поддерживается в связи с развитием системы (написан на предыдущем языке, под старую архитектуру, аппаратную платформу, операционную систему и т.д.).
Требование «опыт работы с legacy кодом» в вакансии означает, что вам достанется код, написанный лет 10-20 назад давно уволившимися программистами. Не исключено, что он изначально был плохо написан, что требования к проекту менялись уже много раз и каждый раз код правился как придётся в режиме жёсткого дедлайна, что документацию никто не писал и рефакторинг не делал. Поэтому вместо того чтобы писать новый код на прогрессивных технологиях, вам большую часть времени придётся разбираться в старом и править его, ловя потом каскады багов. Добро пожаловать в чудесный мир кровавого энтерпрайза, основного потребителя Java.
@sergiks все написал верно, но все таки уточню: вообще термин Legacy в программировании означает прилагательное означающее принадлежность к традиционному. Скажем, Legacy Driver — означает драйвер от производителя и т.д.
Ещё бывает "доставшийся по наследству legacy code", который никто не знает как работает. Только программист здесь вряд ли поможет — здесь нужен либо аналитик, либо data scientist, а программист максимум, что сможет, это интерфейс для них написать, если его там нету,
т. е. вывести на форму то, что возможно, из того, что есть в коде.
Всё ещё ищете ответ? Посмотрите другие вопросы с метками терминология или задайте свой вопрос.
Site design / logo © 2022 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2022.6.10.42345
Нажимая «Принять все файлы cookie», вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Кофе-брейк #20. Что такое legacy-код и как с ним работать. Инструменты, которые облегчают написание технической документации
Источник: Dou Рано и поздно программисту наверняка придется встретиться с legacy-кодом. Чтобы облегчить последствия этого знакомства, я подобрал несколько практических советов и примеров из собственного опыта — в частности, работы с унаследованной Java-системой.
Особенности legacy
- с устаревшей технологией;
- неоднородной архитектурой;
- недостатком или даже полным отсутствием документации.
Мы не можем неуважительно относиться к системе, которая зарабатывает миллионы, или к которой обращаются тысячи людей в день. Как бы плохо она ни была написана, этот отвратительный код дожил до продакшена и работает в режиме 24/7.
Раз эта система приносит реальные деньги, работа с ней сопряжена с большой ответственностью. Это не стартап в стол, а то, с чем пользователи будут работать уже завтра. Это подразумевает и очень высокую цену ошибки, причем дело здесь не в претензиях клиента, а в реальном положении вещей.
Обратный инжиниринг
Не переписывайте код
Соблюдайте бизнес-интересы
Тестируйте
- Верификация, когда реализованный функционал фичи проверяется в отдельной ветке.
- Стабилизация, когда проверяется ветка релиза, в которой все фичи слиты вместе.
- Сертификация, когда все то же самое прогоняется еще раз на немного других тест-кейсах в сертификационном окружении, максимально приближенном к продакшену по характеристикам железа и конфигурации.
Формализуйте DevOps и релиз
Контролируйте качество кода
Инструменты, которые облегчают написание технической документации
Источник: Dzone Большинство программистов не любят писать техническую документацию. Эксперт по психологии Джеральд Вайнберг даже назвал документацию «касторовым маслом программирования»: разработчики любят ее читать, но сами писать просто ненавидят. Отсутствие руководства или пустая дорожная карта приводят к нехватке информации о том, как работают различные части программного обеспечения. В конечном итоге это ухудшает восприятие ситуации конечными пользователями кода, поскольку при отсутствии документации они не могут полагаться на точность и полезность продукта. Чтобы программисту было легче сформировать у себя привычку писать документацию, я рекомендую обратить внимание на четыре отличных инструмента, доступных сейчас практически каждому.