Отправлено: 01.05.10 07:49. Заголовок: vr-online//Какие бывают породы программистов

Какие бывают породы программистов

Распространенные породы
Архитектор. Большинство руководителей обожают этот тип программистов — и, действительно, любой такой деятель окажется ценным приобретением для вашей команды. В основном архитекторы концентрируются на общей структу-ре кода. Они мыслят объектами, а их лучший друг — лист белой бумаги. Посвя-щая себя без остатка решению бизнес-задач, они строят абстракции, проводят анализ систем, после чего переходят к кодированию конкретных решений.

Слов нет — все это очень важные элементы программирования, но для комплексного выполнения задач их еще не достаточно. Зачастую в высшей степени разумные замыслы архитектора воплощаются в настолько общем и непонятном коде, что людей, могущих разобраться в нем и продолжить начинание, просто не нахо-дится. Особи, способные генерировать удачную идею в голове (а лучше в Visio, а затем выполнить ее полноценную конкретизацию в коде, становясь, таким образом, единственными участниками процесса, встречаются очень редко. Не-достаток архитекторов в том, что их код часто служит только одному хозяину, а исполнять чужие команды категорически отказывается 1. Некоторые архитек-торы очень любят набросать структуру кода, с тем чтобы впоследствии пере-дать его на растерзание программистам более «низкой» квалификации. Иногда в коде, написанном архитекторами, встречаются весьма странные конструк-ции — например, окна с сообщениями о системных прерываниях из-за ошибок, появляющиеся по той лишь причине, что код предполагалось исполнять в виде библиотеки DLL на сервере.

Конструктивист.

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

Художник.

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

Инженер.

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

Ученый.

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

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

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

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

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

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

Дворняги

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

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

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

Профан. Программист-профан — это тот, кого называют тупицей. Хуже всего, когда профан не догадывается о своей тупости. Остерегайтесь таких людей. Иногда они могут достаться вам в наследство от предыдущих руководителей, но сами, я вас прошу, никогда их не нанимайте. У меня нет никаких предубеж-дений относительно умственно ущербных людей, но я твердо уверен, что в про-фессии, требующей постоянного самосовершенствования и обучения, таким не место. Если человек невежда, но хочет стать лучше, — дайте ему шанс. Отправьте его, например, в отдел тестирования — иногда не отличающиеся выдающимися умственными способностями пользователи находят себя в отлове жучков. Еще одно соображение насчет глупости: на самом деле все мы постоянно страдаем от несовершенства того, что находится между клавиатурой и стулом. Но, в кон-це концов, если бы для написания кода не требовались мозги, этим занимались бы все без разбору, так ведь? Я советую не путать невежество с глупостью. Не-вежество исправимо, а с глупостью лучше просто не связываться. Если вы уна-следовали кадры, подобранные не программистом, вполне возможно, что среди ваших подчиненных есть такие типажи. Руководители, имеющие весьма отда-ленное представление о технологии, иногда покупаются на необоснованные заверения бездарных претендентов на место.

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

Обзор составлен DmT по мотивам книги Дж. Ханк Рейнвотера "Как пасти котов"