Как я уже говорил, любой отдельно взятый человек может заключать в себе характеристики сразу нескольких пород. Конечно, разобраться в таких людях труднее, но это того стоит. У программистов на редкость богатое «наполнение». Различия между породами и индивидуальные стили, характерные для каждой из них, как мне кажется, нужно смаковать. Вполне возможно, что в следующий раз вы столкнетесь с этими характеристиками, невзначай взглянув в зеркало.
Ниже я перечисляю распространенные породы и их характеристики.
Архитектор[5].Большинство руководителей обожают этот тип программистов – и, действительно, любой такой деятель окажется ценным приобретением для вашей команды. В основном архитекторы концентрируются на общей структуре кода. Они мыслят объектами, а их лучший друг – лист белой бумаги. Посвящая себя без остатка решению бизнес-задач, они строят абстракции, проводят анализ систем, после чего переходят к кодированию конкретных решений. Слов нет – все это очень важные элементы программирования, но для комплексного выполнения задач их еще не достаточно. Зачастую в высшей степени разумные замыслы архитектора воплощаются в настолько общем и непонятном коде, что людей, могущих разобраться в нем и продолжить начинание, просто не находится. Особи, способные генерировать удачную идею в голове (а лучше в Visio), а затем выполнить ее полноценную конкретизацию в коде, становясь, таким образом, единственными участниками процесса, встречаются очень редко. Недостаток архитекторов в том, что их код часто служит только одному хозяину, а исполнять чужие команды категорически отказывается[6]. Некоторые архитекторы очень любят набросать структуру кода, с тем чтобы впоследствии передать его на растерзание программистам более «низкой» квалификации. Иногда в коде, написанном архитекторами, встречаются весьма странные конструкции – например, окна с сообщениями о системных прерываниях из-за ошибок, появляющиеся по той лишь причине, что код предполагалось исполнять в виде библиотеки DLL на сервере.
Конструктивист. Конструктивисты получают удовольствие от процесса написания кода и его результата. Стратегическим планированием они себя утруждают не всегда, но факт в том, что с написанием кода они справляются быстро, причем в большинстве случаев ошибок в нем не обнаруживается даже на этапе альфа-тестирования. Код конструктивисты пишут по наитию, а потому их логика не всегда понятна. У некоторых конструктивистов все в порядке и с интуицией, и со стратегическим планированием, поэтому код выступает естественным продолжением хода их мыслей. Но стоит попросить конструктивиста составить документацию, он обязательно ответит, что код самодокументируемый. Впрочем, если на него немного надавить и дать понять, что без документации никуда не деться, он, вероятно, согласится ее составить – и сделает это качественно. Кто спорит – код должен быть самодокументируемым, но следует иметь в виду, что основное внимание программисты этого типа уделяют процессу создания кода, поэтому остальное для них не так уж важно. Количеству сборок, которое конструктивист выдает за день, позавидует даже Microsoft. Соответственно, их код обычно отличается надежностью. Однако же по мере разбухания (а этот процесс неизбежен) надежность улетучивается, а конструктивист начинает судорожно искать новые, «заплаточные» решения – ведь для него очень важно видеть результат и пребывать в уверенности в том, что он справился с поставленной задачей. Конструктивист в сочетании с архитектором имеют все шансы стать прекрасной командой. Если же вы умудритесь отыскать конструктивиста и архитектора в одном лице, считайте, что львиная доля кадровых проблем решена.
Художник. На самом деле, искусства в написании кода не меньше, чем науки, – не зря же университеты часто сводят оба направления в одной структуре и называют ее как-нибудь вроде «факультета свободных искусств и наук». Не будь в программировании художественного аспекта, может быть, оно приносило бы нам гораздо меньше морального удовлетворения. Художник как тип программиста сконцентрирован на процессе создания кода – переносе коммерческих требований на программные конструкции и искусном сведении объектов пользовательского интерфейса в одну изящную структуру. Работая с компонентами без видимого интерфейса, художники обнаруживают тенденцию к правильной и логичной организации. Недостаток художника в том, что очень часто он затягивает кодирование, пытаясь выяснить, сколько знаков равенства можно установить в одной строке, не нарушив при этом правильность результата булева оператора. С другой стороны, если программист не культивирует в себе художника, результаты его деятельности зачастую отрываются от реальности, теряют «изюминку». Стоит отнять у художника все его отличительные качества, и в результате получится мина замедленного действия, которая обязательно взорвется под пальцами пользователей. Разделяя некоторые характеристики конструктивистов и архитекторов, художники активно претендуют на собственный стиль.
5
Термином «архитектор» я в данном случае обозначаю один из личностных типов программистов и совершенно не имею в виду полноценного программного архитектора. О том, какую роль играет архитектура в общей схеме разработки, говорится в главе 6.
6
А ведь это очень важно – согласно авторитетным оценкам, по меньшей мере 70 % стоимости программного обеспечения приходится на сопровождение. См. William Н. Brownctal, AntiPatterns: Refactotoring Software, Architectures, and Projects in Crisis (New York: John Wiley & Sons, 1998), p. 121.