Как разозлить разработчика?

Это перевод. Автор текста: Ведущий разработчик и менеджер проектов Никлас Миллард.

Спойлер: разозлить разработчика очень просто. Точнее, разработчика может взбесить буквально все. И чем более "религиозны" взгляды разработчика в отношении определенных сущностей и событий, тем проще это сделать. Я считаю, что нет более токсичного сообщества, чем сообщество разработчиков, программистов и инженеров.

Даже если мы заведем разговор хотя бы о том как правильно назвать профессию, споров и агрессии не избежать. Кем является каждый из нас? Жалким разработчиком, пишущей обезьяной, уважаемым программистом или высокомерным инженером - сколько людей, столько и мнений. Но, например, некоторые инженеры приходят в неистовое бешенство, когда кто-то то ли по незнанию, то ли специально называет их "разработчиками".

Я же в произвольном порядке перечислю некоторые темы, действительно беспокоящие разработчиков. Полагаю, что материал изложенный в этой статье в разной степени злит программистов в зависимости от их убеждений, навыков и опыта.

if-else vs. полиморфизм

Дорогие мои, разве я подозревал, каких размеров осиное гнездо я разворошу, когда писал статью "Прекратите использовать if-else" ("Stop using if-else"). Опубликованный материал получил более 100 000 просмотров всего за несколько дней (а это по стандартам Medium, на минуточку, уже признак вирусного контента). Статья породила даже целую ветку хейтеров на Reddit. Я полагаю, что существует целая секта поклонников плохих практик, приветствующих традиционное ветвление, в том числе с использованием инструкций if-else. Наиболее ортодоксальных представителей этой секты раздражает существование объектно-ориентированного программирования, как наиболее сложного и непонятного процесса, особенно для начинающих программистов.

Оценка задач непрофессионалами

Оценку одного из моих первых проектов проводил коллега, имеющий степень магистра, но... в сфере политических наук. Нам нужно было создать "с нуля" проект, который включал: установку окружения на трех облачных структурах, создание модели базы данных, написание бизнес-логики и реализацию, в том числе front-end и back-end.

Так вот, подсчеты коллеги установили следующие затраты времени и ресурсов:

1. 34-36 часов,

2. 1 разработчик.

Эта информация была донесена до конечного заказчика без консультаций с мной, как с техническим специалистом.

Попробую выразиться очень мягко: такой подход чрезвычайно злит и огорчает разработчиков.

Статьи о программировании

Публичные материалы часто обращают внимание или делают вызов давно устоявшимся традициям, в том числе в области программирования. Я часто получаю комментарии следующего типа: "Я работаю в данной области более 20 лет, всегда делаю X, и это работает".

То есть, разработчик, у которого уже несколько десятилетий не менялся подход к написанию кода, пишет, что прочитал статью, чтобы убедиться, что его старинные методы все еще работают и актуальны. К сожалению, это не так, в мире программирование меняется многое и быстро.

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

Чужой код

Ребята, порой мы ненавидим чужой. Особенно, когда у нас есть собственное решение задачи. Да, в таком случае мы забросаем камнями иноверца. Мы придеремся ко всему: начиная с реализации самой задачи и заканчивая мелкими малозначительными, но раздражающими деталями синтаксиса. В таком случае даже подход к написанию фигурных скобок в код будет указывать на растущую в наших глазах тупость автора:

/* Same line */
if (something) {
}
else {
}

/* Seprate line */
if (something)
{
}
else
{
}

/* K&R 1TBS (the One True Braces Style) */
if (something) {
} else {
}

А еще мы, конечно, обратим внимание на отступы: табы или пробелы? А если пробелы: 2 или 4?

Code review и pull request

Возвращаясь к разговору о токсичной культуре, можно сказать, что такие события как CR/PR всегда направлены на выявление Ваших слабых сторон и худших качеств на поприще разработчика.

Многие из нас относятся к обзору кода, как к публичной порке.

Действительно, нет ничего более обидного, чем потратить кучу сил и времени на создание функционала, которые будет уничтожен посторонними людьми, даже не принимавшими участие в реализации проекта.

Комментарии

Необходимость комментирования кода - это еще одна бесконечная тема для обсуждений в мире разработчиков. Комментарии привлекают внимание во время проверки кода. Всем известна фраза: "Если Вам нужны комментарии, Ваш код недостаточно ясен".

let number = 0;
number++ // increment 'number' by one

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

Не забывайте, что в данной статье изложено только личное мнение автора. Спасибо за внимание.