Никогда не думали, а что если паттерны ООП спроецировать на работу программистов?
Singleton-разработчик
Разработчик с bus-factor=1. Как правило, один из «старожилов» проекта, который приложил руку ко многим компонентам и только он знает как эти части работают вместе. Практически «невыпиливаемый» из проекта, либо без него все начинает «работать как-то не так». По любому вопросу «как оно работает» всегда отвечает «да мне проще самому запилить» и запиливает.
Registry-разработчик
Также как и singleton это разработчик-старожил, однако, в отличии от него, не знает деталей реализации, но знает что компонент в принципе существует. Зачастую, служит «живым справочником» и на любой вопрос о коде может посоветовать где посмотреть как это делается.
Factory-разработчик
Разработчик в веб-студии. На вход зачастую получает несколько параметров, вроде готовой верстки и пары картинок, а на выход выдает сайт-визитку или очередной интернет-магазин. Как правило, со временем стремится сократить число параметров на входе чтобы увеличить скорость работы, а то и вовсе автоматизировать процесс.
Adapter-разработчик
Разработчик, который хорошо понимает язык как менеджеров, так и разработчиков. Незаменимый участник мероприятий по планированию и оценке задач. Способен «переварить» фразы «Сделайте зашибись» в более менее понятные причинно-следственные связи между сущностями, которые могут быть реализованы уже другими разработчиками.
Proxy-разработчик
Тот же adapter-разработчик, только без привнесения «дополнительной полезности». Встречается с менеджерами, заводит с их слов тикеты, которые потом тупо переназначает на других разработчиков. При этом всячески старается продемонстрировать свою незаменимость в этом процессе обеим сторонам.
Observer-разработчик
Регулярно мониторит все коммиты master-бранча и делает их ревью даже если это не входит в его область ответственности. Если что-то по ревью ему не нравится, то любит запускать event’ы по рефакторингу и задачам на доработку.
(Single-)Strategy-разработчик
Включаясь в любой новый проект или задачу старается реализовать все по заранее выработанному на других проектах алгоритму. Даже если для этого нужно притянуть зависимости из других компонентов, как правило, оправдывая это тем, что «так правильно, я так много раз делал и все работало».
Facade-разработчик
Ответственный представитель команды, как правило, тим-лид. Всегда может взять на себя все организационные вопросы по работе всей команды в целом.
LazyInitialization-разработчик
Приступает к реализации задачи только когда кто-нибудь запросит ее статус. Категорически не признает работу по issue-трекеру через беклог.
Null-object-разработчик
Разработчик, который перестраховывает отсутствующих членов команды если у менеджеров возникают вопросы по какому-либо функционалу. Всегда готов помочь разобраться, даже если ничего не знает в предметной области.
God-object-разработчик
Единственный разработчик на проекте с самого его начала. Степень god-овости растет по мере отсутствия на проекте системы контроля версий, документации и роста «зоопарка».
Visitor-разработчик
Имеет общее представление о том как правильно писать код, и старается его донести до других разработчиков в их компонентах. Может залезть к вам в код, изменить отступы и переносы, добавить DOC-комменты, и даже переименовать «правильно» классы и методы и на этом будет считать свою миссию выполненной.
ChainOfResponsibility-разработчик
Прежде чем запилить задачу, начинает методично заваливать вопросами всех, кто по его мнению может помочь ему с ней, начиная от тим-лида, кончая сидящим рядом коллегой. Как только «очередной в цепочке» начинает говорить «Да задолбал, возьми уже и сам разберись», переключается на следующего и так до тех пор, пока кто-либо не распишет все до деталей, либо не закончатся коллеги.
Желаю вам в работе побольше хороших паттернов-коллег.
Оригинал статьи на Хабре (2015 год)
К лучшим публикациям Хабра за сутки