Это перевод. Автор текста: Ведущий разработчик и менеджер проектов Никлас Миллард.
Спойлер: разозлить разработчика очень просто. Точнее, разработчика может взбесить буквально все. И чем более "религиозны" взгляды разработчика в отношении определенных сущностей и событий, тем проще это сделать. Я считаю, что нет более токсичного сообщества, чем сообщество разработчиков, программистов и инженеров.
Даже если мы заведем разговор хотя бы о том как правильно назвать профессию, споров и агрессии не избежать. Кем является каждый из нас? Жалким разработчиком, пишущей обезьяной, уважаемым программистом или высокомерным инженером - сколько людей, столько и мнений. Но, например, некоторые инженеры приходят в неистовое бешенство, когда кто-то то ли по незнанию, то ли специально называет их "разработчиками".
Я же в произвольном порядке перечислю некоторые темы, действительно беспокоящие разработчиков. Полагаю, что материал изложенный в этой статье в разной степени злит программистов в зависимости от их убеждений, навыков и опыта.
if-else vs. полиморфизм
Дорогие мои, разве я подозревал, каких размеров осиное гнездо я разворошу, когда писал статью "Прекратите использовать if-else" ("Stop using if-else"). Опубликованный материал получил более 100 000 просмотров всего за несколько дней (а это по стандартам Medium, на минуточку, уже признак вирусного контента). Статья породила даже целую ветку хейтеров на Reddit. Я полагаю, что существует целая секта поклонников плохих практик, приветствующих традиционное ветвление, в том числе с использованием инструкций if-else. Наиболее ортодоксальных представителей этой секты раздражает существование объектно-ориентированного программирования, как наиболее сложного и непонятного процесса, особенно для начинающих программистов.
Оценка задач непрофессионалами
Оценку одного из моих первых проектов проводил коллега, имеющий степень магистра, но... в сфере политических наук. Нам нужно было создать "с нуля" проект, который включал: установку окружения на трех облачных структурах, создание модели базы данных, написание бизнес-логики и реализацию, в том числе front-end и back-end.
Так вот, подсчеты коллеги установили следующие затраты времени и ресурсов:
34-36 часов,
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Очевидно, хорошие и осознанные комментарии являются большим подспорьем для других разработчиков. Да и Вы будущий, разбираясь с таким кодом спустя время, будете благодарить за нужные комментарии себя настоящего.
Не забывайте, что в данной статье изложено только личное мнение автора. Спасибо за внимание.
Комментарии (23)
shaggyone
06.02.2022 11:04+2Думаю стоит разделять чужой код, нелюбимый codestyle и комментарии вида `for (i=0; i< 10; i++) // Цикл по i` это одно, в свою очередь оценка задач непрофессионалами -- совершенно другое.
Первое про моменты между разработчиками. Такие вещи были и будут, т.к. каждый разработчик то и дело эти моменты в работу привностит. Так что либо понять и простить, либо материться у кофеавтомата. А если писать статью то называть её "Как один разработчик может разозлить другого".
Второе -- интереснее. Это вопрос взаимодействия с менеджментом. По мне, под таким заголовком как у вас, просится раскрытие именно этого вопроса.
RabraBabr
06.02.2022 13:09+1Минутка юмора.
В тему разолить разработчика.
Перестаньте уже наконец использовать циклы вида for (i=0; i< 10; i++) чего то там.
Вкл зануду. Они крайне не безопасны,можно запросто выйти за пределы коллекции.
Используйти итераторы. Пример:
std::string s("hello"); std::transform(s.begin(), s.end(), s.begin(), [](unsigned char c) -> unsigned char { return std::toupper(c); });shaggyone
07.02.2022 08:26Где вы увидели С++? Это C99.
char *s = "hello";
for (x=s; *x!=0; x++) { // Цикл по строке
aamonster
06.02.2022 13:01+7Хм... На "разозлить" тянет только история с оценкой времени (ибо подстава). Тут впору было сказать коллеге "Ok, делай сам за это время/деньги". Остальное – банальные темы для срачей, состояние "вы все дураки и не лечитесь, одна я в белом пальто стою красивая" вряд ли можно назвать злостью.
dimti
06.02.2022 17:40Конечно же больше всего меня бесит когда фигурную скобку ставят на следующей после if строке:
if (true) { }Нет ничего, чтобы раздражало больше чем это.
Или вот сравнение на 0 ещё:
$arr = []; if (count($arr) < 1) { ... }Camm on, серьезно? Нет, послушай, ты реально считаешь, что там может быть что-то отличное от 0 быть? (Привет Tobias)
dom3d
06.02.2022 18:58-1Конечно же больше всего меня бесит
Если Вас что то бесит, то у Вас могут быть проблемы.
Изгоняйте своих бесов.
rubinstein
09.02.2022 06:20Всегда ставлю скобку на следующей строке после if. Это в первую очередь наглядно, а во вторых так привык.
Проверку на ноль пишу всегда так X == 0, но не так !X. Ибо первый вариант гораздо нагляднее и сразу виден и понятен. А второй надо ещё рассмотреть + "перевернуть".
dimti
09.02.2022 07:58Посмотрите пункт 1.1 в предлагаемой сводке стандартов PSR-2: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
PhpStorm автоматически форматирует код в соответствии с данными принятыми правилами (есть такая там штука: Ctrl+Shift+L, которая позволяет даже html автоматически разминифицировать и расставить отступы). Обычно я ей пользуюсь когда вижу что код отформатирован не в соответствии со стандартами принятыми внутри команды, о которых я сразу сообщаю разработчикам, делаю style guide, где описываю общие правила для популярных конструкций кода.
Само собой, по привычке, разработчик продолжает ставить фигурную скобку после if в php на следующей строке, даже пересев с netbeans на phpstorm, это не меняет ситуацию. Сила привычки велика.
Со сравнением на ноль вообще странная штука. Видимо причина все таже - дело привычки.
Есть какие-то ситуации, когда математические операции не дают целочисленный 0 - может быть компьютерные вычисления не могут оставить равноценный остаток между, казалось, бы одинаковыми числами с плавающей точкой. Возможно это знание пришло из других языков, где это и правдо было актуально и теперь используется по привычке: https://github.com/OFFLINE-GmbH/oc-mall-plugin/issues/730
third112
06.02.2022 17:59+4ИМХО из статьи видно, что разозлить разработчика очень трудно. И это видно по другим обсуждениям на Хабре. Заголовок "Stop using if-else", конечно, вызвал у меня недоумение — пожал плечами и прошел мимо (я занят разработкой много лет). Помните статью "Настоящие программисты не пишут на Паскале"? Когда эта статья была издана, я не без удовольствия ее прочитал — местами остроумно, но продолжил писать на Паскале, а позже на ОО Паскале.
Думаю, что опытного разработчика статьями типа "чем ЯП Х хуже/лучше ЯП Y, и почему нужно забыть ООП" не разозлить. Максимум негативных реакций — ему будет скучно читать такую статью.
Но очевиден рецепт, как разозлить: понизить ЗП раза в 2 :)
morosov_a_s
06.02.2022 20:14+5Да, как бесят эти стариков среди айтишников, которые неделями используют одни и те же фреймворки
dimti
09.02.2022 08:13Я вот живу в своем собственном маленьком мире и использую Eloquent (даже при дорогостоящих операциях, где допустим условный join будет в 10 раз быстрее чем where exists).
Пока доводилось поработать только с низко нагруженными проектами и там это не встаёт проблемой - использование фреймворка хватает чтобы закрывать потребности.
Но, пожалуй, теперь, настаивать на том чтобы в каждую бочку пихать затычки: фреймворки и ORM, я не буду.
vvbob
07.02.2022 08:17+3>>когда писал статью "Прекратите использовать if-else" ("Stop using
if-else"). Опубликованный материал получил более 100 000 просмотров
всего за несколько дней (а это по стандартам Medium, на минуточку, уже
признак вирусного контента). Статья породила даже целую ветку хейтеров
на Reddit. Я полагаю, что существует целая секта поклонников плохих
практик, приветствующих традиционное ветвление, в том числе с
использованием инструкций if-else. Наиболее ортодоксальных
представителей этой секты раздражает существование
объектно-ориентированного программирования, как наиболее сложного и
непонятного процесса, особенно для начинающих программистов.Догадываюсь что людей разозлило. Люди не любят радикальный фанатизм, как правило. Особенно если этот радикальный фанатизм может ударить по тебе напрямую.
И дело тут не только в тех, кто не способен понять саму идею полиморфизма, как автор пытается это представить (что характерно для радикалов, кстати, у них все кто не с ними - как минимум глупые и недалекие люди).
Доводилось работать в проектах, в истоках которых стояли такие вот разработчики - ненавистники if-else. Код их выглядел жутким ООП лабиринтом, в котором было крайне трудно понять как данные перемещаются по разлапистой иерархии объектов, и в каком месте возникает ошибка. Яркий пример того как можно какой-то простой алгоритм реализовать максимально сложно. Но зато, там действительно было по минимуму if-else, это да!
Была масса классов, написанных лет так пять десять назад, в которых с помощью полиморфизма устранялась альтернатива из двух-трех вариантов. Т.е. возможность легкого расширения функционала (в чем главная фишка полиморфизма) не была использована, и скорее всего не будет использована никогда, но ради какого-то гипотетического преимущества в будущем, вместо небольшого, компактного модуля, мы имеем минимум четыре класса - три полиморфных, и один интерфейс ко всему этому. Это ерунда если рассматривать только одно место в проекте, и конкретно этот момент, хуже было что его авторы помимо полиморфизма очень сильно обожали наследование, местами иерархия классов разросталась до пяти-шести уровней, часто понять где проблема можно было только с помощью долгой и кропотливой отладки, потому что при помощи простого анализа кода было очень сложно понять каким маршрутом данные проходят по этой иерархии и где какой класс используется из-за полиморфизма.
Когда с этим работал - искренне скучал по старому, доброму спагетти-говнокоду, там хотя-бы все было линейно, чаще всего.
mixsture
07.02.2022 12:20+2Плюсую. Имхо люди часто забывают, что ООП был придуман для сокрытия сложности. Если он не выполняет эту функцию, он не нужен, т.к. оверхед по производительности добавляет всегда, а пользы нет.
StupidMouse
08.02.2022 10:39Но, например, некоторые инженеры приходят в неистовое бешенство, когда кто-то то ли по незнанию, то ли специально называет их "разработчиками".
А что произойдет, если назвать его "компьютерщиком", "тыжпрограммистом" и т.д.?
nibb13
09.02.2022 06:46Дурацкая шутка юмора
Нерадивых инженеров привязывают к ракете-носителю в качестве бустеров и на старте над площадкой громогласно разносится: "...три...два...один...вы разработчики!..компьютерщики!..тыжпрограммисты!..пуск!"
Dartflame
08.02.2022 10:40+1Как разозлить разработчика - нет более надёжного способа, чем когда тестировщик говорит тебе "чет ничего не работает", ты полгода пытаешься найти проблему, воешь на луну, а потом тестировщик говорит "ой это я неправильно там кое что настроил, все норм"
Hivemaster
Сразу видно полное отстутствие у автора опыта работы в медицине или например автомеханником.
gatoazul
Не говоря уже о школе. Или, прости господи, о коридорах власти.
aamonster
Злой вы (довелось как-то послушать откровения о жизни учителей в обычной средней школе, думаю, в коридорах власти такого накала страстей под фальшивыми улыбками нет).
Timofeuz
Автор иностранец. Может там в школах и медицине другая атмосфера.
Diamon33
А как насчет сообщества геймеров (MOBA games?), echo chambers в твиттере, однобокие телеграм-каналы, анонимные имиджборды, сетевой маркетинг? I can tolerate everything except the outgroup?
Либо автору предстоит множество открытий, либо он сознательно лукавит. Что иронично - эта фраза про токсичное сообщество в оригинальном материале - top highlight, который можно либо выделить на медиуме, либо поделиться в том же токсичном твиттере.