Как пасти котов. Наставление для программистов, руководящих другими программистами - Дж.Ханк Рейнвотер

Ученый. Ученые – это мальчики и девочки, которые считают себя последователями Бэббиджа и Тьюринга. Никогда в жизни они не вставят в код инструкцию GoTo. Отодвигая художественную составляющую программирования на второй план, они делают все в соответствии с фундаментальными принципами компьютерных наук. И как раз в этом обычно и заключается проблема. В то время как они одержимы безупречностью своих трудов, ваша главная забота как руководителя состоит в том, чтобы разработать доброкачественный продукт и сдать его к установленному сроку. Программисты такого типа на самом деле очень полезны, и когда речь заходит об особо трудных задачах кодирования, их идеям нет цены. Вы просто должны следить за тем, чтобы их педантичность не перевесила практические соображения. У инженеров и ученых есть одна общая черта – те и другие очень любят все усложнять. Иногда даже кажется, что они все поклоняются богу сложности (и даже приносят ему жертвы!).

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

Лихач. Лихачи – это те товарищи, которые делают все быстро. Забывая о комментариях, отступах и соглашениях об именовании переменных, они, тем не менее, умудряются достигать результата очень оперативно – и, что самое замечательное, вплоть до первой неперехваченной ошибки их продукты вполне успешно работают. Иногда такое поведение характерно для молодых программистов, горящих желанием впечатлить вас, – они опрометчиво считают, что оперативность в достижении результата в полной мере соответствует вашим ожиданиям. Признайтесь: мы часто сами выстраиваем у них столь ложное представление, а значит, веди мы себя по-другому, никаких лихачей не было бы. Наши собственные начальники устраивают совещания, на которых устанавливают контрольные сроки, а потом сообщают их нам. Как мы добьемся выполнения поставленных временных задач – это уже наша проблема. Вспомните, как часто идут разговоры о бессмысленности установления крайних сроков кодирования до окончательного выяснения всех требований! Так вот, вам придется к этому привыкнуть. К сожалению, такова реальность – пользователи и рыночные соображения часто принуждают нас сперва давать обещания, а потом уже приступать к планированию. Именно по этой причине вы читаете мою книгу – вам нужны советы по поводу того, как выжить в динамичном, жестоком и суровом мире разработки программных средств.

Далее я привожу список редких пород и их отличительных черт.

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

Минималист. Несмотря на удивительно скромный объем кода, производимого минималистами, код обычно оказывается очень функциональным. Каждая процедура умещается в редакторе кода на одном экране. Объекты стройны, выстроены четко и недвусмысленно сообщают о своем назначении. Звучит неплохо, не правда ли? В общем, да, только стоило бы учитывать мотивы такого поведения. Ведь иногда они кроются в том, что человеку хочется побыстрее разобраться с текущим проектом и перейти к следующему, который его больше захватывает. Иногда (кстати говоря, эта характеристика распространяется и на архитекторов) минималисты, решив поставленную задачу, быстро теряют к ней всякий интерес, и уж, конечно, при обнаружении в ходе альфа-тестирования каких-либо проблем выказывают устойчивое нежелание их исправлять. Иногда минималисты капризны и очень придирчиво выбирают область приложения своих сил. С сопровождением кода дела у них обстоят хуже всех.

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

Трюкач. Трюкачи слишком увлекаются разными технологическими трюками. Они постоянно осваивают разные новинки, но результат от этого не улучшается. По правде говоря, всех нас в той или иной степени привлекают забавные технологические приемы. Я вот, например, помню мой первый компьютер. Он был аналоговым, и, поворачивая диски, я переключал ветви в предустановленном аппаратном алгоритме. Эта штука была похожа на гипертрофированную логарифмическую линейку. В общем, я до сих пор люблю забавляться со всякими высокотехнологичными штуковинами. Если вам приходится работать с трюкачами, попытайтесь направить их увлечение игрушками на решение их первоочередной задачи, а именно на производство бизнес-решений. Если им удалось втиснуть на экран, который, как предполагается, будет отображаться с разрешением 800*600, 30 разных элементов пользовательского интерфейса, это еще совершенно не означает, что они решили свою задачу в соответствии с реальными потребностями пользователей[8]. Трюкачи, при всех их познаниях в технологии, часто не могут усвоить конечное назначение программы. Полагая, что их функции ограничиваются забавами с разными инструментальными средствами, они отказываются учитывать те аспекты программирования, благодаря которым мы не затрачиваем на сопровождение титанических усилий.

Остановимся теперь на дворовых породах и их отличительных чертах.

Разгильдяй. Что сказать о разгильдяях? Некоторые люди небрежны, и это проявляется в коде, который они создают. Они не обращают внимания на такие мелочи, как правильное написание имен переменных и правила венгерской нотации. Зачастую качественно выполнять свои обязанности им мешают проблемы личного плана. Тому, как пишется эффективный код, их нужно учить. Они любят начать с одного стиля, а через процедуру-другую перейти к новому. Читать их код очень утомительно – иногда поздними ночами его приходится переписывать, поскольку иначе есть риск не успеть к сроку сдачи проекта. Если вы не справились с задачей по их вине, прошу вас: отнеситесь к ним снисходительно. В конце концов, они просто отъявленные разгильдяи, которых лучше всего пересадить в отдел бета-тестирования. Хотя нет – так вы просто заморозите проблему, в итоге она все равно может проявиться. Если разгильдяй действительно любит писать код, при условии, что вы уделяете ему достаточно внимания, он имеет шансы реабилитироваться. Всех, кому это не удается, нужно просто пнуть под зад или познакомить с консультантом по трудоустройству.

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