Как не дать проекту превратиться в наследие.

Корпоративное программное обеспечение часто ассоциируется с устаревшим программным обеспечением. Термин унаследованная система или унаследованный код имеет негативное значение в мире разработки программного обеспечения. У старых систем может быть много отрицательных характеристик, но наиболее распространенными являются высокая случайная сложность, отсутствие модульных тестов и отсутствие проектной документации.

Подавляющее большинство инженеров-программистов на самом деле не хотят присоединяться к устаревшим проектам и хотели бы работать только над новыми. Однако, если инженеры действительно хотят работать над унаследованным проектом, обычно это означает, что им пообещали только разработать новые функции или переписать проект с нуля и мигрировать в облака в контейнерах докеров.

Давайте попробуем понять, почему корпоративный проект может стать наследием, но прежде нам нужно кратко обсудить, что такое корпоративное программное обеспечение и какими ключевыми характеристиками оно обладает.

Характеристики корпоративной системы

Корпоративное программное обеспечение автоматизирует бизнес-процессы компании, поэтому оно разрабатывается для организаций или предприятий, а не для отдельных пользователей.

Корпоративные системы обычно имеют следующие характеристики:

  • Сложная бизнес-логика. Корпоративное программное обеспечение предназначено для автоматизации бизнес-процессов, поэтому бизнес-логика или доменная логика должны отражать бизнес-правила и процессы из реального мира. Сложность бизнес-правил зависит от сложности самого бизнеса, но обычно все не так просто: финансы, маркетинг, продажи и т.д.
  • Требование высокой доступности. Корпоративные системы должны быть высокодоступными (99 % времени или более). Недоступная система может парализовать работу всей компании и стоить больших денег.
  • Строгое требование согласованности. Эвентуальная согласованность не является широко применимым атрибутом корпоративных систем. Например, пользователи не должны видеть устаревшую цену на товар, если она была изменена администратором.
  • Долгая продолжительность разработки и обслуживания проекта. Обычно корпоративный проект живет столько же, сколько бизнес, для которого он был разработан. Сегодня у аутсорсинговых компаний есть энтерпрайз-проекты, кодовой базе которых 15–20 лет.
  • Большая кодовая база. Размер кодовой базы зависит от размера бизнеса и его сложности, но обычно корпоративное приложение содержит до полумиллиона строк кода или более.
  • Интеграции с внешними системами. Обычно корпоративная система интегрируется как минимум с парой внешних систем.

Однако обычно корпоративная система не касается:

  • Обработка больших данных. Корпоративные системы обычно не обрабатывают терабайты данных. Технологии больших данных, такие как Spark или Data Lake, не входят в список технологий, используемых для внедрения корпоративного программного обеспечения.
  • Высокие требования к масштабируемости. Корпоративная система разрабатывается для одной организации, в которой обычно работают сотни или тысячи пользователей, но не миллионы. Если организация не планирует значительного роста, высокая масштабируемость не является атрибутом качества, который необходимо внедрять.

Характеристики устаревшей системы

Устаревшая система или унаследованный код стали синонимом плохих систем, с которыми инженеры-программисты не хотят иметь дело.

Устаревшие системы обычно имеют следующие характеристики:

  • Отсутствие модульного или интеграционного тестирования. Обычно очень сложно покрыть устаревший код модульными тестами из-за того, как код написан, например. большие методы и классы, нарушение принципов единой ответственности и слабой связи, интенсивное использование статических классов и т. д.
  • Высокая случайная сложность кодовой базы. Случайная сложность, в отличие от существенной сложности, — это то, что инженеры-программисты привносят в систему, нарушая стандарты кодирования, принципы проектирования, лучшие практики и т. д.
  • Старые технологии, старые методы проектирования и архитектуры. Например, проект может активно использовать антишаблон Active Record для доступа к данным.
  • Метрики показывают плохие результаты. Все показатели кода, такие как индекс ремонтопригодности, цикломатическая сложность, дублирование кода, входящие и исходящие зависимости и другие, показывают довольно плохие цифры.
  • Отсутствие проектной документации. Проектная документация, которая должна описывать архитектуру проекта, процессы непрерывной интеграции и доставки, дизайн ключевых функций, интеграцию с внешними системами, использование сторонних библиотек, стандарты кодирования и прочее, отсутствует или далека от идеала.
  • Технический долг существует, но не отслеживается. В бэклоге всего несколько заявок по техническому долгу, но на самом деле в проекте очень много технического долга.
  • "Это просто работает" или "Лучше не трогать этот код" — это фразы, которые инженеры регулярно говорят новым товарищам по команде о некоторых частях устаревшего кода.


Как исправить ошибку, не нарушая работу приложения
Как быть более уверенным при изменении исходного кода.levelup.gitconnected.com



Является ли каждая корпоративная система устаревшей системой?

Так почему у типичного корпоративного проекта есть хорошие шансы стать наследием в негативном смысле этого слова?

Как мы уже говорили, типичный корпоративный проект — это долгоживущий проект. После одного-двух лет активной фазы разработки проект переходит в «сопровождение и развитие». По сути, разработка корпоративного проекта — это бесконечная история. Бизнес развивается, и он регулярно просит команду инженеров внедрить новые функции после того, как он будет запущен в производство.

Из-за долголетия корпоративных проектов команда инженеров может полностью поменяться даже пару раз. Пожалуй, нет ни одного человека, знающего «общую картину». Каждая новая команда будет реализовывать функции и исправлять по-своему, будет смешивать инструменты, подходы, стандарты кодирования, так что кодовая база проекта теряет свою концептуальную целостность.

Но нетрадиционные корпоративные проекты существуют. Это сверхсложная задача — иметь хорошее качество после 10 лет разработки, но она выполнима и требует как минимум следующего:

  • Существует основная команда или, по крайней мере, один человек (архитектор), который работает над проектом с самого начала, владеет «общей картиной» проекта и выступает в качестве консультантов для текущих и будущих команд разработчиков в аспекты архитектуры и проектирования системы.
  • Архитектор поддерживает актуальность проектной документации и гарантирует, что она охватывает все важные аспекты проекта.
  • Статический анализ кода, показывающий качество кода, безопасность, производительность покрытия модульным тестированием и другие показатели, настраивается для проекта и является частью конвейера сборки. Сборка должна завершаться ошибкой, когда метрики кода ниже определенного порога.
  • Команда регулярно работает над сокращением технического долга. Вся техническая задолженность описывается в бэклоге. Команда выделяет 10–15 % каждого спринта на работу с заявками по техническому долгу или запрашивает у клиента специальный (технический) спринт каждые несколько месяцев.
  • Тестирование, тестирование и еще раз тестирование. Модульные тесты полностью охватывают как минимум доменную логику. Интеграционные тесты проверяют счастливые пути. Сквозные тесты проверяют как минимум критические пользовательские сценарии. Все тесты запускаются автоматически при каждой сборке для скорейшего обнаружения проблем.

Даже если вы присоединитесь к устаревшему проекту, не отчаивайтесь. По крайней мере, это идеальное место для разработчиков программного обеспечения, чтобы улучшить свои навыки рефакторинга и отладки и изучить «плохие методы», чтобы узнать, как не следует писать код.

Работая над старым проектом, постарайтесь проанализировать, что технически не так, и составьте подробный технический план по его улучшению. Приходите к менеджерам или клиентам со своими идеями. Не забудьте рассказать о ценности для бизнеса, которую получат ваши клиенты. Например, если вы планируете перенести приложение на современную платформу, вам нужно сказать, что это сделает приложение быстрее или безопаснее, чтобы конечные пользователи были более довольны.

Станьте тем, кто снимет ярлык «устаревший» с корпоративного проекта. Это будет сложное профессиональное путешествие, которое вам обязательно понравится.

использованная литература

Еще статьи



Развивайте эти несколько привычек, чтобы стать выдающимся инженером-программистом
Все, что от вас требуется, — это дисциплина.levelup.gitconnected.com





50 лучших практик разработки программного обеспечения для технических руководителей и старших специалистов
Лучшие практики для лучших инженеров.levelup.gitconnected.com