#code #review

Это ровно то что мы используем в команде и работает очень хорошо

https://devwayoflife.com/2020/06/04/i-made-over-1000-code-reviews-this-is-what-i-learned/

#code #document #review

🧠5 причин почему тебя не слышат в код/документ ревью и что делать 🔭

Ранее Askar S. (@myegothings) попросил рассказать о том как я строю коммуникацию в команде. У меня только сейчас дошли руки (и муза) поделиться своим опытом. Поэтому встречаете несколько советов на тему code review 👀

1. 💆‍♂️Твое предложение не решает никакую конкретную проблему. Каждому программисту свойственно поймать себя в процессе создания чего-то, когда его просто его увлек процесс. Мы как настоящие гики начинаем решать сложную проблему даже там где ее нет.

Что делать: каждый раз когда пишешь комментарий старайся указать на проблему которую ты видишь в предложенном решении. Порой собеседник может просто и не видеть проблему под тем же углом что и ты (или наоборот). Иной раз пока описывая проблему, я сам убеждаюсь, что проблемы то никакой и нету. А иногда, в диалоге понимаю, что эта проблема решается в другом месте и тем самым не является проблемой.

2. ☄️Best practice for the sake of best practice: ты увидел что предложенное решение нарушает best practice, о которой ты недавно вычитал или видел в другом проекте, но в данном случае она может быть быт неактуальной.

Что делать: следовать best practices без четкого понимания какую проблему они решают это очень плохая идея- также как и стараться оптимизировать код на асимптотическую сложность где это не приносит никакой практической выгоды.

3. 🌈Вы обсуждаете Code/Design style во время code review: ты считаешь что нужно написать иначе чтобы было элегантнее/красивее, но у автора другое мнение.

Что делать: если такие вопросы поднимаются не в первый раз, то потрать пару дней на то чтобы составить и согласовать с командой Team Conventions.

Важно понимать, что в этом процессе твоя задача услышать мнения других. Помни про свою начальную цель - ввести определенные стандарты по стилю, даже если они не нравятся тебе лично. (Ну и автоматизируй все что можно автоматизировать, aka Linters)

Это то, что я делаю в каждой команде. После чего я каждый раз ссылаюсь на документ, который утвердила вся команда. если кто то нарушает правила, то это уже между ним и командой

4. ⏳Сейчас не время. Часто твое предложение может решать конкретную проблему и ты видишь что можно что-то сделать иначе. Ведь только это может быть не кстати в данный момент времени.

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

Тем самым нет сильного давления на владельца изначальной задачи, так как мы не только помогаем ему почувствовать что он продвигается, но и помогаем ему выделить на это дополнительное время.

5. ✍️Ты не проделал домашнюю работу. Часто можно начать раздражать своих коллег указывая на их «ошибки», не имея достаточно контекста. Ты думаешь что там есть проблема, но там ее нету.

Что делать: два варианта : 1/когда думаешь что проблема есть, убедись что она есть. Это может потребовать от тебя дополнительных инвестиций в то, чтобы предоставить подтверждения наличия проблемы. Если можешь то собери ссылки и данные. 2/ если нету времени, то лучше задать уточняющий вопрос. У меня это обычно начинается с “I am curious …” Или “double-checking: ….”

🧘‍♂️Ну и в качестве бонуса, не держись за свои идеи слишком сильно. давай своим коллегам побольше простора для собственного мнения.

А каким правилам следуете вы?