Обратимость решений
На конференции XP 2002 Энрико Цинанотто (Enrico Zaninotto) прочитал интереснейший доклад, в котором указал на связь между гибкими методологиями и "облегченным" процессом производства в промышленности (lean manufacturing). С его точки зрения, одним из основных положений обоих методов является уменьшение сложности процесса путем повышения его обратимости.
Вообще, необратимость принимаемых решений вполне можно считать основной причиной сложности процесса разработки ПО. Судите сами: если однажды принятое решение можно легко изменить, то его правильность становится менее важной. А это делает жизнь много проще. При эволюционном стиле проектирования дизайнеры должны стараться принимать легко обратимые решения. И вместо того, чтобы мучительно отыскивать единственно правильное решение, нужно или постараться отложить его принятие на потом (когда у вас будет больше необходимой информации), или же принять такое решение, которое в будущем можно изменить без особых усилий.
Стремление к выработке обратимых решений является основной причиной, по которой гибкие методологии настоятельно рекомендуют держать весь код в системах управления исходным кодом (source code control systems). Разумеется, это не гарантирует обратимость решений, особенно если они долгосрочные. Однако это придает команде некоторую уверенность в такой возможности, даже если она используется очень редко.
Кроме того, обратимый дизайн подразумевает наличие процесса, при котором все ошибки быстро становятся очевидными. С этой точки зрения очень хорош итеративный подход, когда заказчик воочию наблюдает развитие разрабатываемой системы. И если вдруг окажется, что в спецификации вкралась ошибка, поправить ее можно будет сразу же, еще до того, как цена исправлений станет слишком высока.
Тот же подход очень полезен и в проектировании. Проектные решения должны выстраиваться так, чтобы проблемные моменты тестировались и оценивались как можно раньше. Кроме того, очень полезно проводить эксперименты, чтобы понять, насколько сложно будет внести изменения в будущем (даже если вы не собираетесь ничего менять сейчас). Наилучший способ - поэкспериментировать на прототипе, сделанном на каком-то ответвлении системы. Такой метод раннего прототипирования для оценки сложности будущих изменений в системе уже был успешно опробован несколькими командами.
