Как выбесить разработчика. 6 способов
Проверено, без смс и регистрации.
![](https://248006.selcdn.ru/main/iblock/6be/6be29a8c20e4d574d796f6116e491535/a5e847f0c87af9908b7a632fd6457d5a.png)
![](https://248006.selcdn.ru/main/iblock/6be/6be29a8c20e4d574d796f6116e491535/a5e847f0c87af9908b7a632fd6457d5a.png)
![](https://248006.selcdn.ru/main/upload/setka_images/08225924062021_77732aab727214daa7d7b54a7dfe9ac62029242a.jpeg)
Никлас Миллард
(Nicklas Millard)
об авторе
Технический писатель из Дании. Автор с почти миллионом просмотров. Бэкенд-разработчик (.NET) в компании FinTech. В прошлом — ведущий технический консультант «Большой четвёрки».
![](https://248006.selcdn.ru/main/upload/setka_images/08260624062021_db52642fc67f6c7c46657360f234a883af322464.png)
Вывести разработчика из себя, на самом деле, очень просто. Особенно уязвимы те, чьи убеждения по-религиозному тверды и не подвергаются пересмотру. В этом смысле коллективы программистов, разработчиков и софт-инженеров одни из самых токсичных.
Да даже сама эта тема — кто же мы на самом деле — уже веский повод для жаркой дискуссии. Вы презренный разраб — некое подобие мартышки с клавиатурой? Или вполне достойный программист? А может быть, пафосный софт-инженер? Или птица высочайшего полёта — архитектор ПО? Поругаться можно даже из-за самоназвания — неслучайно некоторые софт-инженеры приходят почти в неистовство, если кто-то осмелился назвать их высочества «разработчиками».
ОТ ПЕРЕВОДЧИКА
Отечественные разработчики (пока что) явно терпимее. Но вот назовёте нашего тимлида, например, кодером — вряд ли попадёте к нему в друзья.
В этой статье я собрал подобные темы. Каждая из них способна задеть программиста за живое, а как сильно — зависит от опыта, навыков и убеждений спеца.
Спор о замене условного оператора полиморфизмом
Когда я опубликовал одну из первых своих статей Stop Using If-Else («Откажитесь от оператора if-else»), то был приятно удивлён: всего за несколько дней она набрала больше ста тысяч просмотров — по меркам Medium это немало.
Но я и представить не мог, какое осиное гнездо разворошу. Читателей так разозлил мой текст, что они даже посвятили ему гневный тред на Reddit. Как будто писать плохой код с привычным ветвлением стало чем-то вроде религии, а я вдруг оскорбил чувства верующих.
Если интересуетесь этой темой, приглашаю прочесть мои статьи Replacing If-Else With Commands and Handlers («Как заменить if-else шаблоном Command и обработчиками») и If-Else Is a Poor Man’s Polymorphism («If-else — полиморфизм для бедных»).
В общем, кто-то считает, что новичку нельзя просто так взять и начать использовать ООП. Вроде как надо изучить всё от и до, проникнуть в суть, достичь просветления. А мне не нравится, что из-за этого начинающие разработчики долго считают объектно-ориентированное мышление чем-то жутко сложным.
Ставить дедлайны, не разбираясь в разработке
Один из первых моих проектов планировал коллега — магистр политических наук. Тогда нам нужно было разработать решение с нуля: развернуть и настроить три облачные среды, создать модель базы данных, написать бизнес-логику, бэкенд и фронтенд.
По оценке коллеги, всё это я должен был сделать в одиночку за 34–36 часов. Меня даже не спрашивали, реалистичны ли эти сроки, — график работ над проектом сразу представили клиенту.
Такая вот фигня просто выбешивает разработчиков.
Комментировать статьи, чтобы самоутвердиться
В статьях разработчики делятся опытом. Часто их тексты бросают вызов привычному, рассказывают, как писать код по-новому. А потом авторы видят под статьями комменты вроде: «Я разработчик с 20-летним опытом. И то, о чём вы пишете, всегда делал таким-то способом, а не вашим. И мой способ работает!»
Такие комментарии больше говорят об их авторах, чем о теме. Что это значит на самом деле? Человек 20 лет пишет код одним и тем же образом, не меняя стиля, не пробуя ничего нового. А статью решил прочитать только затем, чтобы убедиться, что знания его до сих пор актуальны. Дорогие комментаторы, сожалею, но мир не стоит на месте.
Так что читать комменты — дело не всегда благодарное. Хейтеры не дремлют. С любым советом из статьи можно поспорить, а предлагаемые приёмы и правила упрекнуть в неуниверсальности.
Подмечать соринки в чужом коде
Вы когда-нибудь видели, чтобы чужой код хвалили? А вот поносить — другое дело. Для этого даже не обязательно понимать, что код должен делать и почему он написан именно так. Всегда легче назвать чужой код глупым, чем признать, что ты чего-то в нём не догоняешь.
Зацепиться можно за любую мелочь:
- за фигурные скобки на одной и той же строке,
- или вынесение их в отдельные строки,
- или за выбор стиля K&R с отступом из восьми пробелов.
Загуглите curly braces discussion (пер.: «обсуждение фигурных скобок») — от числа результатов теряется дар речи.
![](https://248006.selcdn.ru/main/upload/setka_images/08260624062021_27e9aa5bdf801f94f7728fe14d1ac08405e5a691.png)
Классический повод для спора: как всё-таки делать отступы в коде — табом или пробелом?
Критика без тормозов (ревью кода и пул-запросы)
Именно на ревью кода и во время пул-запросов токсичность разработчиков проявляется во всей красе.
Ревью кода — это вроде как позвать людей, которые опозорят работу других людей при их же коллегах.
Похожее происходит и при пул-запросах. Досадно, когда тратишь время, разрабатываешь какую-то крутую фичу. Потом предлагаешь добавить её в мастер-ветку репозитория — и твой код зарезают. Причём делают это те, кто даже не участвовал в его написании. Это обескураживает.
По сути, и на ревью кода, и после пул-запроса одни разработчики без обиняков говорят другим, как тем следует писать их код. И никого никому не жаль, если в числе «тех других» нет их самих.
Считать, что комменты нужны только плохому коду
Нужны ли комментарии коду? Говорят, об этом спорили ещё строители Вавилонской башни. Хотите последовать их примеру — без собеседника не останетесь точно.
Чаще всего комментарии привлекают внимание на этапе ревью. Вроде как «если понадобился коммент, значит, вы написали недостаточно понятный код».
![](https://248006.selcdn.ru/main/upload/setka_images/08260624062021_e3ea06ecc4efe66fd609360c227a5daace25eda6.png)
Контраргумент. Очевидно, что вдумчивые комментарии очень помогут тем, кто будет читать код после вас. Да и вы сами, заглянув в свой исходник через несколько лет, будете им только рады.
Об этом я уже писал в статье Yes, Your Code Need Comments («Да, вашему коду нужны комментарии»).