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

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

66

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

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

67

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

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

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

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

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

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

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

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

Принципы проектирования

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

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

68

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

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

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

69

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

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

Принципы успеха

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

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

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

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

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

Кошачьи разборки

Не спи за рулем!

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