Код
#статьи

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

Проверено, без смс и регистрации.

Никлас Миллард

(Nicklas Millard)


об авторе

Технический писатель из Дании. Автор с почти миллионом просмотров. Бэкенд-разработчик (.NET) в компании FinTech. В прошлом — ведущий технический консультант «Большой четвёрки».


Код с плохим форматированием. Скриншот: Никлас Миллард / Medium.com

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

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

ОТ ПЕРЕВОДЧИКА

Отечественные разработчики (пока что) явно терпимее. Но вот назовёте нашего тимлида, например, кодером — вряд ли попадёте к нему в друзья.

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

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

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

Варианты расстановки фигурных скобок. Скриншот: Никлас Миллард / Medium.com

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

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

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

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

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

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

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

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

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

Тут был Капитан Очевидность. Скриншот: Никлас Миллард / Medium.com

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

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



Нейросети для работы и творчества!
Хотите разобраться, как их использовать? Смотрите конференцию: четыре топ-эксперта, кейсы и практика. Онлайн, бесплатно. Кликните для подробностей.
Смотреть программу
Понравилась статья?
Да

Пользуясь нашим сайтом, вы соглашаетесь с тем, что мы используем cookies 🍪

Ссылка скопирована