Небольшая выдержка из книги «Как пасти котов», автор в прошлом программист поэтому его классификация мне показалась точной и смешной одновременно, немного отредактировал что бы убрать лишний контекст, в целом пост несет развлекательный характер и не претендует на точную классификацию.
Архитектор.
Большинство руководителей обожают этот тип программистов и, действительно, любой такой деятель окажется ценным приобретением для вашей команды. В основном архитекторы концентрируются на общей структуре кода. Они мыслят объектами, а их лучший друг лист белой бумаги.
Посвящая себя без остатка решению бизнес задач, они строят абстракции, проводят анализ систем, после чего переходят к кодированию конкретных решений.
Слов нет все это очень важные элементы программирования, но для комплексноrо выполнения задач их еще не достаточно. Зачастую в высшей степени разумные замыслы архитектора воплощаются в настолько общем и непонятном коде, что людей, могущих разобраться в нем и продолжить начинание, просто не находится.
Особи, способные генерировать удачную идею в rолове (а лучше в Visio), а затем выполнить ее полноценную конкретизацию в коде, становясь, таким образом, единственными участниками процесса, встречаются очень редко. Недостаток архитекторов в том, что их код часто служит только одному хозяину, а исполнять чужие команды категорически отказывается.
Некоторые архитекторы очень любят набросать структуру кода, с тем чтобы впоследствии передать его на растерзание программистам более «низкой квалификации.
Иногда в коде, написанном архитекторами, встречаются весьма странные конструкции например, окна с сообщениями о системных прерываниях из за ошибок, появляющиеся по той лишь причине, что код предполагалось исполнять в виде библиотеки DLL на сервере.
Конструктивист.
Конструктивисты получают удовольствие от процесса написания кода и его результата. Стратегическим планированием они себя утруждают не всегда, но факт в том, что с написанием кода они справляются быстро, причем в большинстве случаев ошибок в нем не обнаруживается даже на этапе альфа-тестирования.
Код конструктивисты пишут по наитию, а потому их логика не всегда понятна. У некоторых конструктивистов все в порядке и с интуицией, и со стратегическим планированием, поэтому код выступает естественным продолжением хода их мыслей. Но стоит попросить конструктивиста составить документацию, он обязательно ответит, что код самодокументируемый.
Впрочем, если на него немного надавить и дать понять, что без документции никуда не деться, он, вероятно, согласится ее составить - и сделает это качественно. Кто спорит - код должен быть самодокументируемым, но следует иметь в виду, что основное внимание программисты этого типа уделяют процессу создания кода, поэтому остальное для них не так уж важно. Количество сборок, которое конструктивист выдает за день, позавидует даже Microsoft.
Соответственно, их код обычно отличается надежностью. Однако по мере разбухания (а этот процесс неизбежен) надежность улетучивается, а конструктивист начинает судорожно искать новые, «заплаточные» решения - ведь для него очень важно видеть результат и пребывать в уверенности в том, что он справился с задачей.
Художник.
На самом деле, искусства в написнии кода не меньше, чем науки, не зря же университеты часто сводят оба направления в одной структуре и называют ее как-нибудь вроде «факультета свободных искусств и наук».
Не будет в программировании художественного аспекта, может быть, оно приносило бы нам гораздо меньше морального удовлетворения. Художник как тип программиста сконцентрирован на процессе создания кода - переносе коммерческих требования на программные конструкции и искусном сведении объектов пользовательского интерфейса в одну изящную структуру.
Работая с компонентами без видимо интерфейса, художники обнаруживают тенденцию к правильной и логичной организации. Недостаток художники в том, что очень часто он затягивает кодирование, пытаясь выяснить, сколько знаков равенства можно установить в одной строке, не нарушив при это правильность результата булева оператора.
С другой стороны, если программист не культивирует в себе художника результаты его деятельности зачастую отрываются от реальности, теряют «изюминку». Стоит отнять у художника все его отличительные качества, и в результате получится мина замедленного действия, которая обязательно взорвется.
Инженер.
Эти ребята имеют обыкновение скупать все возможные средства сторонних производителей, писать десятки COM-объектов и сводить их воедино, так что они прекрасно работают в версии 1.0, присущая им тяга к усложнению проявляется лишь тогда, когда речь заходит о версии 1.1.
Программирование часто приравнивают к инженерии программных средств - и, действительно, многие стороны нашей професии подчиняются этой методологии. Но давать инженерам карт-бланг нельзя. Инженеры любят все переусложнять.
Ученый.
Ученые - это мальчики и девочки, которые считают себя последователям Бэббиджа и Тьюринга. Никогда в жизни они не вставят в код инструкцию GoTo. Отодвигая художественную составляющая программирования на второй план, они делают все в соответствии с фундаментальными принципами компьютерных наук.
И как раз в этом обычно и заключается проблема. В то время как они одержимы безупречностью своих трудов, ваша главная забота состоит в том, что бы разработать доброкачественный продукт и сдать его к установленному сроку.
Программисты такого типа на самом деле очень полезны, и когда речь заходит об особо трудных задачах кодирования, их идеям нет цены. Нужно следить за тем, что бы их педантичность не перевесила практические соображения. У инженеров и ученых есть одна общая черта - и те и другие любят все усложнять.
Лихач.
Лихачи - это те товарищи которые делают все быстро. Забывая о комментариях, отступах и соглашениях об именовании переменных, они тем не менее, умудряются достигать результата очень оперативно - и, что самое замечательное, вплоть до первой неперехваченной ошибки их продукты вполне успешно работают. Иногда такое поведение характерно для молодых программистов, горящих желанием впечатлить.
Волшебник.
Каким-то загадочным образом те, кого я называю волшебниками, регулярно решают самые трудные задачи программирования, причем идут такими путями, которые раньше никому и в голову не приходили.
Более того - волшебники делают все это вовремя, и иногда у них получаются вполне доступные для понимания программы, которые можно сопровождать.
Но если полагаться на них слишком сильно, в один прекрасный день он разочарует - в конце концов, постоянно творить чудеса никому еще не удавалось.
Минималист.
Несмотря не удивительно скромный объем кода, производимого минималистами, код обычно оказывается очень функциональным. Каждая процедура умещается в редакторе кода на одном экране. Объекты стройны, выстроены четко и недвусмысленно сообщают о своем назначении.
Звучит неплохо, не правда ли? Иногда минималисты, решив поставленную задачу, быстро теряют к ней всякий интерес, и уж, конечно при обнаружении в ходе альфа-тестирования каких-либо проблем выказывают устойчивое нежелание их исправлять.
Иногда минималисты капризны и очень придирчиво выбирают область приложения своих сил. С сопровождением кода дела у них обстоят хуже всех.
Аналогист.
Это программист, который не слишком силен в абстракциях, но прекрасно справляется с аналогиями. Во время проектных совещаний аналогисты постоянно выдумывающие все новые и новые аналогии, способны свести с ума любого.
Но при этом нельзя не признать, что, как правильно они очень быстро схватывают суть задачи и в результате создают удобный (в том числе и для сопровождения) код. Их аналогии всегда привязаны к осязаемым объектам. Правда поскольку аналогисты не дружат с абстракцией, создавать объекты с четкими межуровневыми интерфейсами у них получается не всегда.
Дело в том, что возможность создания в достаточной мере абстрактного интерфейса объекта - это одно из величайших преимуществ ООП, и поэтому конкретное мышление иногда мешает успешно справляться с поставленными задачами.
Трюкач.
Трюкачи слишком увлекаются разными технологическими трюками. Они постоянно осваивают разные новинки, но результат от этого не улучшается. Трюкачи, при всех их познаниях в технологии, часто не могут усвоить конечное назначение программы.
Полагая, что их функции ограничиваются забавами с разными инструментальными средствами, они отказываются учитывать те аспекты программирования, благодаря которым мы не затрачиваем на сопровождение титанических усилий.
Разгильдяй.
Они не обращают внимания на такие мелочи, как правильно написание имен переменных и правила венгерской нотации. Зачастую качественно выполнять свои обязанности им мешают проблемы личного плана.
Тому, как пишется эффективный код, их нужно учить. Они любят начать с одного стиля, а через процедуру-другую перейти к новому. Читать их код очень утомительно - иногда поздними ночами его приходится переписывать.
Если разгильдяй действительно любит писать код, при условии, что вы уделяете ему достаточно внимания, он имеет шансы реабилитироваться. Всех, кому это не удается, нужно просто пнуть под зад или познакомить с консультантом по трудоустройству.
Тормоз.
Тормоз - это программист, который не знает, с чего начать. Он постоянно ищет спецификацию (или ожидает, пока ему ее дадут), отчаянно надеясь что она станет для него отправной точкой.
Нерешительность в чем-то хороша, поскольку в некоторых случаях свидетельствует о низкой квалификации программиста, который не хочет лишних ошибок на этапе прогона. Им нужно представлять образец кода, чтобы они могли разобраться, с чего начать, и выбрать стиль, которого им нужно будет придерживаться. Нерешительность часто характерна для неопытных программистов, иногда ей страдают программисты, у которых по тем или иным причинам не слишком впечатляющий послужной список и они бояться ошибиться еще раз.
Помогите тормозу регулярно добиваться небольших успехов, и тогда все наладится.
Любитель.
Любители очень хотят стать настоящими программистами. Тщательно изучив какой-нибудь инструмент написания макрокоманд, они возводят себя в ранг хакеров. Единственная причина, по которой они бросают уютные мест в отделах поддержки пользователей и тестирования, Заключается в том< что, по их мнению, быть программистом - это очень круто.
Да, мы, действительно крутые, но по большому счету, это лишь побочное следствие нашей основной деятельности. Любителям не хватает образования, но по мере их обучения вы должны пристально за ними следить и лишь при условии определенных достижений с их стороны поручать им работы на критически важными приложениями. Узнав на собственном опыте, как трудно заниматься программированием и какое серьезное внимание к деталям требуется от программистов, Любители часто разочаровываются в своем выборе.
Они отказываются признавать превосходство ООП над процедурной парадигмой - и все потому, что нужное прозрение их еще не посетило.
Профан.
Это тот, кого называют тупицей. Хуже все, когда профан не догадывается о своей тупости. Остерегайтесь таких людей. Иногда они могут достаться вам в наследство от предыдущих руководителей, но сами я вас прошу, никогда их не нанимайте. Если человек невежда, но хочет стать лучше, - дайте ему шанс. Отправьте его например в отдел тестирования.
Эклектик.
Можно сказать, что эклектики просто стряпают программные продукты. Представитель этой породы сочетает в себе качества инженера, разгильдяя и не слишком талантливого художника, причем упомянутые ингредиенты находятся в чудовищной диспропорции.
Результат их деятельности представляет собой винегрет из стилей кодирования и подключаемых модулей при невероятной путанице в коде. Все это выглядит довольно привлекательно, но стоит лишь попробовать кусочек, как наступят необратимые последствия. Основным средством реабилитации эклектиков служит критика кода.
Ковбои.
Этот тип плохо согласуется с перечисленными породами, а описывать его лучше в соответствии с тем мнением, которое ковбой о себе формирует. Итак программист-ковбой обычно в совершенстве владеет своим ремеслом, но при этом управлять им практически невозможно.
Ковбои глубоко убеждены, что могут работать только над теми проектами, над которыми хотят, делать это на собственных условиях, согласуясь исключительно с собственными планами и обращаясь только к подходящим по их мнению средствам. Такой программист - своеобразный волк-одиночку.
В зависимости от того, что вам нужно< и вашей готовности терпеть своеобразие их лично, ковбои могут творить либо чудеса, либо хлам. С ковбоями надо держать ухо востро: они ни при каких обстоятельствах не станут частью вашей команды. Прибегать к их услугам стоит либо в безвыходных ситуациях, либо если разрабатываемый проект должен радикально отличаться от всех других, а сопровождать его будут сторонние специалисты.
А кто вы? :D
