Если нельзя, но очень хочется, то нужно обязательно и ничего в мире не стоит того, чтобы делать из этого проблему!


Интересна Java? Кликай по ссылке и изучай!
Если тебе полезно что-то из того, чем я делюсь в своем блоге - можешь поделиться своими деньгами со мной.
с пожеланием
столько времени читатели провели на блоге - 
сейчас онлайн - 

среда, 30 сентября 2015 г.

Какашульки в коде


Вопрос был только что в группе JuJa.
Який код ревью вважаєте більш оптимальним? По задачним (програміст-тімлід) чи командним по кожній задачі. Чи все ж таки че залежить від наявності часу на проекті?
Много ко многим. Все смотрят все. Коллективное владение кодом. Как в XP Смайлик «smile»

Пробовал несколько форматов: 
1) Команда собирается и все смотрят diff за какой-то промежуток времени - где-то раз в неделю. С попкорном, шутками. А тот, чей код смотрят - записывает замечания :) На мой вопрос "а мы жеж не весь код успеваем посмотреть..." Менеджер отвечал - "тут как ППС и писюны в подворотне, они каждый день циркулируют по маршруту, сегодня собрали двоих штрафанули, завтра еще одного, потом еще двоих и так со временем все писюны будут наказаны"

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

3) Самокодревью - когда ты перед коммитом сам просматриваешь свои diff и критичненько так относишься к коду расставляя тудушки или фикся походу сразу. Часто тут всплывают всякие экспериментыльные какашульки, которые не стоило коммитить но удалить забыл. Тудушки ставлю, потому как хочется залить в мастер уже через 10 минут, если могу фиксить сразу в течении этого времени - фикшу, иначе туду. Чтобы кодревью небыло кайфоломом - иначе будет подсознательно ломать в будущем делать ревью.

4) Кодревью бывало записывал на видос перед коммитом скринрекодером и выставлял линк в коммите. Кто хотел, потом мог изучить подробно. Обычно, когда готовишь код на показ, хочется его сделать как можно более классняцким.

5) Бывало и такое, что тимлид грозно разрушал код своим кодревью, в таком случае не стоит ожидать, что код пойдет в мастер когда он по твоему "готов" и просто воспринимать это как очередной этап доделки. Иногда бывало, что Архитектор смотрел код, тогда не то что доделки, переделки случались. Бывало и такое, что 3 итерации были как "классно, давай запомним, и попробуем еще такой вариант - а потом выберем что лучше". Это классный опыт был, сильно прокачался тогда.

6) В процессе обучения или если есть свободное время ребятам советую подобных к 5) подход - написал, работает? попробуй сделай то же но иначе, а потом сравни результаты. Тут рефакторинг прокачивается. 

7) Самое лучшее код ревью, конечно же в парном программировании - там оно всегда по чуть-чуть. 

8) Еще одна рекомендация - смотреть на свой код (уде реализованную фичу) спустя несколько дней (или как минимум мерджить после сна). Смотришь на свой код и думаешь - от блин...

И вообще, код надо постоянно допиливать, если к нему не вазвращаешься - он устаревает. Чем больше к нему подходов, тем класснее он становится.

Не будет ломать до- или переделывать когда у тебя есть тесты. Не будет ломать до- или переделывать работу, когда у тебя есть тесты. Рефакторинг с тестами не только безопасен, но и начинает приносить удовольствие. А кодревью - это заявка на рефакторинг.

Какашульки в коде есть всегда. И да! Никаких деплоев в пятницу вечером!

Как-то так

Комментариев нет:

Отправить комментарий