Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО
Не могу описать, насколько меня это бесило. Я ощущал глубочайшее раздражение. Я носил галстук каждый день и ненавидел его. Но почему? Ведь я знал, куда я поступаю на работу. Я знал принятые правила. Почему меня это раздражало? Потому что я был эгоистичным, самовлюбленным типом.
Я просто не мог приходить на работу вовремя. И мне казалось, что это не важно. В конце концов, я «хорошо справлялся». И это было правдой: я действительно очень хорошо справлялся с написанием своих программ. Бесспорно, я был лучшим программистом в группе. Я мог писать код быстрее и лучше других. Я быстрее находил и устранял проблемы. Я знал, что я был ценным специалистом, так что время и даты для меня значили мало.
Решение о моем увольнении было принято тогда, когда я опоздал на одну из контрольных точек проекта. По всей видимости, Джон сказал нам, что в следующий понедельник ему нужна демо-версия рабочих функций системы. Наверняка я знал об этом, но просто не обратил внимания.
Система находилась в стадии активной разработки. До реальной эксплуатации было еще далеко. Не было причин оставлять систему в рабочем состоянии, когда в лаборатории никого не было. Я последним уходил с работы в пятницу, и, видимо, я оставил систему в неработоспособном состоянии. Тот факт, что понедельник был важной датой, просто не отложился у меня в памяти.
В понедельник я пришел на час позже и увидел, как все мрачно собрались вокруг нерабочей системы. Джон спросил: «Почему система не работает сегодня, Боб?» Я ответил: «Не знаю», и сел за отладку. Я даже тогда не вспомнил о демо-версии, запланированной на понедельник, но по поведению моих коллег было совершенно ясно, что произошло что-то нехорошее. Тогда Джон подошел ко мне, прошептал на ухо: «А если бы пришел Стенберг?» и отошел в негодовании.
Стенберг был вице-президентом по автоматизации. Сегодня его должность назвали бы «руководителем технической службы». Вопрос показался мне бессмысленным. «Ну и что? – подумал я. – Система же не в эксплуатации, так в чем проблема?»
В этот день я получил первое предупредительное письмо. В нем мне предлагалось немедленно изменить свое отношение к работе, иначе «последует немедленное увольнение». Я был в ужасе!
Мне пришлось проанализировать свое поведение и понять, что же я делал не так. Я поговорил с Джоном и Ральфом с твердым намерением изменить себя и свой стиль работы.
И я это сделал! Я перестал опаздывать, начал обращать внимание на внутреннюю политику. Я начал понимать, почему Джон беспокоился по поводу Стенберга. Я понял, как подвел его, оставив на понедельник неработоспособную систему.
Но было слишком поздно. Через месяц я получил второе предупреждение по поводу какой-то тривиальной ошибки. В этот момент мне следовало понять, что письма были простой формальностью, а решение об увольнении уже было принято. Но я твердо решил все исправить и работал еще прилежнее.
Еще через несколько недель мне сообщили об увольнении.
Мне пришлось идти домой к своей беременной 22-летней жене и рассказывать, что я потерял работу. Мне бы не хотелось, чтобы такое когда-нибудь повторилось в моей жизни.
Программисты и программисты
У программистов часто возникают трудности при работе в тесном контакте с другими программистами. Порой это создает серьезные проблемы.
Принадлежность кода
Один из худших признаков неправильно функционирующей команды – когда каждый программист возводит стену вокруг своего кода и запрещает другим программистам прикасаться к нему. Я был в местах, где программисты даже запрещали другим смотреть на свой код. Это верный путь к катастрофе.
Однажды я консультировал компанию, производившую высококлассные принтеры. Машины состояли из множества разных компонентов: систем подачи бумаги, печати, укладки бумаги, сшивания листов, резаков и т. д. С точки зрения бизнеса эти системы обладали разной ценностью. Система подачи листов была важнее системы укладки, но ни одно устройство не могло сравниться по важности с системой печати.
Каждый программист работал над своей системой. Один писал код для системы подачи листов, другой – код для системы сшивания и т. д.
Все они бдительно охраняли свою технологию и не позволяли никому притрагиваться к своему коду. Политический вес программистов был напрямую связан с коммерческой ценностью устройства. Программист, работавший над устройством печати, обладал непререкаемым авторитетом.
Для технологии такое положение дел имело катастрофические последствия. Мне, консультанту, было хорошо видно массовое дублирование кода и разнобой в интерфейсах между модулями. Но никакие аргументы с моей стороны не могли убедить программистов (или представителей бизнеса) изменить подход к работе. Ведь их зарплата была связана с важностью устройств, которыми они занимались.
Коллективная принадлежность кода
Разрушьте стены принадлежности кода – код должен принадлежать всей группе. Я предпочитаю работать с группами, в которых любой участник может проверить любой модуль и внести те изменения, которые сочтет нужным. Я предпочитаю, чтобы код принадлежал группе, а не конкретным людям.
Профессиональные разработчики не запрещают коллегам работать со своим кодом. Они не возводят вокруг своего кода стены принадлежности. Напротив, они стараются работать друг с другом над как можно большей частью кода. И работая над другими частями системы, они учатся друг у друга.
Парное программирование
Многие программисты не любят идею парного программирования. Мне это кажется странным, потому что в напряженных ситуациях большинство программистов объединяется в пары. Почему? Потому что парное программирование очевидным образом является самым эффективным способом решения задачи. Вспомните старую поговорку: «Две головы лучше, чем одна». Но если парное программирование является самым эффективным способом решения задач в напряженных ситуациях, с чего бы ему не быть самым эффективным способом решения задач в нормальное время?
Я не собираюсь цитировать научные исследования, хотя у меня в запасе найдется немало подходящих цитат. Я не буду рассказывать «случаи из жизни», хотя и их у меня тоже предостаточно. Я даже не собираюсь указывать, какую часть времени следует проводить за парным программированием. Скажу одно – профессионалы работают в парах. Почему? Потому что по крайней мере для некоторых задач эта методология наиболее эффективна. Впрочем, это не единственная причина.
Профессионалы также объединяются в пары, потому что это лучший способ обмена знаниями. Профессионалы не создают «банки знаний» – вместо этого они изучают разные аспекты системы и бизнеса, объединяясь в пары. Они понимают, что хотя у каждого участника группы имеется своя должность, все участники должны быть готовы моментально переключаться в случае необходимости.
Профессионалы объединяются в пары, потому что это лучший способ рецензирования кода. Ни в одной системе не должно быть кода, который не был прорецензирован другими программистами. Существует много механизмов рецензирования кода; в большинстве своем они ужасающе неэффективны. Самый эффективный и действенный способ рецензирования кода – участие в его написании.
Как работать мозжечком
Однажды утром на самом пике бума интернет-коммерции я приехал на поезде в Чикаго. Когда я ступил на платформу, мне в глаза бросился огромный плакат над выходом. Хорошо известная фирма-разработчик приглашала на работу программистов. На плакате было написано: «Поработайте мозжечком рядом с лучшими!»
Столь выдающаяся глупость меня поразила. Жалкие бестолковые рекламщики пытались произвести впечатление на умных, эрудированных, технически грамотных программистов – на людей, которые плохо переносят глупость. Рекламщики пытались создать впечатление, будто на новой работе вы будете обмениваться знаниями с другими умными людьми. К сожалению, упомянутая в рекламе часть мозга – мозжечок – отвечает за координацию движений, а не за интеллект. И те люди, которых пытались привлечь этой рекламой, только ухмылялись над глупой ошибкой.
Но в этой рекламе меня заинтриговало другое. Я представил себе группу людей, пытающихся «поработать мозжечком». Поскольку мозжечок находится в задней части мозга, я представил себе группу программистов, рассевшихся по кабинкам затылками друг к другу, уставившихся на мониторы и оградившихся от внешних раздражителей наушниками. Это нельзя назвать группой.
Профессионалы работают вместе. Невозможно работать вместе, рассевшись по углам с наушниками. Участники группы должны сидеть за общим столом, повернувшись друг к другу лицом. Они должны чувствовать опасения своих коллег, слышать их раздраженное бормотание. Между ними должно идти постоянное общение – как вербальное, так и на уровне «языка тела». Они должны взаимодействовать как единое целое.
