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

Question

При запуске нового проекта мы запускаем его, основываясь на том, что является «последним» и что «известно».

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

Все будет хорошо, пока мы не завершим разработку и не начнем производство.

Затем идет обслуживание (устранение дефектов и улучшения). Люди меняются, архитекторы и дизайнеры уходят.

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

Эта тенденция наблюдается во многих проектах, над которыми я работал.

Как сохранить «концептуальную целостность» системы при выполнении технического обслуживания?

Answer 1

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

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

Кроме этого, это сводится к гигантской теме лучших практик . Почти все "хорошие" методы программирования направлены на простоту обслуживания. Хорошие методы проектирования и строительства приводят к проектам, которые легче понять последующим разработчикам. Стив Макконнелл говорит об управлении сложностью как о главном императиве работы программного обеспечения. Если сложность решается заранее, тем, кто придет позже, будет легче сохранить концептуальную целостность проекта без изменений.

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

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

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

Основная идея заключается в том, что обслуживание должно быть процессом постоянного улучшения проекта, а не постоянного его ухудшения. Отличная книга, посвященная этой теме, - «1017 * Майкла Фезерса,« Эффективно работающая с устаревшим кодом ». Вы можете проверить это.

Answer 2

1. Начните с минимальных изменений.
2. Попасть в стиль проекта.
3. Создайте острова здравомыслия.
4. Каждый коммит должен улучшать состояние кода.

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

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