Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

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

В этот день я получил первое предупредительное письмо. В нем мне предлагалось немедленно изменить свое отношение к работе, иначе «последует немедленное увольнение». Я был в ужасе!

Мне пришлось проанализировать свое поведение и понять, что же я делал не так. Я поговорил с Джоном и Ральфом с твердым намерением изменить себя и свой стиль работы.

И я это сделал! Я перестал опаздывать, начал обращать внимание на внутреннюю политику. Я начал понимать, почему Джон беспокоился по поводу Стенберга. Я понял, как подвел его, оставив на понедельник неработоспособную систему.

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

Еще через несколько недель мне сообщили об увольнении.

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

У программистов часто возникают трудности при работе в тесном контакте с другими программистами. Порой это создает серьезные проблемы.

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

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

Каждый программист работал над своей системой. Один писал код для системы подачи листов, другой – код для системы сшивания и т. д.

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

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

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

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

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

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

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

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

Однажды утром на самом пике бума интернет-коммерции я приехал на поезде в Чикаго. Когда я ступил на платформу, мне в глаза бросился огромный плакат над выходом. Хорошо известная фирма-разработчик приглашала на работу программистов. На плакате было написано: «Поработайте мозжечком рядом с лучшими!»

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

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