Как пасти котов. Наставление для программистов, руководящих другими программистами

Рейнвотер Дж.Ханк

Глава 6

Философия и методы технического лидера

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

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

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

Как уразуметь свою техническую роль и придерживаться ее

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

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

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

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

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

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

Конструировать или выращивать

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

58

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

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

59

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

Перевод на русский язык:(прим. сост. FB2)

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

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

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