Весьма высока вероятность того, что причина, по которой вас сделали руководителем, заключается в ваших успехах на поприще техники. Это свое предположение я уже ранее высказывал. И хотя технические навыки далеко не всегда гарантируют качество руководства, для исполнения роли, которую я намерен описать в этой главе, вы подходите идеально. Многое из того, о чем я рассказывал в предыдущих главах, полагаю, привело вас в уныние своей новизной; материал же этой главы, напротив, скорее всего, покажется вам знакомым и, может быть, даже тривиальным. Это совершенно не означает, что читать главу не надо, – не зря же я ее написал, в конце концов! На самом деле взглянуть на технические проблемы с точки зрения технического лидера очень полезно. Ведь теперь вы не просто «технический руководитель» группы; вы – лидер с большой буквы. Принятие решений – это ваша прерогатива. За последствия принятых решений, сказывающихся на разрабатываемых программных продуктах, вы также несете ответственность, поэтому проблема выбора и принятия решений выходит на первый план.

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

Роль технического лидера заключается в том, чтобы координировать архитектурные и проектные решения. Архитектура и проектирование – это, как известно, две разные вещи. Да, действительно, программисты иногда воспринимают их как синонимы, но, я вас уверяю, это в корне неправильно. Практикуя техническое лидерство в масштабе своего отдела, вы скоро убедитесь в том, что проектирование компонентов приложений очень сильно отличается от разработки их общей архитектуры. Архитектура направлена на многократное использование проектных решений. В идеале перед сборкой системы из составляющих ее компонентов неплохо было бы макетировать архитектурное понятие. В этом контексте вспомните компонентное конструирование из области объектно-ориентированной технологии – своей основной целью оно провозглашает многократное использование кода. Итак, мы имеем дело с двумя совершенно разными задачами, и по моему скромному, но правильному мнению, многократное использование проектных решений значительно важнее.

Архитектура ориентирована на многократное использование проектных решений.

Сила объектно-ориентированной технологии вне зависимости от языка, на котором она реализуется, – это возможность создания объектов, связывающих прикладные данные с вариантами пользовательского взаимодействия. Детали при этом скрываются. Таким образом, избегая непосредственного соприкосновения с уровнями данных и пользовательского интерфейса, объекты получают открытые интерфейсы, которые, в свою очередь, взаимодействуют со структурой программы и процессами. Итак, мы получаем возможность собирать компоненты, согласующиеся со свойствами и методами, имена которых значимы в контексте проблемной области (в противоположность области решений). К примеру, метод под именем ShowAppointments, наполняя свойство Appointments графического пользовательского интерфейса, способен одновременно скрывать детали – такие как Select * from Appointments where Date = Today. Таким образом, удобочитаемость программ открывает возможности для решения конкретных задач.

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

Обратимся к аналогии. Классическую архитектурную традицию западной цивилизации принято отсчитывать от древнегреческих и древнеримских строений. Эти здания, простоявшие уже более двух тысяч лет, подобно литературным произведениям талантливых авторов, доносят до непосвященного наблюдателя простое и ясное послание. В то же время при более детальном анализе структуры этих зданий выясняется, что в них скрыты многочисленные свидетельства дотошной творческой работы. Программная архитектура способна на такие же чудеса – демонстрируя внешний блеск, она может заключать в себе невероятную сложность. Впрочем, поскольку наша дисциплина существует всего лишь полвека, до того момента как ее лучшие достижения станут называть классическими, пройдет еще много времени. Как технический лидер вы должны заложить те основы, на которых сотрудникам вашей группы и, возможно, другим разработчикам предстоит заниматься непосредственно конструированием. Да, мы живем в то время, когда популярное искусство необдуманно провозглашается непреходящей ценностью. При этом не следует забывать, что результаты наших трудов над клавиатурой должны пройти проверку временем.

Традиционной метафоре строительства в нашей профессии соответствует термин «конструирование»[58]. Как часто мы им пользуемся для описания своих действий? По моим наблюдениям, довольно часто. Все начинается с детства. Если вы из моего поколения, то ребенком, наверное, играли с конструкторами – ну а представители поколения X, вероятно, помнят свои экзерсисы с Lego. Обиходное понятие «конструирование программного обеспечения» вполне доходчиво обозначает повседневную деятельность программиста. Попробуем проанализировать эту метафору в буквальном смысле и объяснить, что значит дополнять приложения новыми характеристиками. Можно ли надстроить небоскреб дополнительными десятью этажами и при этом пребывать в уверенности, что фундамент их выдержит? Мне так не кажется; надеюсь, что и вы придерживаетесь моего мнения. Придется обратиться к еще одной метафоре – садоводству. Разбивая сад и выращивая его, вы, естественно, время от времени выкорчевываете одни растения и высаживаете другие. В своей книге о прагматическом программировании Эндрю Хант (Andrew Hunt) и Дэвид Томас (David Thomas) высказываются об этой метафоре следующим образом:

«Растения в саду высаживаются, с одной стороны, в соответствии с исходным замыслом, а с другой – согласно текущим обстоятельствам. Некоторые из них выживают, другим же суждено превратиться в компост. Растения можно пересаживать, менять их расположение, играя, таким образом, со светом и тенью, ветром и дождем. Переросшие растения подрезают или срезают, а если, к примеру, какой-нибудь цветок по своему цвету не соответствует окружению, его пересаживают в более подходящее (с эстетической точки зрения) место. Занимаясь садоводством, мы выдираем сорняки и удобряем растения, которым нужна дополнительная поддержка. Хороший садовод постоянно наблюдает за здоровьем растений на своем участке и при необходимости вносит разного рода коррективы (удобряет почву, пересаживает растения, придумывает новый вариант разбивки)»[59].

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

Чтобы соответствовать потребностям бизнеса XXI века, мы должны построить органичную методику разработки программных продуктов.

Метафора садоводства, к тому же, выражает различие между органическим и синтетическим. Все органическое выращивается; синтетические же объекты собираются из конструируемых компонентов. Действительно, конструируя компоненты, мы делаем их синтетическими по самой природе. Однако та среда, в которой их предполагается выращивать, должна выводить целое за рамки суммы компонентов. Кроме того, она должна предусматривать возможность адаптации к изменяющимся коммерческим требованиям и к технологической эволюции.

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

За последнее десятилетие появилось множество работ – как фундаментальных, так и прикладных, – доказывающих необходимость применения в процессе разработки программных средств качественной архитектуры. Исследователи, специализирующиеся в этой области, указывают на то, что огромное количество проектов приложений заканчиваются неудачей именно из-за пренебрежения архитектурными вопросами[60]. В результате выполнения таких проектов, как правило, получаются «прямолинейные» системы. Их последующая адаптация к изменяющимся коммерческим требованиям осуществляется с большими трудностями, поскольку предполагает выделение значительных временных, трудовых и интеллектуальных ресурсов.

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

Создание архитектуры – это активный творческий процесс, который отнюдь не ограничивается сидением за клавиатурой, фиксацией коммерческих требований и реализацией компонентов, которые способны эти требования удовлетворить, в коде. В процессе работы над архитектурой вам придется абстрагироваться от своих механистических обязанностей и максимально углубиться в задачу, которую предстоит решить. Спору нет – во многих случаях решение оказывается вполне механистическим, то есть чисто программным. И тем не менее, если вы не разберетесь в задачах, стоящих перед своей компанией, обеспечить продуктам длительное и продуктивное существование вам, скорее всего, не удастся. Марк и Лора Сьюелл (Marc & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана[61]. С точки зрения этих авторов, любой архитектор должен:

• в совершенстве владеть искусством выслушивания, опрашивания и наблюдения;

• хорошо разбираться в предметной области клиента – будь то банковское обслуживание, деятельность государственных органов, образование, здравоохранение, розничная торговля или скачки;

• получить стратегическое представление о деятельности предприятия клиента, не ограничиваясь тактическим или рабочим обзором его деятельности;

• иметь комплексные познания в технологической области – для того чтобы при разработке архитектурного плана суметь учесть все без исключения варианты стратегических решений;

• наладить конструктивное взаимодействие с клиентом и специалистом, ответственным за конструирование;

• уяснить видение вопроса клиентом и согласованное с ним проектное решение, следить за их неукоснительным соблюдением.

Не кажется ли вам, что выполнение всех этих требований выходит за рамки ваших скромных обязанностей? Если вы придерживаетесь такой точки зрения, рекомендую вам расширить кругозор, предварительно попытавшись вспомнить все разработанные с вашим участием продукты, которым так и не суждено было продвинуться дальше первой версии. Все мы так или иначе имели дело с продуктами-однодневками. С моей точки зрения, недостаточно комплексное понимание задачи приводит к созданию подобного рода тактических решений, которые на первый взгляд удачны, однако не выдерживают проверки временем.

Архитектор должен уметь решать эту проблему, имея в виду два важных понятия: проектные ограничения (design forces), которые обусловливают все решения, принимаемые относительно программных средств, и аналитические позиции (analysis viewpoints), позволяющие принимать решения в соответствии с проектными ограничениями.

Поскольку в формализованном виде дисциплина архитектурного планирования появилась относительно недавно, в ее рамках существует несколько конкурирующих концепций. Мальво (Malveau) и Маубрей (Mowbray)[62] – два эксперта в этой области – приводят список основных концепций. Это каркас Закмана (Zachman), открытая распределенная обработка (Open Distributed Processing, ODP), анализ предметной области, модель 4+1 представлений программной архитектуры и, наконец, академическая программная архитектура. Это уже немало. А знакомы ли вы с положениями каждой из них? Если нет, торопитесь – принимайтесь за изучение перечисленных концепций, поскольку они предоставляют любому специалисту прекрасный инструментарий для создания многократно используемых систем.

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

• Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?

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

• Минимизирована ли сложность высокоуровневых архитектурных характеристик системы?

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

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

• Достаточна ли компетентность персонала для сопровождения систем, построенных на основе новых технологий? Если в конструировании[63] применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?

Ни в коем случае не забывайте об этих вопросах и проблемах. Обязательно сформулируйте их и донесите до группы разработчиков – ведь умение четко сформулировать вопросы иногда важнее, чем даже знание правильных ответов на них. Может быть, конечно, в этом я преувеличиваю, но, полагаю, мысль вам понятна. Способов наделать глупостей всегда более чем достаточно, и первый вопрос, который вы должны себе задать, звучит так: «Что я должен делать? Какое решение будет правильным?» Задавая адекватные вопросы, вы сможете организовать создание стройной, мощной и долговечной архитектуры.

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

• Как будет проходить взаимодействие пользователей с системой? (Эту аналитическую позицию часто называют вариантной.)

• Какие компоненты требуется собрать для того, чтобы обеспечить функционирование системы?

• Каков механизм взаимодействия компонентов, благодаря которому система функционирует?

• Какие технологии в наибольшей степени приспособлены для создания данного программного обеспечения?

• Как предполагается поставить систему клиенту?

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

Переработать архитектуру значительно сложнее и потенциально разрушительнее, чем реконструировать компоненты.

Держу пари, что вы сомневаетесь: нужно ли вам все это знать? Полагаю, что если вы действительно хотите стать эффективным техническим лидером, это знание необходимо. Если вы пользуетесь языком программирования четвертого поколения (4GL, например, Visual Basic), а не, скажем, С++, то больше внимания следует уделять разработке архитектуры системы. Даже при условии применения С++ создать плохую архитектуру не представляет труда – что уж говорить о языках четвертого поколения! Да, действительно, они позволяют оперативно выстроить механизм взаимодействия пользователя с системой, но это, как вы понимаете, лишь ее оболочка. Термин быстрая разработка приложений (Rapid Application Development, RAD), возникнув на заре создания программных продуктов под Windows, первоначально отражал высокие темпы выхода продуктов на рынок, достигавшиеся средствами языков четвертого поколения. В сегодняшних условиях «быстрая» разработка в большинстве случаев приводит к появлению некачественных программных продуктов. Мне даже кажется, что аббревиатуру RAD сегодня более уместно расшифровывать как «разработка мерзких приложений» (Rotten Application Development). Первоочередное внимание следует уделять, говоря анатомическим языком, скелету, нервной системе и внутренним органам. В противном случае вы рискуете извергнуть очередную халтуру.

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

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

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

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

О чем вы говорите? Я предпочитаю VB и собираюсь писать на нем все программы[65]. Вы так считаете? Подумайте еще раз. Задачи, которые вам предстоит решать, – не гвозди; их нельзя вбивать одним молотком. Да, я опять обращаюсь к метафоре строительства, но, по-моему, в этом контексте она как нельзя более кстати. Не забывайте, впрочем, что метафоры и аналогии выполняют исключительно иллюстративную функцию – они как луч света в темной комнате, освещающий очертания меблировки. Иначе говоря, иллюстрация и реальный объект не идентичны; между иллюстрацией и проблемной областью нет точного соответствия. Аналогичным образом проектные решения можно принимать только при наличии утвержденной архитектуры.

В последующих разделах мы поговорим о том, как довести грамотно выращенный продукт до стадии сбора урожая. Вопрос заключается в следующем: является ли этот процесс многоступенчатым?

Итак, имея на руках грандиозную архитектуру, вы готовы приступить к проектированию компонентов. Прекрасно. Мобилизуйте все свои объектно-ориентированные навыки. В первую очередь вам предстоит проверить архитектуру, имея в виду подчеркнуть приоритет этого этапа (я называю его «нулевым») в контексте процесса проектирования. Другими словами, вы должны провести макетирование архитектуры, но не совсем так, как это делается обычно. Вместо обширного графического пользовательского интерфейса сконструируйте ряд низкоуровневых компонентов, снабдите их интерфейсами-заглушками и возвращаемыми значениями – это позволит убедиться в работоспособности системы в вертикальной проекции. Конструируемые на этом этапе графические пользовательские интерфейсы должны лишь подавать сигналы и запускать те или иные процессы – больше от них ничего не требуется. Ведь ни один человек не выживет, если его мозг не будет взаимодействовать с сердцем, так? Именно поэтому, кстати, косметические операции проводятся исключительно по желанию пациента, а вот при проведении операции на головном мозге его согласия не требуют. Я полностью убежден – проверять архитектуру необходимо. На это, скорее всего, уйдет больше времени, чем можно было бы ожидать, но не сомневайтесь – усилия стоят того. С соблазном сразу перейти к разработке реальных компонентов системы нужно бороться – будет очень неприятно, если, подключив все компоненты, вы обнаружите, что они не стыкуются или не работают.

Первое, что нужно сделать в процессе проектирования, – это проверить архитектуру.

Подробности процесса «проверки концепции» я, пожалуй, опущу – благо литературы, посвященной архитектуре и проектированию, предостаточно. Только вот не стоит перекладывать обязанности по проверке архитектуры на кого-то другого – и не дай вам Боже отложить этот процесс до бета-тестирования. Эта обязанность ложится на вас и ваших подчиненных, а основная идея, которую я стремлюсь до вас донести, ясна и понятна – нельзя уклоняться от выполнения своих обязанностей. Ваша первоочередная задача в процессе проектирования заключается как раз в том, чтобы проверить архитектуру на предмет ее применимости – вот почему речь идет о «нулевом», то есть о приоритетном, этапе. Если на все нижеследующие вопросы вам удастся ответить положительно, значит, вы наверняка на правильном пути.

• Предполагает ли архитектура возможность идентификации подсистем функций и предотвращает ли она их взаимозависимость с другими подсистемами? Удалось ли вам сконструировать объекты, способные функционировать сравнительно независимо при помощи ограниченного числа вспомогательных объектов?

• Насколько доходчиво «перспективное представление» системы – сможет ли, скажем, продавец, прослушав краткий инструктаж, объяснить потенциальным клиентам, как работает программный продукт, который они намереваются приобрести?

• Исключается ли жесткое кодирование параметров конфигурации системы? К примеру, потребуется ли повторная компиляция программы при переименовании сервера или домена, или редактирования конфигурационного файла будет достаточно?

Обратите внимание на слово «наверняка», выделенное курсивом в последнем предложении абзаца, предшествующего списку. Почему я употребил именно это слово? Дело в том, что вы должны учитывать все факторы воздействия на систему на 1–2 года вперед. Невозможно выстроить надежный план действий, не зная коммерческой конъюнктуры. С другой стороны, разбираясь в тонкостях бизнеса, вы имеете все шансы стать предсказателем будущего своих программных продуктов.

Почему я говорю «предсказатель», а не, скажем, «прогнозист»? Объясняется это следующим образом. Термин «предсказатель» (prognosticator) образуется из двух греческих корней: pro, что в переводе означает «до», и gnosis, то есть «знание». Нельзя точно знать, что произойдет в будущем, однако, как и специалисты, составляющие прогнозы погоды, чем больше мы практикуемся по части предсказаний, тем лучшие результаты получаем. Не стоит также забывать, что создание программных продуктов – это искусство, которое постепенно приобретает очертания науки. Любая наука начинается с исследования явлений (феноменологии). В контексте разработки программных средств эта деятельность сводится к документированию всех явлений, наблюдаемых в ходе процесса, и построению эталонов. По мере исполнения этой миссии начинают выкристаллизовываться закономерности, согласно которым у нас что-то получается или, наоборот, не получается. В конце концов нам удается сформулировать принципы кодирования. Когда кому-нибудь это удается, он присваивает новому принципу свое имя, публикует книгу и наслаждается признанием. Именно этим в последнее десятилетие занимались разработчики концепции позитивных (pattern) и негативных (antipattern) эталонов, в связи с чем ваши шансы на славу теперь минимальны.

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

Итак, вы готовы запустить маховик проектирования. Теперь дела должны пойти в гору. То есть, я имею в виду, с горы. Да, я полон противоречий. Но ведь и процесс проектирования, как и жизнь, похож на американские горки. Попытайтесь получить удовольствие от поездки, смакуйте азарт и не забудьте вернуться живым. Мне кажется, процесс проектирования в его лучшем понимании правомерно сравнить с катанием на винтообразной (в противоположность круговой) трассе. В ней есть начало и конец, но в то же время вашему взору регулярно открываются одни и те же виды. А теперь сравните это удовольствие с падением с водопада, когда вас несет вниз по реке, потом вы оказываетесь в свободном полете и, наконец, шлепаетесь пятой точкой об воду, рассчитывая при этом остаться в живых. Такое впечатление, что вы работаете в парке аттракционов, не так ли?

Нет, тут я неправ; слово «развлечение» (amusement), опять же, образуется из двух греческих составляющих: а, что означает «нет», и muse в значении «думать». Я, равно как и ваш начальник, все-таки надеюсь, что в процессе проектирования вы думаете. В данный момент я пытаюсь доходчиво объяснить различия между устаревшим водопадным циклом разработки и разрекламированным в последнее время итеративным циклом. Я убежденный сторонник последнего – несмотря даже на то, что иногда он кажется бесконечным. Как бы там ни было, если вы стремитесь к эффективному проектированию, необходимо неизменно придерживаться архитектурного плана. Существует множество книг, проводится множество семинаров, на которых нас учат «правильным» методам проектирования. Некоторые из них действительно очень полезны. Лучшим же методом проектирования мне представляется тот, которым вы и ваши подчиненные уже привыкли пользоваться, и заключается он в решении корпоративных задач. Если вы еще не достигли в этом отношении больших успехов, не стоит себя корить. Наша работа не обходится без трудностей. Некоторые из нас совершенствуются, иные же через пару лет просто исчезают из поля зрения. Это жестокий мир, так что крепитесь и стремитесь к совершенствованию своих методов.

В предыдущем абзаце я обратился к метафоре из Дарвина по поводу того, что выживает сильнейший. Родившийся в XIX веке, этот замечательный принцип и поныне применяется при оценке корпоративной культуры и деятельности сотрудников предприятий. Во многих случаях он вполне адекватен; не будем, впрочем, забывать о других концепциях из области эволюционной биологии, в частности об адаптации. В настоящее время зарождается новый подход к адаптации. Предлагают его те исследователи, которые занимаются вопросами поведения сложных систем и принципами самоорганизации в таких системах. Стюарт Кауфман (Stuart Kauffman), один из ведущих специалистов в этой области, утверждает, что «…как биологическая, так и технологическая эволюция представляет собой процессы, направленный на оптимизацию систем с конфликтующими ограничениями»[66]. Для более осмысленного освещения вопросов выживания организмов и их существования в хаосе сложных систем Кауфман предлагает выражение «поступление сильнейших». Вооружившись его видением проблемы, исследователи привязали его выводы к процессы разработки программных продуктов.

Прекрасный образец применения теории сложных систем в области разработки программного обеспечения являет собой книга Джеймса Хайсмита (James Highsmith) под названием «Адаптивная разработка программных средств». Хайсмит предлагает вниманию читателя итеративный цикл, который он называет «жизненным циклом адаптивной разработки». В нем три основных компонента: сотрудничество, размышление и обучение. С его точки зрения, у этого цикла есть ряд преимуществ[67]:

• реагируя на периодические отзывы, приложения эволюционируют, приближаясь тем самым к предъявляемым заказчиками требованиям;

• упрощается адаптация к изменяющимся бизнес-требованиям;

• процесс разработки подгоняется под заданный для данного продукта профиль качества;

• преимущества от применения продукта заказчик получает раньше, чем обычно, – хотя бы за счет того, что приложение поставляется ему быстрее, а значит, он раньше начинает получать доход;

• заказчики раньше, чем обычно, начинают испытывать доверие к проекту.

Какое отношение все это имеет к проектированию? В любом случае в вашей компании применяется какой-то метод проектирования – он либо адекватен, либо требует усовершенствования, либо не годится для решения поставленных задач. Возможно, требуется его немедленная замена. Решение за вами. Я считаю, вы должны проявить инициативу, проанализировать применяемые в компании методы проектирования и подогнать их под заведомо работоспособные образцы.

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

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

• Следование стандартам программирования, принятым для данного языка[68]. Это обеспечивает единообразие методик конструирования объектов, применяемых разными программистами. (В этом контексте имеет полное право на существование метафора строительства.)

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

• Ограничение взаимозависимости объектов. В отсутствие серьезных аргументов в пользу иной точки зрения взаимозависимость приносит одни неприятности, превращая сопровождение в сплошной кошмар[69]. Чтобы однажды сделанные взаимозависимыми объекты превратить в независимые, требуются дополнительные временные и финансовые ресурсы.

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

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

Обширная библиотека должна быть в ваших мозгах – лишь при таком условии вы сможете взвешенно организовать процесс проектирования.

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

Теперь вернемся к конкретике: есть ли у меня какое-то универсальное решение? Есть, и я о нем уже говорил: сосредоточьтесь и лидируйте. О том, как сосредоточиться, мы рассуждаем в этой главе. Что же касается лидерства – думайте сами. В конце концов, роль лидера в вашей компании по праву принадлежит вам – так что играйте ее убедительно. Как говорил Шекспир, «весь мир театр, и люди в нем актеры».

Знание – это лишь исходное условие; по мере накопления опыта вы должны стремиться к принятию взвешенных решений, последовательно культивировать качества лидера.

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

Мы только что приступили к работе над новой программой последовательной связи, и наш отдел продаж требовал поставить ее как можно быстрее. В те времена такого понятия, как отдел тестирования, еще не существовало – штат сотрудников проекта ограничивался кодировщиками, пытавшимися всеми силами успеть к срокам, установленным отделом продаж. Грег в нашей компании трудился уже довольно долго и, надо сказать, весьма успешно, поэтому к постоянному давлению привык. По крайней мере, мне так казалось. У него даже была репутация ценного сотрудника – в основном потому, что он единственный из нас всех умудрялся сопровождать код старых приложений, которые уже не продавались.

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

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

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

Какова мораль? Очевидно, она в том, чтобы не спать на работе. Но это еще не все. К сожалению, некоторые программисты не выдерживают нагрузки. Мы должны работать в высоком темпе, а с теми, кто за ним не поспевает, приходится прощаться. Это жестокая реальность. Надеюсь, у Грега все нормально, – ведь с тех пор я его ни разу не видел.

Переместимся из XVI в XX век – как говаривал Элиотт, «Это один из вариантов конца света/Без треска, но с воем»[70]. Не стоит делать программы по этому принципу. Для того чтобы избежать этого, вам придется играть роль кодового полицейского. Если выражаться более знакомыми терминами, вам предстоит проводить регулярные критические обзоры кода, направленные на проверку соответствия архитектурной базе и принципам проектирования. Вспомним принцип, который я сформулировал в главе 2, – без регулярных проверок нельзя рассчитывать на хорошие результаты. Именно поэтому критические обзоры кода так важны.

В ходе проведения обзора вам предстоит столкнуться с двумя трудностями. С одной стороны, против вас работает время; с другой – программисты зачастую слишком ревностно относятся к попыткам редактирования своего кода. В конце концов, в сутках всего 24 часа. Пытаться изменить это обстоятельство бесполезно, поэтому единственный выход – учиться использовать время рационально. О том, как наиболее эффективно распоряжаться своим временем, говорится в главе 4, посвященной организованности.

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

Вы вместе с вашими подчиненными должны работать так, как будто повязаны узами контракта. В качестве основных положений контракта при этом выступают коммерческие спецификации и ваше видение архитектуры; условия же контракта сводятся к принципам и методикам проектирования. Будучи программным полицейским, вы должны следить за корректностью разрабатываемого программного продукта, начиная от зародышевого состояния и вплоть до зрелости. Впрочем, довести программный продукт до состояния зрелости пока что не удается – при сегодняшнем технологическом уровне приложения останавливаются в своем развитии в подростковом состоянии. Ну, может быть, мы приближаемся к юношеству. Каждая компания по-своему уникальна, в каждой приняты собственные стандарты оценки зрелости продуктов[71]. Принципам оценки в программной инженерии посвящены многочисленные издания. Кейперс Джонс (Capers Jones) в своей книге «Applied Software Measurement»[72] утверждает, что наиболее успешные компании, работающие в сфере разработки программного обеспечения, отличаются шестью общими характеристиками.

1. Они проводят точные измерения продуктивности и качества программных продуктов.

2. Они тщательно планируют и оценивают программные продукты.

3. У них работают квалифицированные менеджеры и технические специалисты.

4. У них адекватные организационные структуры.

5. Они пользуются наиболее эффективными методами и инструментами разработки программного обеспечения.

6. Их сотрудники работают в достойных условиях.

Из всех этих характеристик наиболее важной Джонс считает первую. Именно здесь в полную силу проявляются преимущества критических обзоров кода.

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

В своем кратком обзоре основных принципов проектирования я акцентирую ваше внимание на трех аспектах: стандартах, связности и взаимозависимости. Рассмотрим соответствующие нарушения.

Везде ли проставлены комментарии? Сможет ли с их помощью новичок, не знакомый со структурой данного модуля, в нем разобраться? Предположим, вы пытаетесь проследить последовательность исправления ошибки, – можно ли это сделать по комментариям? Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля. Для того чтобы продолжить чье-то начинание, вы должны знать, почему ваш предшественник пошел именно тем путем, которым пошел. В этом вам помогут комментарии.

Соглашение по именованию. Следуют ли ему ваши подчиненные? Возможно ли, взглянув на имя переменной, с уверенностью судить о ее области действия? Отлаживать код, в котором для определения области действия предположительно неверного параметра приходится тратить по полчаса, невероятно трудно. Бывает и так, что имена процедур настолько длинны, что наводят на мысль о бесполезности или даже вредности введения длинных имен файлов в Windows. Быть может, они, напротив, настолько коротки, что для расшифровки имен подпрограмм приходится прибегать к словарю? Между этими крайностями нужно найти баланс – кто знает, может быть, для этого вам придется провести урок грамматики и объяснить своим подчиненным, чем глагол отличается от существительного. Я понимаю, что префикс «get» в именах подпрограмм, извлекающих данные, утомляет; но его наличие безусловно свидетельствует о том, что они что-то извлекают. То же самое можно сказать о префиксе «set». Простота во многих случаях – синоним практичности.

Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля.

Соглашение по именованию и комментарии к коду предоставляют нам возможность употреблять в процессе написания кода единый язык. Не позволяйте своим подчиненным прибегать к «технологии безмолвия». Заставьте их должным образом расставлять комментарии и присваивать имена. Далеко не всегда разработчики отказываются от комментариев из-за спешки – иногда они сами плохо понимают, что сделали (например, скопировав готовый код из библиотеки и понадеявшись на авось). Бывает, они копируют комментарии, сделанные автором библиотеки, к которой они обращаются. Это много о чем говорит. Конечно, в основном про комментарии забывают из-за неуверенности в результате или из-за элементарной лени. Несколькими пометками в коде ситуацию не исправить. Такие явления зачастую означают значительно более серьезную проблему, с которой столкнулся кодировщик и решать которую нужно на более высоком административном уровне.

Среди прочих распространенных нарушений стандартов – применение подпрограмм с несколькими точками выхода, а также введение ненавистного оператора GoTo. (Программистам VB эту привычку можно простить – благо в NET операторы Try, Catch и Finally включены в библиотеку.) Еще один распространенный недочет – регулярное отсутствие обработки ошибок. Некоторые убежденные в своей непогрешимости кодировщики считают обработку ошибок пустой тратой времени. Действительно, в некоторых случаях перехватить ошибку вверху цепочки вызовов вполне достаточно; в то же время неумение выявлять потенциальные источники ошибок свидетельствует об отсутствии у кодировщика навыков стратегического мышления.

Возвращаясь к перечню отличительных черт различных пород программистов, приведенному в главе 1, замечу, что с его помощью удобно выявлять и другие нарушения, допускаемые вашими подчиненными. Этот список можно продолжать бесконечно в зависимости от конкретного кадрового обеспечения[73]. Я лишь хочу заметить, что, исполняя роль кодового полицейского, вы обязаны фиксировать имена тех, кто нарушает правила.

Слабая связность и сильная взаимозависимость – две области нарушений, которые допустимо рассматривать совместно, поскольку наличие одного предполагает наличие другого. Имеет ли в процедурах место обширное ветвление? Сильную взаимозависимость между процедурами обычно называют ветвлением по входу-выходу. При высокой степени ветвления по выходу функционирование процедуры предполагает обращение к множеству других процедур, что, естественно, нежелательно. Ветвление по входу, напротив, оказывает положительное воздействие, так как свидетельствует о строгой инкапсуляции. Общую оценку серьезности нарушений по части связности и взаимозависимости можно дать исходя из степени несоответствия основным объектно-ориентированным принципам.

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

Заметив нарушения, вы должны приостановить процесс кодирования, пока нарушители не исправят ситуацию. Чем дольше нарушения будут игнорироваться, тем выше вероятность того, что код придется отправить прямиком на помойку[74]. Когда разработчики обнаруживают халтуру своих коллег, они невольно опускаются до того же уровня – это человеческая природа, ничего не поделаешь. Если владение оружием предполагает употребление обоих рук, то грамотное проведение критических обзоров кода требует пресечения деятельности нарушителей за счет авторитета руководителя.

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

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

Делайте то, что считаете нужным.

Некачественная или случайная архитектура приводит к таким последствиям:

• сверхтрудное сопровождение и низкая оперативность (а следовательно, финансовые потери) при введении новых свойств;

• нежелание программистов заниматься сопровождением кода вследствие чрезмерной усложненности системы и неуверенности относительно первоочередных действий при исправлении ошибок и введении новых свойств;

• размывание кода из-за лавинообразного роста числа объектов, за счет чего при увеличении размера исполняемых файлов сокращается производительность.

Ниже перечислены последствия неадекватного проектирования:

• из-за несоблюдения стандартов создается впечатление, что все объекты создавались разными программистами;

• модификация в одном месте приводит к нарушению в нескольких других;

• вследствие многократного дублирования кода для изменения любой функции требуется найти и также изменить все ее экземпляры.

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

Я не большой поклонник школы позитивного мышления и все-таки несколько лет назад меня заинтересовала книга о Леонардо да Винчи. Ее автор вознамерился научить читателя мыслить как Леонардо. Поскольку Леонардо широко известен, позволю себе называть его просто по имени. Билл Гейтс истратил кучу денег (которые он предварительно выкачал из нас за свои программы) на оригиналы дневников Леонардо. Этим все сказано. Леонардо был невероятно умен. Если вы всерьез заинтересуетесь его биографией (а для этого мало прочитать единственную книжку из серии «помоги себе сам»), то быстро поймете, что его творческий гений направлялся жизненной философией. Эту самую философию Майкл Гелб (Michael Gelb) вкратце сформулировал следующим образом[75].

• Неизменно любознательный взгляд на жизнь и сильнейшее стремление к постоянному обучению.

• Привычка проверять знания через опыт, настойчивость и готовность учиться на ошибках.

• Последовательное совершенствование восприятия действительности органами чувств (в особенности, зрением) как средство обогащения жизненной практики.

• Готовность к восприятию неясностей, парадоксальных явлений и неопределенности.

• Уравновешивание науки и искусства, логики и воображения. Мышление «всем интеллектом».

• Воспитание изящества в движениях, «двуправорукости», физического здоровья и поведения.

• Признание и понимание взаимосвязи между всеми вещами и явлениями. Системное мышление.

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

Влияние Леонардо на современную ему технологию впечатляет. Трудно себе представить, как один человек смог выдумать все те изобретения, которые он набросал в своих дневниках, а частично и реализовал. Очевидно, в этом ему помогла его жизненная философия. Что делает ее такой действенной? Уверен, что ни одна из ее составляющих не сыграла такой роли, как сбалансированное сочетание различных векторов его мышления.

Взять, например, его тягу к знаниям в сочетании с терпимостью к неопределенности. Убежденный в том, что опыт – лучший учитель, он постоянно совершенствовал свои воззрения с тем, чтобы улучшить наблюдательность. Леонардо воспитал целую плеяду последователей, уделяя значительное время оценке их достижений. Быть может, он был первым, кто пользовался принципом системного мышления – а ведь это именно то, к чему мы, специалисты по проектированию программных продуктов, неизменно стремимся. Этот принцип предполагает следование установленному плану вплоть до его окончательной реализации. Он имеет непосредственное отношение к тому, о чем я уже говорил, – к комплексной проверке архитектуры, предваряющей ее исполнение в виде подсистем-компонентов.

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

Крайне рекомендую на досуге почитать Леонардо – надеюсь, это поможет вам на практике проводить в жизнь стройную систему деятельности. Вполне возможно, побудить вас к действию смогут биографии современных лидеров нашей индустрии[76]. Полезно также ознакомиться с историями успеха деятелей других отраслей экономики. Удивительно, но факт: они в своей деятельности сталкиваются с теми же проблемами, что и мы. Короче говоря, биографическая литература – это неплохой выбор для чтения перед сном. По крайней мере, она поможет вам отдохнуть от повседневного чтения трудов по ADO 2.1, MTS MSMQ, VB, ASP, HTML 4.0 – видимо, их авторы считают, что заумная аббревиатура на корешке завлекает покупателя[77]. Кто знает, быть может, биография Джуди Гарланд (Judy Garland) напомнит вам, что как программист, руководящий другими программистами, вы не в Канзас-Сити.

Умирая, Леонардо понимал, что труд его жизни остался незаконченным. Это жестокая реальность. Тем не менее я призываю вас стремиться к самосовершенствованию и, руководствуясь полюбившимися философскими воззрениями, каждую неделю делать немного больше полезных дел. Между знанием и действием в нашей рабочей действительности огромная пропасть. Это своеобразное состязание между эпистемологией и онтологией. Факт тот, что изначально мы предрасположены к бездействию; однако, в конце концов, происходит что-то, что заставляет нас воскликнуть: «Хватит с меня этих проблем в коде!» – и наконец сделать что-нибудь стоящее.

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

• Удается ли вам последовательно играть роль технического лидера? Я совершенно не хочу сказать, что ваши идеи всегда должны быть на порядок лучше чужих, – просто ваши обязанности иные, к ним относятся отбор наиболее удачных идей и их практическая реализация.

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

• Смогли ли вы за счет своих проектных решений обеспечить возможность многократного использования компонентов? Может ли любой сотрудник вашей группы взять модуль, разработанный другим сотрудником, и успешно справиться с его сопровождением или расширением функциональности? Ответы на эти вопросы свидетельствуют о ваших достижениях по части организации и руководства проектной деятельностью.

• Как вы обращаетесь с выявленными недостатками кода – устраняете их сразу на стадии разработки или ведете журнал фрагментов кода, требующих переработки?

• Способствует ли здоровая критика действий ваших подчиненных повышению их квалификации?

• Что вы предпочитаете – умные разговоры или практические действия? Помните ли вы, что нереализованные философствования бесполезны?

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

Техническое лидерство взращивается на почве знания и питается готовностью учиться на собственных ошибках – в конечном итоге такая практика обязательно увенчается успехом.

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

Примечания:

5

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

6

А ведь это очень важно – согласно авторитетным оценкам, по меньшей мере 70 % стоимости программного обеспечения приходится на сопровождение. См. William Н. Brownctal, AntiPatterns: Refactotoring Software, Architectures, and Projects in Crisis (New York: John Wiley & Sons, 1998), p. 121.

7

Некоторые предпочитают называть программиста этого типа «гуру» или «спецом». А мне больше нравится «волшебник».

58

И строительство, и конструирование выражаются в английском языке одним словом – construction. Поэтому нам при переводе пришлось в меру сил лавировать между этими двумя значениями. Таким вот печальным образом гипертрофированная метафоричность автора разбивается об языковой барьер. – Примеч. перев.

59

Andrew Hunt and David Thomas, The Pragmatic Programmer (New York: Addison-Wesley, 2000), p. 184.

Перевод на русский язык: http://www.ozon.ru/context/detail/id/1657382/ (прим. сост. FB2)

60

Рекомендую в этом контексте ознакомиться с работами апологетов позитивных и негативных эталонов, например с трудами Брауна (Вroun) и других исследователей, чьи публикации перечислены в библиографии.

61

Marc Т. Sewell and Laura М. Sewell, The Software Architect's Profession (Upper Saddle River, NJ: Prentice Hall, 2002), p. 68.

62

Raphael С. Malvcau and Thomas Mowbray, Software Architect Bootcamp (Upper Saddle River, NJ: Prentice Hall, 2001).

63

Как просто, оказывается, вернуться к привычной терминологии! Если бы я сказал «…в выращивании применяются старые технологии…», смогли бы вы понять, о чем я говорю?

64

Ах, какой я молодец, что подобрал анатомическую метафору!

65

Лично я пользуюсь VB, начиная с версии 1.0, поэтому никаких предрассудков против этого языка не питаю. Всем интересующимся проблемами создания архитектуры и проектирования средствами VB рекомендую ознакомиться с работой Billy S. Hollis, Visual Basic 6 Design, Specification and Objects (Upper Saddle River, NJ: Prentice Hall, 1999).

66

Stuart Kauffman, At Home in the Universe (New York: Oxford University Press, 1995), p. 179.

67

James A. Highsmith III, Adaptive Software Development (New York: Dorset House Publishing, 2000), p. 40.

68

«Стандарты программирования» – выражение многозначное. Диапазон его значений простирается от инструкции по написанию качественной процедуры до утверждения единственной точки выхода из подпрограммы. Список этот можно продолжать бесконечно. Объединяющий принцип прост – заведите стандарт и придерживайтесь его.

69

Что такое кошмар для программиста? Это когда он вынужден не спать всю ночь, исправляя код, в котором, внеся одно исправление в одном объекте, получает изменение в трех местах другого объекта.

70

T.S. Elliot, Collected Poems 1909–1962 (New York: Harcourt Brace Jovanovich, 1971), p. 82.

71

См. Humphrey, op. cit., p. 5.

72

Capers Jones, Applied Software Measurement (New York: McGraw-Hill, 1991), p. 1.

73

Специалистам по VB я рекомендую труд James D. Foxall, Practical Standards for Microsoft Visual Basic (Redmond, WA: Microsoft Press, 2000). Что касается других языков, выбор литературы обширен; взять хотя бы классическое издание по С – Steve Maguire, Writing Solid Code (Redmond, WA: Microsoft Press, 1993). Дополнительную литературу см. в библиографии.

74

См. Hunt and Thomas, op. cit. – авторы обозначают хаотичность в разработке программных продуктов изысканной метафорой: «не надо жить с разбитыми окнами». Я более чем уверен, что эта книга обязательно должна занять достойное место в вашей библиотеке, – уж очень она хороша.

75

Хотите верьте, хотите нет, но я эту книгу прочел. Michael J. Gelb, How to Think Like Leonardo da Vinci (New York: Dell Publishing, 1998), p. 9.

76

Есть одна восхваляющая амбициозность книга, которая мне очень нравится. James Champy and Nitin Nohria, The Arc of Ambition (New York: Perseus Books, 2000).

77

Кстати, это неплохой маркетинговый прием – по крайней мере, я такие книги покупаю.