Когда хорошая архитектура портится
Mark Dalgarno http://www.methodsandtools.com/archive/archive.php?id=85
Введение
В конце концов каждый разработчик сталкивается с кодом, который никто не понимает и не трогает, чтобы не сломать. Это происходит из-за программной эрозии – постоянного разрушения внутренней структуры ПО, происходящего на всех стадиях разработки. На архитектурном уровне программная эрозия заключается в различии запланированной и реализованной архитектуры. Запланированная архитектура является текущей концепцией структуры ПО. А реализованная меняется из-за различных модификаций и временных нарушений программной архитектуры. Если не бороться с этими расхождениями, то эрозия со временем накапливается и мешает системе удовлетворять поставленным требованиям.
Типы
- Нарушение архитектуры
- Циклические зависимости
- Мёртвый код
- Дублирование кода
- Метрические вырождения
Признаки
Даже самые молодые проекты подвержены эрозии, если в них не заостряется на этом внимание. Вот некоторые признаки, по которым можно оценить степень тяжести разрушения вашей программы:
- рост рисков и затрат времени и усилий при внедрении нового функционала
- снижение продуктивности и качества
- никто не отвечает за архитектуру, а знает о её устройстве всё меньшее количиство людей
- отсутствие стабильного состава разработчиков
- отсутствие рефакторинга
- необходимость переписывать код
Последствия
Чтобы оценить последствия эрозии кода, было проведено исследование. Двум командам поставили одну и ту же задачу, которая требует написания примерно 3-х тысяч строк кода в программе на 50 тысяч строк. Первой команде дали проект, подверженный эрозии. Второй команде дали тот же проект, но предварительно его «почистили» и восстановили архитектуру в соответствии с документацией. В результате первой команде потребовалось в 2 раза больше времени на выполнение задачи. Последствия эрозии очевидны.
Причины
Эрозия не появляется внезапно и из ниоткуда. Она растёт при изменениях, которые появляются по разным причинам. Например, нужно добавить новые особенности, чтобы склонить покупателя к покупке, или расширить кроссплатформенность. Порой нужно что-то срочно изменить для быстрой выгоды и используется быстрый и простой способ, который будет работать, но повлечёт за собой большие проблемы в будущем.
Примеры
В 2007-2008 автор статьи посетил множество IT-семинаров и расспрашивал участников о разных случаях программной эрозии, с которыми им доводилось сталкиваться. В результате почти все опрошенные в той или иной степени сталкивались со всеми видами эрозии.
Исследование аутсорсинговой системы 1MLOC C/C++
История проекта
Разработка длилась много лет. Шесть лет назад компания переехала в индию к другому владельцу, где она с тех пор развивалась. На момент переезда считалось, что планируемая архитектура совпадает с реализованной. Со временем в команду добавлялись люди и штат сотрудников вырос с 5-ти до 50-ти. Недавно компания провела сравнение количества проделанной работы старой и новой команды. Оказалось, что оно одинаково.
Нынешняя ситуация
Исследую это разницу в продуктивности, компания сравнила архитектуру 6-ти летней давности с нынешней. Выявилось, что теперь многие части системы имеют незапланированные зависимости. Хоть все подобные изменения были задокументированы и сотрудники могли ознакомиться со структурой, изначальная структура лучше подходила для решения поставленных задач. Так что можно сказать, что хорошая архитектура испортилась. Сейчас же компания планирует частично вернуться в Германию под старое руководство.
Анализ
Проект разрабатывался много лет и за это время изменилось много вещей. Возможно, на момент переезда проект уже был подвержен эрозии. Сам переезд тоже сильно повлиял на развитие. Новые люди, другие навыки и культура. Новым сотрудникам было нужно вникнуть в уже существующие устои. Всё это способствовало ухудшению ситуации.
Предотвращение
Главным образом борьба с программной эрозией это забота менеджеров. Если они заинтересованы в эффективности проекта на данный момент, тогда разработчики могут сфокусироваться на быстром, но поверхностном решении текущих проблем. Но в дальнейшем будет сложнее продолжать латать программу. Но менеджеры могут следовать некоторым указаниям, чтобы бороться с эрозией.
- Начните разработку с устойчивой структуры. Пусть она будет гибкой и будет учитывать возможные будущие изменения.
- При реализации представляйте архитектуру. Старайтесь придерживаться плана.
- Сравнивайте то, что получилось, с тем, что планировалось.
- Ищите циклические зависимости, дублирование кода и прочие следы эрозии.
- Выполняйте рефакторинги системы, чтобы устранить найденные проблемы.
Поддержка и наставления менеджеров могут создать у разработчиков культуру борьбы с эрозией кода. Появятся регулярные рефакторинги, чёткое распределение обязанностей, обмен архитектурными знаниями, частое общение между всей группой. Можно даже создать «зелёную неделю», в течение которой команда будет работать над улучшением их ремонтоспособности кода.
Написание с нуля
Довольно часто разработчик сам утверждает, что часть кода испортилась и следует её переписать. Обычно это происходит, когда довольно долго откладывали рефакторинг. Если переписывания удалось избежать, а рефакторинг не проводился, тогда эрозия продолжает развиваться, пока работать с кодом не становится слишком сложно. В конце концов из-за халатности команды становится необходимым начисто переписать его. Но прежде чем этим заняться стоит задайте себе несколько вопросов. Действительно ли этот код уже нельзя спасти? Понимаете ли вы, что нужно сделать? Исправляете ли вы ошибки или делаете что-то новое?
Итог
Любая успешная программа должна развиваться. Нужно проводить профилактические работы, чтобы избежать эрозии кода, и чем раньше, тем лучше. Иначе уже придётся бороться с последствиями. Существует много способов бороться с порчей архитектуры. Нужно просто решить, какой лучше всего подходит вашему проекту. Менеджер должен в первую очередь заботиться об этом. Если вы архитектор или разработчик, то учитесь разным приёмам обнаружения и борьбы с эрозией кода.