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

Что вы можете сделать, чтобы избежать рефакторинга в будущем, или "Делайте это хорошо, чтобы сделать его хорошим"

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

Так или иначе, вы не можете избежать ошибок, но можете контролировать их количество, выполняя определенные действия, такие как:

  • Используйте модульное и автоматизированное тестирование
  • Внедрить BDD
  • Делать фичи меньше, вводить и публиковать модификации меньшего размера, тем самым упрощая систему
  • Делайте рефакторинг :) меньшего размера, на регулярной основе, как ежедневная уборка
  • Требовать от команды ответственности за разрабатываемую систему
  • Предоставьте доступ к измененной/новой функции ограниченному числу заинтересованных лиц, а не всем сразу, что поможет выявить проблемы намного раньше
  • Начните использовать подходы к унифицированной архитектуре, чтобы уменьшить разнообразие технических решений.
  • Внедрять и корректировать процедуру технического надзора перед созданием новой фичи или внесением модификаций, проводить обзор архитектуры и мониторинг решений, фиксировать результаты и собирать рекомендации
  • Введите показатели сложности и качества кода и отслеживайте эти показатели.

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

Узнайте больше на — http://bit.ly/2YePtU7

Первоначально опубликовано на https://www.luxoft-training.com.