[Перевод] Как разозлить разработчика?

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

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

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

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

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

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


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

Читайте так же:

  • В Google Analytics 4 стал доступен импорт офлайн-событийВ Google Analytics 4 стал доступен импорт офлайн-событий Команда Google Analytics сообщила о добавлении новой функции в GA 4 – импорта офлайн-событий. New In Google Analytics 4: Import Offline EventsYou can import offline events from sources that don't have an internet connection or that otherwise cannot support real-time event collection […]
  • Запущенные четверть века назад сети 2G лет отключают в Южной КорееЗапущенные четверть века назад сети 2G лет отключают в Южной Корее Южная Корея стала первой страной, которая запустила услуги мобильной связи 2G еще в 1996 году. Эта сеть существует уже около 25 лет. В этом месяце страна полностью откажется от первых в мире коммерческих сетей 2G. По мере того, как сети 5G продолжают расширяться в разных регионах, старые […]
  • Портативная пушка Гаусса за 1кПортативная пушка Гаусса за 1к В этом посте будет рассмотрена схема и сборка портативной Пушки Гаусса, которую можно собрать за минимальную сумму, а именно, ускоритель будет собран в сумму ~ 1000р. Схема проста на столько, что ее сможет собрать не разбирающийся. Корпус в свою очередь можно скачать в виде 3D модели. […]
  • Топовая версия Meizu 18 Pro оказалась самой популярной моделью серии Meizu 18Топовая версия Meizu 18 Pro оказалась самой популярной моделью серии Meizu 18 Сегодня днем компания Meizu провела в Ките пресс-конференцию Meizu Smart Life Conference. Глава отдела маркетинга Meizu Ван Чжицян (Wan Zhiqiang) расказал об успехах серии смартфонов Meizu 18, выпущенной в начале года. Ван Чжицян заявил. Что самой продаваемой версией линейки Meizu 18 […]