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

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

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

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

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

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

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

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


integrity maintenance
person Murthy    schedule 11.02.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person David Schmitt    schedule 11.02.2009
comment
Нет отрицательного голоса - однако, по моему опыту, этого очень сложно добиться. Команды технического обслуживания (или поддержки) имеют агрессивные цели/графики, в результате чего их основной мотив состоит в том, чтобы исправить как можно больше дефектов. Кроме того, они, как правило, не самые опытные разработчики, которых видел AFAI. - person Gishu; 23.07.2010
comment
Да, если основной целью ремонтной бригады (установленной руководством) не является улучшение ситуации, никакая добрая воля или стратегия не помогут. См. thedailywtf.com. - person David Schmitt; 26.07.2010

arrow_upward
1
arrow_downward

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

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

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

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

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

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

Основная идея заключается в том, что сопровождение должно быть процессом постоянного улучшения проекта, а не его постоянного ухудшения. Отличной книгой по этой теме является книга Майкла Фезерса Working Effectively. с устаревшим кодом. Возможно, вы захотите проверить это.

person Adam Bellaire    schedule 11.02.2009