Dev Easy Notes

Я как вчера помню свой первый МР (мерж реквест) на проекте с командой больше 1-го разработчика. То что сделали с моим МРом можно смело выкладывать в оранжевый ютуб. Мне тогда накидали 40 комментариев за 5 минут. На проекте работали крайне педантичные разработчики, которые докапывались до каждой строчки кода. Разумеется работая в такой компании, ты рано или поздно сам становишься таким же педантичным фанатиком. Я мог докопаться до чего угодно, до форматирования, до названия переменных, до прически автора. 

Продолжалось это до тех пор, пока на очередном ревью не задал себе вопрос: “а не херней ли я страдаю?”. В ответ на вопрос мне явилось ведение в виде Линуса Торвальдса который сказал мне, что даже для него это слишком. И после этого я понял две вещи: что стоит завязывать работать под грибами, а также нужно пересмотреть свое отношение к ревью кода. 

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

И я сформулировал для себя несколько основных правил, как правильно делать код ревью. В основе этих правил простой принцип: “Не доебывайся до мелочей”.  Все крайне просто, комментирую я код только в 3-х случаях. 

1️⃣ Когда вижу что разработчик делает откровенную херню. Не просто, что решение “не самое лучше”, или что “можно сделать красивее”, а вот прям нельзя. Ебанет если так сделать, и я могу четко с пруфами объяснить почему. 

2️⃣ Когда вижу что разработчик начал пилить велосипед, когда уже есть готовый компонент в проекте. Или когда кто-то начал для простой задачи выдумывать супер крутую архитектуру, которая закладывает фундамент для будущего. В некотором смысле это можно отнести к предыдущему пункту.

3️⃣ Четкое нарушение конвенций, которые приняла вся команда. При возникновении спорного момента или если такого нет в конвенциях, то сначала выносим на обсуждение и только потом можем докапываться в МР. Если же у вас нет принятых конвенций в команде, тогда на основе чего вы решили доебаться? На основе своих ощущений прекрасного?

Все вот эти вещи вроде: “можно сделать короче“, “в будущем возможно понадобится X, давай переделам”, “так нельзя писать код” идут лесом. Туда же идут всякие идеи по микрооптимизации некритичного кода. 

Мне рассказывали забавные истории про тимлида который оставлял комментарии типа: “Ыыы исправь!” и это блять не шутка. Не можешь четко сформулировать что не так – сиди, блять, помалкивай или иди учиться формулировать свои мысли.

🔥69👍19😁6👎2❤1

www.tgoop.com/dev_easy_notes/278

4.1K viewsNikita, Jan 22, 2024 at 08:22

Я как вчера помню свой первый МР (мерж реквест) на проекте с командой больше 1-го разработчика. То что сделали с моим МРом можно смело выкладывать в оранжевый ютуб. Мне тогда накидали 40 комментариев за 5 минут. На проекте работали крайне педантичные разработчики, которые докапывались до каждой строчки кода. Разумеется работая в такой компании, ты рано или поздно сам становишься таким же педантичным фанатиком. Я мог докопаться до чего угодно, до форматирования, до названия переменных, до прически автора. 

Продолжалось это до тех пор, пока на очередном ревью не задал себе вопрос: “а не херней ли я страдаю?”. В ответ на вопрос мне явилось ведение в виде Линуса Торвальдса который сказал мне, что даже для него это слишком. И после этого я понял две вещи: что стоит завязывать работать под грибами, а также нужно пересмотреть свое отношение к ревью кода. 

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

И я сформулировал для себя несколько основных правил, как правильно делать код ревью. В основе этих правил простой принцип: “Не доебывайся до мелочей”.  Все крайне просто, комментирую я код только в 3-х случаях. 

1️⃣ Когда вижу что разработчик делает откровенную херню. Не просто, что решение “не самое лучше”, или что “можно сделать красивее”, а вот прям нельзя. Ебанет если так сделать, и я могу четко с пруфами объяснить почему. 

2️⃣ Когда вижу что разработчик начал пилить велосипед, когда уже есть готовый компонент в проекте. Или когда кто-то начал для простой задачи выдумывать супер крутую архитектуру, которая закладывает фундамент для будущего. В некотором смысле это можно отнести к предыдущему пункту.

3️⃣ Четкое нарушение конвенций, которые приняла вся команда. При возникновении спорного момента или если такого нет в конвенциях, то сначала выносим на обсуждение и только потом можем докапываться в МР. Если же у вас нет принятых конвенций в команде, тогда на основе чего вы решили доебаться? На основе своих ощущений прекрасного?

Все вот эти вещи вроде: “можно сделать короче“, “в будущем возможно понадобится X, давай переделам”, “так нельзя писать код” идут лесом. Туда же идут всякие идеи по микрооптимизации некритичного кода. 

Мне рассказывали забавные истории про тимлида который оставлял комментарии типа: “Ыыы исправь!” и это блять не шутка. Не можешь четко сформулировать что не так – сиди, блять, помалкивай или иди учиться формулировать свои мысли.

BY Dev Easy Notes