Эффект плато. Как преодолеть застой и двигаться дальше - Хью Томпсон Страница 60

или Медленные падения и едва заметные отличия

Кент Бек жил вне законов. Кое-кто мог бы даже назвать его анархистом.

Живи он в XVI веке, не исключено, что именно он, а не Коперник, заявил бы, что Земля вращается вокруг Солнца. Когда Хью впервые услышал выступление Бека, эскапизм его философии и наглость его утверждений были настолько резкими, что показались заслуживающими внимания. Этот человек мог вполне серьезно утверждать, что мосты нужно строить не по готовым проектам, а ориентируясь на текущие обстоятельства. Он говорил множество столь же странных вещей, однако самым удивительным было то, что люди ему верили.

Как и все успешные революционеры, он искал союзников. Они встречались и обменивались планами свержения устоявшихся порядков. Во время одного из таких собраний в Сноуберде Бек вместе с шестнадцатью другими людьми подписал Манифест гибкости {138}. Это был один из самых еретических документов в области разработки программ. На дворе стоял 2001 год.

Бек – создатель подхода под названием «экстремальное программирование», и начало его книги Extreme Programming Explained («Экстремальное программирование в деталях») напоминает скорее политическую доктрину, а не технический текст для разработчиков программ {139}:

«Extreme Programming (XP) напрямую связано с социальными изменениями. Оно помогает нам отказаться от привычек и методов, которые были полезны в прошлом, однако теперь не позволяют нам сделать свою работу в наилучшем виде. Все дело в том, чтобы отказаться от того, что защищает нас, однако при этом мешает нашей производительности».

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

До появления Манифеста гибкости крупные проекты по разработке программных продуктов были жестко структурированы и следовали модели под названием «водопад» {140}. В этой системе разработка разбивается на несколько монолитных этапов, один из которых последовательно переходит в другой. Этот же крайне структурированный и методичный подход используют инженеры при проектировании и строительстве небоскребов (проект, строительство, тестирование). И, как и при строительстве небоскреба, разработка программы могла занимать до нескольких лет. Рабочие комитеты устраивали встречи, на которых согласовывались все детали программы, после чего программисты суеверно стучали по дереву. После завершения работы над набором основных свойств они принимались за дело, выполняя одно задание за другим. В это время тестеры готовились перехватить у них работу, а члены руководящего комитета пытались справиться с прыгавшим от напряжения кровяным давлением. Когда результаты передавались тестерам для поиска ошибок, все опять принимались стучать по дереву. В это время, когда после первого заседания комитета уже проходило около 18 месяцев, кто-то мог рассказать команде о выходе на рынок Netscape или изобретении Facebook, после чего все начальные планы комитета уже оказывались полностью устаревшими. Разумеется, при наличии согласованного и утвержденного набора свойств о пути назад не могло быть и речи. И тогда часть разочарованных программистов уходила из компании, а маркетинговая команда принималась размышлять и обсуждать, как получше солгать о том, на что действительно способна программа.

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