Pull to refresh

Comments 35

UFO just landed and posted this here
UFO just landed and posted this here
Смысл пункта 9 полностью потерялся при переводе :( Да и вообще говорить «пожалуйста» в русском языке на каждый чих не очень принято

Возможно имелось в виду использовать could вместо can. Хотя для меня разница не принципиальная.

В оригинале как раз про «please», а не про «could — can».
В русском не принято в каждой просьбе использовать слово «пожалуйста», в английском принято, у них частота его использования сильно выше. Это, кстати, одна из причин по которой русских считают не очень вежливыми.
«почему бы вам просто...».
Я вот, например, не знаю почему человек сделал именно так как сделал, и хочу получить ответ на мое более простое решение. И вполне логично, что мой вопрос будет сформулирован например как «почему бы вам просто не убрать копирование?». И что в нем не так?

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

Хорошо: «Как мы будем делать XXX после вашего изменения?»
Подойдет к тебе в реале человек и скажет такое с надрывом — и ты идиот перед всеми остальными. Хорошо? Палка о двух концах.

"просто" — это оценочное слово. Можно, например, сформулировать как "Почему тут нельзя сделать вот так?" и, если это не очевидно, перечислить преимущества и недостатки предложенного варианта. Это способ сильно повысить вероятность того, что обсуждение будет конструктивным, а не свалится в перекидывание казашками между двумя д'Артаньянами.

UFO just landed and posted this here

От культурных особенностей ещё зависит. У англичан такая вот манера полайт дискуссии с непрямыми вопросами мне кажется в крови. Там советы из статьи определенно будут полезны. У наших первая реакция на открытый вопрос в комментарии — т.е. претензий по существу у интервьюера нет, он разводит какую-то демагогию про сферических коней. Лишние трения.

Культурные особенности они такие, да и мир — не самое дружелюбное место)

Статья о том как избежать претензий и перебранок если вам что-то субъективно не нравиться в просмотренном материале. И первые пять комментаторов правилам точно не последовали :)))

Добавлю ссылки на статью о двух частях, которая мне лично очень помогла с проведением code review: How to Do Code Reviews Like a Human (part one, part two).

Если я знаю, что будут придираться, то посылаю очень сырой код, — пусть за одно и проверят. А я пока отдохну.
Если я такое чуствую, то скорее вы получите отказ в мерже. Очень много времени забирает ревью кода, но без контрибюторов, опен сорс это сизифов труд. Вы пользуетесь продуктом, вам что-то надо, мы можем сказать насколько это сложно и указать места и как это делать, но явный тяпляп это перебор.

Не раз себя ловил на мысли: блин, я бы уже за час это написал, но нет надо держать себя в руках, контрибюторы должны подучиться.
А кто ревьюит ревьюера? почему он истина?
Ревьювер это не судья, а помощник, который может подсказать как сделать код лучше.
И его стоит слушать, потому что обычно у него больше опыта в том коде, которым он владеет.
Если говорить о тотальном контроле качества на предприятии, то получается ревьюера никто не контролирует. Зачастую получается, кто первых халат одел, тот и доктор.
Ревьювер не обязательно один. У нас принято правило, что ПР прошел, если более 60% ревьюверов дало добро.
Ну и стоит следить за ситуацией, когда ПР проходит только потому что у всех не было до него дела и поставили аппрув чтобы не мешался.
UFO just landed and posted this here
Все кому это доступно. Если ты на опенсорс проекте несколько лет, то твое мнение что-то да значит. И как правило, я пишу почему конкретный кусок кода не подходит и как это исправить.
Иными словами, комментировать нужно позитивно, конструктивно и вежливо!
Как-то стремно звучит.
Не знаю как остальным, но лично мне не нравится вся эта псевдокультурность. Я люблю когда говорят прямо и по делу. Если код говно, то код говно и это факт. Не имеет зачения я сказал или ко мне претензия — это просто факт (примечание: я говорю про аргументированные моменты).

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

Сори, че-то накипело.
Если код говно, то код говно и это факт.


Это очень размытая формулировка, которая утверждает «не делай так» (блокирует дальнейшие действия). В статье предлагается подход «делай так» (блокирует другие действия, указывает на желательные действия). Т.е. упор идёт на то, чтобы мотивировать работника к чему-то, а не демотивировать его выполнять свою работу.

Восприятие размытых формулировок обычно требует инсайтов, а перед инсайтом многие животные (включая людей) становятся возбужденными и агрессивными. Вдобавок размытые формулировки снимают ответственность с инструктирующего, поскольку если бы он предложил решение — то оно могло бы оказаться тоже неправильным. По сути, он перекладывает риск с себя на ученика.
Разумеется, размытые формулировки при таких раскладах будут чаще встречать отторжение, чем чёткие и недвусмысленные инструкции.
Гм… А с чего вдруг ревьювер — это обязательно учитель/ментор?
С обучением джунов подход совсем другой. Я свою мысль несу про ревью полноценный равновесных коллег.
А если с вами будут говорить точно также? Готовы ли вы принять точно такое отношение и к себе?
Легко. Я люблю когда люди говорят честно и прямо — не надо ничего додумывать.
Могу только восхититься!
Как по мне, то это должно быть нормальным адекватным поведением.
Я часто встречаюсь с ситуацией, что люди не могут отделить код от себя и все, что касается кода они принимают на душу. Вот именно это и есть проблема. Человек может быть сколь угодно хорошим, но если результат его работы попахивает, то комментарии будут именно к результату работы, а не к человеку.

Как мне кажется, первое, чему нужно учить разработчиков — отделяться от кода и не воспринимать его как часть себя. Конечный результат — пожалуйста. Способ его достижения — будь готов спокойно отправить в /dev/null, иначе не будет никакого развития и роста.

P.S. В особых случаях программисты относятся к программе как… «оно как живое, нужно аккуратно вносить изменения» и все в таком духе. Тут каждому должно быть понятно, что архитектурно программа написана настолько их рук вон плохо, что прямо слов нет, только адовые комментарии к коду. Хотя скорее всего тут уже и к кодописателю будут совсем нелестные комментарии.
Ох, не знаю. У меня был коллега, который на подобные вопросы (Как мы будем делать XXX после вашего изменения?) реагировал обидой, воспринимая их подколом (на самом деле здесь должно было быть более экспрессивное слово, но оно нецензурное). Более того, задавая подобные вопросы, вы явно знаете, что вы имеете в виду, но вы об этом не говорите. К чему это приводит? К тому, что если коллега вас не понял, то вы еще долго будете играть в вопрос-ответ. А выглядеть это будет издевательством над тем самым коллегой.
Это изменение изменяет одиночный цикл O(n) на дважды вложенный цикл O(n²); не повлияет ли это на производительность?

«Послушай, разве ты не видишь, что твоему товарищу за шиворот падают капли расплавленного олова?»

UFO just landed and posted this here
Во-первых, его зовут Линус. Во-вторых, линукс с ним после месячного отпуска.
Sign up to leave a comment.

Articles