Спойлер никак
Аксиома
Любой код, написанный любым разработчиком, станет чьим-то legacy
Поправка
При условии, что доживет до стадии рабочей системы
Дополнение
Иногда реализованные Вами решения станут Вашим legacy
Просто смиритесь: рано или поздно, всё, что Вы разрабатывали или еще разработаете – уйдет в утиль. Смена и обновление технологий, изменение бизнес-процессов, эволюция компаний, даже политическая обстановка (как мы видим в последние годы), всё это не оставит шанса любой Вашей разработке остаться чем-то большим, чем бэкапом на пыльном сервере.
Но это не освобождает нас от ответственного подхода при разработке. Попыток заложить еще в процессе поиска решения вещи, способные продлить жизнь системы. И в целом, ответ на вопрос
Как не породить жуткое legacy?
Лежит в той же плоскости, что и
Как сделать нормальную систему?
Набор пунктов решения задачи известен давно, и я, конечно, тоже повторю его чуть позже со своими комментариями. Но. Учитывайте, что за пределами мира крупных компаний, стримов, каналов и конференций у Вас часто не будет хватать ресурсов
👉финансов
👉времени
👉компетенций
чтобы реализовать все это. Из первого ограничения вытекают два последующих. С этим тоже надо смириться.
Ну а теперь давайте формализуем требования
👉Документация. В любом виде: БТ, ФТ, ТЗ, переписки, записи встреч, база знаний, комментарии в коде, задачи в джире, планы в конфлюенс – всё, что спустя время поможет ответить на вопросы: кто, когда и нахуя затребовал/сделал очередную фичу
👉Соглашения при разработке. Главное не доводите до абсурда и не регламентируйте количество пробелов в комментариях между номером задачи и тем, кто ее сделал
👉Рефакторинг и код-ревью. Регулярные. Чем чаще, тем лучше. Помогает отследить неоптимальные во всех смыслах решения и поддерживать целостность.
👉Грамотные решения при проектировании и разработке. Выделять что-то отдельное смысла нет, а говорить обо всем – начинать отдельную серию постов. Все то, что люди понимают, говоря слова «чистый код» и «чистая архитектура»
👉Тестирование. В идеале – автоматическое. Как минимум – ответственное.
👉Возводите критические точки в абсолют. Везде, где это возможно. Если по ТЗ надо проверить 5 независимых свойств, прикиньте, как выбранное Вами решение будет выглядеть, если свойств станет 50. А как, если часть из свойств будет зависеть от других свойств? Вместо «ну не будет же пользователь творить лютую нелогичную херню» считайте, что он начнет делать её сразу, как получит доступ к фиче. И так далее.
Ну вот вроде основное, что стоит делать. Но если у Вас не получается делать всё и сразу, начните хоть с чего-то – и Вы заметите, что жить стало чуть-чуть легче.
Еще есть один пункт, который точно делать не стоит: замыкать какую-то часть решения на одного специально обученного человека. В таком случае, особенно при невыполнении некоторых пунктов из списка «стоит», есть риск получить на самом деле незаменимого человека.
Так что следуйте логике, отжимайте ресурсы на полезные штуки – и будет Вам счастье в виде долгоиграющей системы.
#медведьразмышляет #legacy