Программисты не любят работать с legacy. Всё потому, что legacy-код сложен, он использует устаревшие технологии и требует особого обслуживания.
Legacy-кодом не рождаются, им становятся. По началу этот код мог использовать новейшие технологии и быструю разработку.
Но внезапно система устаревает, забывается и больше не поддерживается. В чём причина? Вот 9 причин, по которым ваш софт становится legacy.
1. CV вместо кода, как часть IT-карьеризма
IT-индустрия движется быстро, а компании требуют опыт работы с новейшими фреймворками, библиотеками и платформами. Зная это, многие разработчики включают в стек новые технологии для своего резюме.
Руководители проекта часто не догадываются об этом. Разработчики настаивают на использовании чего-то нового. Руководители проекта принимают и продвигают технологию, несмотря на то, что она задерживает проект и портит качество.
Некоторые разработчики рассматривают своё пребывание в компании как временное. Они обеспокоены последствиями выбора технологий меньше, чем следующим шагом в своей карьере.
Чтобы противодействовать этому феномену, руководство должно ставить чёткие, долгосрочные цели, подходить к выбору технологий внимательно и тщательно оценивать изменения в стеке, учитывая интересы компании.
2. Изучать новое – весело
Да, учиться весело. Но обучение само по себе не заработает вам денег, а это, согласитесь, не очень весело. Так почему бы не совместить приятное с полезным? Изучайте новое во время работы и делайте деньги. Не стесняйтесь учиться на работе – так делают многие разработчики.
Однако помните, что изучение нового ради «новизны» – очередная ошибка, ведущая к legacy.
Нововведения приводят софт к состоянию legacy потому, что в системе смешиваются разные подходы и увеличивается сложность. После введения новых вещей старые теряют актуальность. Количество старого кода постепенно увеличивается, и софт переходит в статус legacy.
Это двойной удар по бизнесу: разработчики учатся, вместо того чтобы работать, и создают нечто тяжело поддерживаемое вместо стабильного, цельного, долгосрочного ПО.
Для решения проблем разработки существуют готовые инструменты и техники. Другими словами, разработчикам нужно просто делать софт и смириться с отсутствием возможности изучать новое. Для этого компания не должна требовать от разработчиков изучения новых технологий.
В любом случае эти процессы запускает руководство, принимая взвешенные решения об изучении новых технологий в интересах компании. Так изучение становится частью стратегии и перестаёт быть проблемой.
При нововведениях руководству нужно всерьёз задуматься о рефакторинге старого кода. Если весь код обновлён в соответствии с новой технологией, сложность ПО можно держать под контролем.
3. Хайп
Возможно, кто-то удивится, но мода решает в IT многое. Нет, мы не имеем в виду одежду, а проводим аналогию. Дизайнеры сосредоточены на модной одежде с новым дизайном и сочетанием цветов. Желание отличиться и соответствовать некоторым идеалам двигают моду: наверняка вы не хотите носить одежду, которую носит ваш дед. Вместо этого вы бы предпочли стиль любимого актёра, стартапера или музыканта.
То же самое работает в IT. Разработчики отделяют себя от того, что «не стильно», и стараются соответствовать чему-то крутому. В результате появляются разные подходы к разработке без какой-либо объективной причины.
То, что сегодня кажется крутым и новым, завтра устареет. IT-индустрия известна своим быстрым движением. Чем быстрее разработчики осваивают хайп, тем быстрее они отказываются от него при появлении следующего. Некоторые программные системы – это просто музей прошедших трендов. И это характерная черта legacy.
Важно распознавать временные тенденции. Новую технологию нужно тщательно рассмотреть перед внедрением.
4. Преимущества нового и недостатки старого
После внедрения новых технологий недостатки старых видно отчётливо. Но нелегко увидеть проблемы новых технологий. Минусы часто проявляются только после долгих лет использования.
Сравнивая технологии, важно принять во внимание все аспекты. Это может быть тяжело, но сильные решения в отношении технологий защитят ваш софт от судьбы стать legacy.
5. Ненужные зависимости и слишком тесная связь
Повторное использование – это здорово. Во время жизненного цикла ПО происходит утилизация большого количества софта. В результате список зависимостей растёт благодаря таким пакетным менеджерам, как npm и maven.
Если зависимости выбраны невнимательно, они сами могут стать legacy, что в итоге сделает наследственной связанную с ними часть программы. Необязательные зависимости помогут избежать этой ситуации.
Ещё одна проблема – тесная связь, когда большая часть кода взаимодействует с зависимостями. Такая сильная интеграция говорит о том, что судьба конечного продукта находится в руках зависимостей. Зачастую эта связь неизбежна, попробуйте минимизировать её, чтобы софт не перешёл в категорию трудно поддерживаемых.
6. Излишняя сложность архитектуры
Архитектура ПО – это структура высокого уровня. Решения, принятые на этапе создания архитектуры, имеют сильные последствия. Типичный пример – программирование на разных языках. В современном веб-приложении могут использоваться 2-3 разных ЯП. При этом понятно, что от использования шести разных ЯП будет мало хорошего.
Если архитектура излишне сложна, новые разработчики сломают голову, работая над системой. Как итог – ухудшение качества кода.
Непонимание излишне сложной системы ведёт к игнорированию соответствующих особенностей архитектуры.
Максимально простая архитектура избавит вас от этих проблем.
7. Ненужные части языков программирования
Сообщество разработчиков всерьёз рассматривает идиоматический код. Так называют код, который широко использует особенности определённого языка. Принято считать, что идиоматический код легче писать без ошибок.
Но у такого кода есть недостатки. Первый – код навсегда привязан к определённому языку. Когда язык выходит из моды, код уходит в legacy. Менее идиоматический код легче переводить на другой ЯП просто потому, что в нём содержится больше общих конструкций иных языков.
Другая проблема в сложности. Современные языки на удивление сложны. Если вы ещё не ощутили это в своём проекте, посмотрите на сложные задачи и примеры.
Многие из нас знают гуру с 10+ годами опыта. Они знают много подробностей ЯП. Их компетентность позволяет писать самые сжатые решения некоторых проблем. Когда кто-то менее опытный сталкивается с этими проблемами, ему приходится тратить несколько часов на Гугл и обсуждение с коллегами, чтобы просто понять, что вообще происходит.
Эти затраты часто игнорируются, но и они – часть цены за конечное решение. Простейшее решение может требовать больше времени и кода, но впоследствии оно не повлечёт за собой таких же затрат.
Некоторые компании снижают сложность используемого ЯП с помощью гайдов, статического анализа и код-ревью. Как правило, со временем такие гайды изменяются и нарушаются.
8. Неограниченные разработчики
Обычно архитектуру ПО выбирают тщательно. Новый или менее опытный разработчик может и не знать об архитектурных решениях. Такой разработчик может писать код в ущерб архитектуре, тем самым усложняя её. Тогда в коде «всплывает» новая архитектура, которую трудно заметить другим разработчикам. И это ещё один шаг в сторону усложнения.
Иными словами, не ограничивать разработчиков = увеличивать сложность.
Ограничить можно несколькими способами. Например, категоризировать возможности разработчиков, дать доступ к подходящим категориям. Нужно ограничить внесение изменений архитекторами, например, на введение нового ЯП.
Применяйте ограничения через проверку кода с помощью статического анализа. Это единственный способ держать сложность под контролем.
9. Модульная архитектура
Модульная архитектура предполагает разделение софта на малые части с ограниченной областью действия, размером и с чётким разграничением ответственности. Подход был популярен достаточно долго и признан хорошей практикой.
Но со временем модули начали расширяться до группы монолитов. И причина тому – отсутствие ограничений модулей. Например, если модуль ограничен только до функций без состояний, он не будет расширяться за предел этой функциональности. Другой пример – ограничение модуля до абстрагирования взаимодействия с платёжными системами. При этом код-ревью – это верный способ убедиться в соблюдении ограничений.
Заключение
Разработкой софта должны руководить архитекторы и технологи, которые защитят продукт в долгосрочной перспективе. Архитектор должен принимать решения о выборе технологий и справляться с изменениями в стеке. Он должен следить за модульностью, зависимостями и уровнем сложности. Разработчики должны знать области действия модулей и соблюдать ограничения. Руководство может достигнуть этих целей с помощью код-ревью и статического анализа.
Комментарии