Чед Фаулер - Программист-фанатик

В столбце «технология» перечисли, что ты считаешь самым ценным в технологиях, в которые решил вложиться. Какие наиболее важные атрибуты технологии следует учитывать в процессе выбора? Каким образом ты создаешь масштабируемые системы? Какой видишь наиболее продуктивную среду для разработки программного обеспечения? Какие платформы лучше, а какие хуже всего в общем случае?

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

Это список твоих уязвимостей.

2. Знай своего врага. Выбери технологию, которую ты больше всего ненавидишь, и сделай на ее основе один проект. Разработчики имеют склонность разбиваться на конкурирующие лагери. Приверженцы .NET ненавидят фанатов J2EE, а те, в свою очередь, платят им той же монетой. Любители операционной системы UNIX ненавидят Windows, а любители Windows терпеть не могут UNIX.

Придумай простой проект и попробуй создать прекрасное приложение в рамках ненавидимой тобой технологии. Если ты пишешь на языке Java, покажи этим фанатам .NET, как настоящий разработчик использует их платформу! В лучшем случае ты поймешь, что столь ненавидимая тобой технология на самом деле не так уж плоха и на ее основе можно создавать приличный код. Кроме того, у тебя появится (разумеется, пока не развитый) новый навык, из которого в будущем ты, возможно, сумеешь извлечь выгоду. В худшем случае ты выполнишь практическое упражнение, получив дополнительную базу для своих аргументов.

В начале этого тысячелетия один небольшой протест сильно изменил всю индустрию разработки программного обеспечения. Группа экспертов-разработчиков в какой-то момент поняла, что существующие методы ведения проектов могут привести как к успеху, так и к неудаче. В промышленных условиях, где большинство проектов оканчивается неудачей, они, как им казалось, нашли способ, ведущий к успеху. Эта группа называла себя альянсом специалистов по быстрой разработке ПО (Agile Alliance).

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

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

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

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

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