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

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

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

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

Хороший трюк с телепатией приводит к тому, что люди начинают от тебя зависеть.

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

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

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

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

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

Руководство людьми и проектами — трудная и интересная работа. Люди, обеспечивающие бесперебойную работу над проектом без многочисленных указаний сверху, высоко ценятся постоянно занятыми начальниками и заказчиками. Правильно применяемый трюк с чтением мыслей приведет к тому, что люди начнут от тебя зависеть — отличный рецепт карьеры, направление которой ты выбираешь сам. Эту способность стоит осваивать и развивать.

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

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

Совет 21

Ежедневные победы

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

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

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

Мой друг и коллега Джеймс Макмурри[13] на заре нашей с ним карьеры поделился разработанной им системой, которая гарантировала хороший результат работы. Система поразила меня своей глубиной, особенно если учесть небольшой опыт ее создателя (возможно, он учел уроки, полученные от родителей), и я пользуюсь ею до сих пор. Не уведомляя руководство, он фиксирует хиты дня. Его задача — каждый день делать нечто такое, о чем можно было бы с гордостью доложить наверх. Это может быть пришедшая ему в голову идея или некое действие, могущее улучшить работу его отдела (см. Одна неделя хитов).

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

Понедельник. — Автоматизировать сборку!

Вторник. — Написать тесты для синтаксического разбора кода.

Среда. — Разобраться с инструментами объектно-реляционного проецирования, чтобы можно было больше вообще не писать SQL-запросы.

Четверг. — Написать сценарий развертывания веб-приложения.

Пятница. — Избавить проект от предупреждений компилятора.

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

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

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

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

Совет 22

Помни, на кого работаешь

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