Comments 24
Я считаю, что нет более токсичного сообщества, чем сообщество разработчиков, программистов и инженеров.
Сразу видно полное отстутствие у автора опыта работы в медицине или например автомеханником.
Не говоря уже о школе. Или, прости господи, о коридорах власти.
А как насчет сообщества геймеров (MOBA games?), echo chambers в твиттере, однобокие телеграм-каналы, анонимные имиджборды, сетевой маркетинг? I can tolerate everything except the outgroup?
Либо автору предстоит множество открытий, либо он сознательно лукавит. Что иронично - эта фраза про токсичное сообщество в оригинальном материале - top highlight, который можно либо выделить на медиуме, либо поделиться в том же токсичном твиттере.
Думаю стоит разделять чужой код, нелюбимый codestyle и комментарии вида `for (i=0; i< 10; i++) // Цикл по i` это одно, в свою очередь оценка задач непрофессионалами -- совершенно другое.
Первое про моменты между разработчиками. Такие вещи были и будут, т.к. каждый разработчик то и дело эти моменты в работу привностит. Так что либо понять и простить, либо материться у кофеавтомата. А если писать статью то называть её "Как один разработчик может разозлить другого".
Второе -- интереснее. Это вопрос взаимодействия с менеджментом. По мне, под таким заголовком как у вас, просится раскрытие именно этого вопроса.
Минутка юмора.
В тему разолить разработчика.
Перестаньте уже наконец использовать циклы вида 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); });
Хм... На "разозлить" тянет только история с оценкой времени (ибо подстава). Тут впору было сказать коллеге "Ok, делай сам за это время/деньги". Остальное – банальные темы для срачей, состояние "вы все дураки и не лечитесь, одна я в белом пальто стою красивая" вряд ли можно назвать злостью.
Конечно же больше всего меня бесит когда фигурную скобку ставят на следующей после if строке:
if (true)
{
}Нет ничего, чтобы раздражало больше чем это.
Или вот сравнение на 0 ещё:
$arr = [];
if (count($arr) < 1) {
...
}Camm on, серьезно? Нет, послушай, ты реально считаешь, что там может быть что-то отличное от 0 быть? (Привет Tobias)
Конечно же больше всего меня бесит
Если Вас что то бесит, то у Вас могут быть проблемы.
Изгоняйте своих бесов.
Всегда ставлю скобку на следующей строке после if. Это в первую очередь наглядно, а во вторых так привык.
Проверку на ноль пишу всегда так X == 0, но не так !X. Ибо первый вариант гораздо нагляднее и сразу виден и понятен. А второй надо ещё рассмотреть + "перевернуть".
Посмотрите пункт 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
ИМХО из статьи видно, что разозлить разработчика очень трудно. И это видно по другим обсуждениям на Хабре. Заголовок "Stop using if-else", конечно, вызвал у меня недоумение — пожал плечами и прошел мимо (я занят разработкой много лет). Помните статью "Настоящие программисты не пишут на Паскале"? Когда эта статья была издана, я не без удовольствия ее прочитал — местами остроумно, но продолжил писать на Паскале, а позже на ОО Паскале.
Думаю, что опытного разработчика статьями типа "чем ЯП Х хуже/лучше ЯП Y, и почему нужно забыть ООП" не разозлить. Максимум негативных реакций — ему будет скучно читать такую статью.
Но очевиден рецепт, как разозлить: понизить ЗП раза в 2 :)
Да, как бесят эти стариков среди айтишников, которые неделями используют одни и те же фреймворки
Я вот живу в своем собственном маленьком мире и использую Eloquent (даже при дорогостоящих операциях, где допустим условный join будет в 10 раз быстрее чем where exists).
Пока доводилось поработать только с низко нагруженными проектами и там это не встаёт проблемой - использование фреймворка хватает чтобы закрывать потребности.
Но, пожалуй, теперь, настаивать на том чтобы в каждую бочку пихать затычки: фреймворки и ORM, я не буду.
>>когда писал статью "Прекратите использовать if-else" ("Stop using
if-else"). Опубликованный материал получил более 100 000 просмотров
всего за несколько дней (а это по стандартам Medium, на минуточку, уже
признак вирусного контента). Статья породила даже целую ветку хейтеров
на Reddit. Я полагаю, что существует целая секта поклонников плохих
практик, приветствующих традиционное ветвление, в том числе с
использованием инструкций if-else. Наиболее ортодоксальных
представителей этой секты раздражает существование
объектно-ориентированного программирования, как наиболее сложного и
непонятного процесса, особенно для начинающих программистов.
Догадываюсь что людей разозлило. Люди не любят радикальный фанатизм, как правило. Особенно если этот радикальный фанатизм может ударить по тебе напрямую.
И дело тут не только в тех, кто не способен понять саму идею полиморфизма, как автор пытается это представить (что характерно для радикалов, кстати, у них все кто не с ними - как минимум глупые и недалекие люди).
Доводилось работать в проектах, в истоках которых стояли такие вот разработчики - ненавистники if-else. Код их выглядел жутким ООП лабиринтом, в котором было крайне трудно понять как данные перемещаются по разлапистой иерархии объектов, и в каком месте возникает ошибка. Яркий пример того как можно какой-то простой алгоритм реализовать максимально сложно. Но зато, там действительно было по минимуму if-else, это да!
Была масса классов, написанных лет так пять десять назад, в которых с помощью полиморфизма устранялась альтернатива из двух-трех вариантов. Т.е. возможность легкого расширения функционала (в чем главная фишка полиморфизма) не была использована, и скорее всего не будет использована никогда, но ради какого-то гипотетического преимущества в будущем, вместо небольшого, компактного модуля, мы имеем минимум четыре класса - три полиморфных, и один интерфейс ко всему этому. Это ерунда если рассматривать только одно место в проекте, и конкретно этот момент, хуже было что его авторы помимо полиморфизма очень сильно обожали наследование, местами иерархия классов разросталась до пяти-шести уровней, часто понять где проблема можно было только с помощью долгой и кропотливой отладки, потому что при помощи простого анализа кода было очень сложно понять каким маршрутом данные проходят по этой иерархии и где какой класс используется из-за полиморфизма.
Когда с этим работал - искренне скучал по старому, доброму спагетти-говнокоду, там хотя-бы все было линейно, чаще всего.
Но, например, некоторые инженеры приходят в неистовое бешенство, когда кто-то то ли по незнанию, то ли специально называет их "разработчиками".
А что произойдет, если назвать его "компьютерщиком", "тыжпрограммистом" и т.д.?
Как разозлить разработчика - нет более надёжного способа, чем когда тестировщик говорит тебе "чет ничего не работает", ты полгода пытаешься найти проблему, воешь на луну, а потом тестировщик говорит "ой это я неправильно там кое что настроил, все норм"
По-настоящему злит работать с людьми, плохо понимающими, что такое разработка.
Как разозлить разработчика?