Как выбесить разработчика. 6 способов

Вывести разработчика из себя, на самом деле, очень просто. Особенно уязвимы те, чьи убеждения по-религиозному тверды и не подвергаются пересмотру. В этом смысле коллективы программистов, разработчиков и софт-инженеров одни из самых токсичных.

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

В этой статье я собрал подобные темы. Каждая из них способна задеть программиста за живое, а как сильно — зависит от опыта, навыков и убеждений спеца.

Спор о замене условного оператора полиморфизмом

Когда я опубликовал одну из первых своих статей 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 (пер.: «обсуждение фигурных скобок») — от числа результатов теряется дар речи.

Классический повод для спора: как всё-таки делать отступы в коде — табом или пробелом?

Критика без тормозов (ревью кода и пул-запросы)

Именно на ревью кода и во время пул-запросов токсичность разработчиков проявляется во всей красе.

Ревью кода — это вроде как позвать людей, которые опозорят работу других людей при их же коллегах.

Похожее происходит и при пул-запросах. Досадно, когда тратишь время, разрабатываешь какую-то крутую фичу. Потом предлагаешь добавить её в мастер-ветку репозитория — и твой код зарезают. Причём делают это те, кто даже не участвовал в его написании. Это обескураживает.

По сути, и на ревью кода, и после пул-запроса одни разработчики без обиняков говорят другим, как тем следует писать их код. И никого никому не жаль, если в числе «тех других» нет их самих.

Считать, что комменты нужны только плохому коду

Нужны ли комментарии коду? Говорят, об этом спорили ещё строители Вавилонской башни. Хотите последовать их примеру — без собеседника не останетесь точно.

Чаще всего комментарии привлекают внимание на этапе ревью. Вроде как «если понадобился коммент, значит, вы написали недостаточно понятный код».

Контраргумент. Очевидно, что вдумчивые комментарии очень помогут тем, кто будет читать код после вас. Да и вы сами, заглянув в свой исходник через несколько лет, будете им только рады.

Об этом я уже писал в статье Yes, Your Code Need Comments («Да, вашему коду нужны комментарии»).