Обратимость: мудрость иногда расцветает слишком поздно
Последнее преимущество определяет один из принципиальных вкладов объектной технологии в жизненный цикл ПО - обратимость.
Обратимость - официальное признание влияния более поздних стадий процесса разработки ПО на решения, выработанные на начальных стадиях. Безусловно, эта особенность является неизбежной и универсальной, но это одна из наиболее тщательно охраняемых тайн.
Хотелось бы, конечно, полностью определить проблемы, прежде чем приступать к их решению: анализ завершать до проектирования, проектирование - до начала реализации, реализацию - до поставки. Однако что делать, если в процессе реализации разработчик внезапно понимает, что система может что-то делать лучше или вообще должна иначе работать? Отругать его за то, что занимается не своим делом? А если он действительно прав?
Это явление отражает поговорка - esprit de l'escalier, ("лестничное остроумие", остроумие задним числом). Вообразите приятный обед в фешенебельной парижской квартире на третьем этаже. Со всех сторон звучат остроты по поводу телятины Marengo, а Вы будто онемели. Суаре заканчивается, Вы попрощались с хозяевами, спускаетесь по лестнице и вдруг - вот она, разящая остроумная реплика, которая сделала бы Вас героем вечера! Но слишком поздно.
Имеют ли место приступы esprit de l'escalier в программном обеспечении? Они существуют с тех пор, как стали замораживать спецификацию прежде, чем приступить к решению. Плохие менеджеры подавляют программистов - пишите код и помалкивайте. Хорошие менеджеры стараются использовать в своих интересах запоздалые идеи спецификации, не обращая внимания на то, кто отвечает за данную проблему, и невзирая на требования стиля водопада.
С развитием OO-разработки стало ясно, что явление esprit de l'escalier - не только результат лени при анализе, но и отражение самой природы процесса разработки ПО. Мудрость иногда приходит слишком поздно. Нигде более, чем в объектной технологии, не проявляется так явно связь между проблемой и решением. Не только потому, что мы иногда понимаем аспекты проблемы только в процессе решения, но и по более глубокой причине. Решение воздействует на проблему и может предложить лучший функциональный подход.
Вспомним пример из лекции 3 с командами отката и повтора и списком истории: фактически в ходе реализации был предложен новый, более удобный интерфейс, облегчающий работу конечных пользователей.
Введение обратимости требует дополнить диаграмму жизненного цикла кластера указаниями на постоянную возможность обратных пересмотров и исправлений:
Рис. 10.5. Жизненный цикл отдельного кластера, обратимость
