Вопрос был только что в группе JuJa.
Який код ревью вважаєте більш оптимальним? По задачним (програміст-тімлід) чи командним по кожній задачі. Чи все ж таки че залежить від наявності часу на проекті?
Много ко многим. Все смотрят все. Коллективное владение кодом. Как в XP Смайлик «smile»
Пробовал несколько форматов:
1) Команда собирается и все смотрят diff за какой-то промежуток времени - где-то раз в неделю. С попкорном, шутками. А тот, чей код смотрят - записывает замечания :) На мой вопрос "а мы жеж не весь код успеваем посмотреть..." Менеджер отвечал - "тут как ППС и писюны в подворотне, они каждый день циркулируют по маршруту, сегодня собрали двоих штрафанули, завтра еще одного, потом еще двоих и так со временем все писюны будут наказаны"
2) В команде где два фронт и два бекенд дивелопера. Мы либо решаем задачи (когда сложно) в парах, либо каждый решает свою часть а потом мерджим не только в мастер, но и в понимании друг-друга (я объясняю свою, часть напарник свою).
3) Самокодревью - когда ты перед коммитом сам просматриваешь свои diff и критичненько так относишься к коду расставляя тудушки или фикся походу сразу. Часто тут всплывают всякие экспериментыльные какашульки, которые не стоило коммитить но удалить забыл. Тудушки ставлю, потому как хочется залить в мастер уже через 10 минут, если могу фиксить сразу в течении этого времени - фикшу, иначе туду. Чтобы кодревью небыло кайфоломом - иначе будет подсознательно ломать в будущем делать ревью.
4) Кодревью бывало записывал на видос перед коммитом скринрекодером и выставлял линк в коммите. Кто хотел, потом мог изучить подробно. Обычно, когда готовишь код на показ, хочется его сделать как можно более классняцким.
5) Бывало и такое, что тимлид грозно разрушал код своим кодревью, в таком случае не стоит ожидать, что код пойдет в мастер когда он по твоему "готов" и просто воспринимать это как очередной этап доделки. Иногда бывало, что Архитектор смотрел код, тогда не то что доделки, переделки случались. Бывало и такое, что 3 итерации были как "классно, давай запомним, и попробуем еще такой вариант - а потом выберем что лучше". Это классный опыт был, сильно прокачался тогда.
6) В процессе обучения или если есть свободное время ребятам советую подобных к 5) подход - написал, работает? попробуй сделай то же но иначе, а потом сравни результаты. Тут рефакторинг прокачивается.
7) Самое лучшее код ревью, конечно же в парном программировании - там оно всегда по чуть-чуть.
8) Еще одна рекомендация - смотреть на свой код (уде реализованную фичу) спустя несколько дней (или как минимум мерджить после сна). Смотришь на свой код и думаешь - от блин...
И вообще, код надо постоянно допиливать, если к нему не вазвращаешься - он устаревает. Чем больше к нему подходов, тем класснее он становится.
Не будет ломать до- или переделывать когда у тебя есть тесты. Не будет ломать до- или переделывать работу, когда у тебя есть тесты. Рефакторинг с тестами не только безопасен, но и начинает приносить удовольствие. А кодревью - это заявка на рефакторинг.
Не будет ломать до- или переделывать когда у тебя есть тесты. Не будет ломать до- или переделывать работу, когда у тебя есть тесты. Рефакторинг с тестами не только безопасен, но и начинает приносить удовольствие. А кодревью - это заявка на рефакторинг.
Какашульки в коде есть всегда. И да! Никаких деплоев в пятницу вечером!
Как-то так
Комментариев нет:
Отправить комментарий