Comments 35
Возможно имелось в виду использовать could вместо can. Хотя для меня разница не принципиальная.
«почему бы вам просто...».Я вот, например, не знаю почему человек сделал именно так как сделал, и хочу получить ответ на мое более простое решение. И вполне логично, что мой вопрос будет сформулирован например как «почему бы вам просто не убрать копирование?». И что в нем не так?
В этом плане письменное общение, как по мне, усложняет взаимопонимание, поскольку разный эмоциональный окрас текстом не передать. Одна и та же фраза может одной интонацией быть и вежливой и оскорбительной. В то время как заниматься литературным изложением своей мысли, в плоть до описания пролетевшего мимо скворца, явно не будет времени. Все будет зависеть от того кто это прочтет.
Хорошо: «Как мы будем делать XXX после вашего изменения?»Подойдет к тебе в реале человек и скажет такое с надрывом — и ты идиот перед всеми остальными. Хорошо? Палка о двух концах.
"просто" — это оценочное слово. Можно, например, сформулировать как "Почему тут нельзя сделать вот так?" и, если это не очевидно, перечислить преимущества и недостатки предложенного варианта. Это способ сильно повысить вероятность того, что обсуждение будет конструктивным, а не свалится в перекидывание казашками между двумя д'Артаньянами.
От культурных особенностей ещё зависит. У англичан такая вот манера полайт дискуссии с непрямыми вопросами мне кажется в крови. Там советы из статьи определенно будут полезны. У наших первая реакция на открытый вопрос в комментарии — т.е. претензий по существу у интервьюера нет, он разводит какую-то демагогию про сферических коней. Лишние трения.
Культурные особенности они такие, да и мир — не самое дружелюбное место)
Статья о том как избежать претензий и перебранок если вам что-то субъективно не нравиться в просмотренном материале. И первые пять комментаторов правилам точно не последовали :)))
Не раз себя ловил на мысли: блин, я бы уже за час это написал, но нет надо держать себя в руках, контрибюторы должны подучиться.
И его стоит слушать, потому что обычно у него больше опыта в том коде, которым он владеет.
Не знаю как остальным, но лично мне не нравится вся эта псевдокультурность. Я люблю когда говорят прямо и по делу. Если код говно, то код говно и это факт. Не имеет зачения я сказал или ко мне претензия — это просто факт (примечание: я говорю про аргументированные моменты).
Я утрирую, но общий тренд тянется давно. К глубокому сожалению, нынешнее (лет 10 минимум) поколение разработчиков любит смазливость и вежливость. Адекватную критику они называют токсичностью. А адекватной критикой они воспринимают только те вещи, которые их учат пошагово что и как делать, рубку дать вместо удочки. Да нет времени вас учить и расставлять по полочкам ваши знания, мы не учителя и вы нам не платите за это.
Сори, че-то накипело.
Если код говно, то код говно и это факт.
Это очень размытая формулировка, которая утверждает «не делай так» (блокирует дальнейшие действия). В статье предлагается подход «делай так» (блокирует другие действия, указывает на желательные действия). Т.е. упор идёт на то, чтобы мотивировать работника к чему-то, а не демотивировать его выполнять свою работу.
Восприятие размытых формулировок обычно требует инсайтов, а перед инсайтом многие животные (включая людей) становятся возбужденными и агрессивными. Вдобавок размытые формулировки снимают ответственность с инструктирующего, поскольку если бы он предложил решение — то оно могло бы оказаться тоже неправильным. По сути, он перекладывает риск с себя на ученика.
Разумеется, размытые формулировки при таких раскладах будут чаще встречать отторжение, чем чёткие и недвусмысленные инструкции.
Я часто встречаюсь с ситуацией, что люди не могут отделить код от себя и все, что касается кода они принимают на душу. Вот именно это и есть проблема. Человек может быть сколь угодно хорошим, но если результат его работы попахивает, то комментарии будут именно к результату работы, а не к человеку.
Как мне кажется, первое, чему нужно учить разработчиков — отделяться от кода и не воспринимать его как часть себя. Конечный результат — пожалуйста. Способ его достижения — будь готов спокойно отправить в /dev/null, иначе не будет никакого развития и роста.
P.S. В особых случаях программисты относятся к программе как… «оно как живое, нужно аккуратно вносить изменения» и все в таком духе. Тут каждому должно быть понятно, что архитектурно программа написана настолько их рук вон плохо, что прямо слов нет, только адовые комментарии к коду. Хотя скорее всего тут уже и к кодописателю будут совсем нелестные комментарии.
Это изменение изменяет одиночный цикл O(n) на дважды вложенный цикл O(n²); не повлияет ли это на производительность?
«Послушай, разве ты не видишь, что твоему товарищу за шиворот падают капли расплавленного олова?»
10 советов, как ревьюить код, который вам не нравится