Pull to refresh

Comments 18

Можно посмотреть как это происходит в chrome: codereview.chromium.org/. По-моему это не совпадает ни с одним из вариантов и лежит между формальной и неформальной инспекциями.
Вот кстати да, в google code (это вроде он) очень грамотно сделали. Есть поток изменений и по каждому ты сразу можешь смотреть дифф и ставить свои комменты. Я в одном своем проекте использовал и нам очень удобно было, самый удобный инструмент для коде ревью, который видел.

У меня на этой и прошлой работе проблема с коде ревью состоит в том, что нет
1) какого то формального способа рассмотреть все коммиты, пройтись по каждому
2) нет формального и прозрачного способа привязать свои вопросы и мысли к коду (сейчас просто рассыпаю TODO комменты в надежде, что их поправят на второй итерации)

Если бы был такой standalone тул, как google code, активно бы его использовал именно для ревью.
Решили недавно в команде из 2 человек, для одного из проектов внедрить регулярное неформальное инспектирование кода.
Товарищ написал 40 строк элементарного javascript кода, я написал 60 строк простейшего php кода. Мы знали, что будем проверять друг друга и от того пытались писать максимально качественно. За 5 минут проверки:

У меня:
3 стилистических ошибки.
1 логический дефект.

У товарища:
2 стилистические ошибки.
1 логическая ошибка.

Не стану приводить исходники, но еще раз заверю, что они были элементарными, а ошибки — глупыми. Мной допущенный дефект тестирование бы не обнаружило. И главное то, что он бы свои ошибки у себя не нашел, а я бы не нашел у себя свои… Инспекция кода — крайне эффективно себя показала, и в дальнейшем без нее — мы не сделаем ни шагу. Рекомендую всем, оценка: 10.
UFO just landed and posted this here
В Agile сложно планировать всю архитектуру с самого начала, приложение строится законченными, работоспособными частями.
Даже хорошие программисты частенько ошибаются. Иногда по мелочи. Вспомним MVC, часто бывает так, что большую часть кода можно убрать из контроллеров в модельный слой. Толстые модели можно разбить по мелким модулям. И так далее.

Все это в целом улучшает архитектуру (если широко смотреть на значение этого слова).
Если бы все можно было изначально правильно продумать и написать с первого раза умные дядьки не придумали бы такую вещь как рефакторинг. Зачастую только в процессе разработки становятся понятными тонкости, а иногда даже написав большой кусок кода понимаешь, что правильнее было бы переписать его совсем по-другому.
Про непрерывность процесса совершенствования кода отлично написано в этой статье.
UFO just landed and posted this here
Снова общие слова и цитаты известных книг.
Главная проблема всех этих слов: книги к тексту которых все оперируют — как правило говорят о большой разработке. много, очень много кода. Но дело в том, что большинство проектов «простые» и «маленькие» и применение подобных методик просто пустая трата ресурсов.
Гораздо интересней вопрос — где же проходит та черта. Я не встречал обоснованного статистикой ответа на этот вопрос. А без него — это всё очередной выпуск бюллетеня КО.
Недавно накосячил в «Hello world» на С. После этого считаю, что в любом проекте инспеция полезная штука.
А так — по опыту, наверное. Кто-то может написать проект размером X без ошибок, кто-то нет.
Отличная статья! Я просмотрел страницы 3 хабра, и это единственный пост действительно полезный! «Совершенный код» считаю лучшей книгой по руководству тех процессом из всех которые я прочитал. Обзор кода по соотношению эффективность/времязатраты лучшее решение для предотвращения ошибок и улучшения качества кода. Только по формальному тестированию я бы делал так, один инспектор до собрания анализирует код, затем вся команда собирается и начинается обсуждение, слишком уж затратно назначать нескольких инспекторов. По экстремальному программированию — считаю достаточным детальное обсуждение архитектуры — построение диаграмм в паре. Например вы обсудили в паре архитектуру, кто-то один реализовал, затем напарник сделал неформальный обзор кода. А спорные вопросы можно выносить на формальные обзоры. Причём формальные обзоры проводить раз в неделю или раз за спринт, т.е. значительно реже.
P.S. Общие правила утверждённые на формальных обзорах обязательно вносятся в wiki проекта, для ознакомления будущих участников проекта и тех членов команды, которые ещё с ними не знакомы.
У нас все было очень просто:
1. Любой feature-код, пишется в отдельной ветке в git-репозитории.
2. Когда код написан, задаче ставится «Решено», о чем уведомляется инспектор кода.
2. Вливать ветку в develop обязан лично инспектор. Он же и просматривает, что он вливает. Если есть замечания, задача переоткрывается, комментарии обычно пишутся прямо к каждой строчке кода в диффе.
3. Если претензий нет, задаче ставится статус «Проверена» и ветка вливается в develop.
Отличный вариант не отнимающий много времени. А по какому принципу у вас назначаются инспекторы на конкретные фичи?
Обычно инспектором выступает главный разработчик конкретного проекта, для которого пишется фича. Этот человек отвечает за архитектуру и развитие проекта в целом, знаком с ним «от» и «до».
Практика показывает, что если такого человека нет, или их несколько, рано или поздно в коде начинается бардак, все что-то делают, но в общем структура проекта теряет целостность, появляется большое количество недоработок и затычек.
Если же что-то пойдет не так, претензии в первую очередь будут предъявлены именно главному разработчику (инспектору), в не зависимости от того, кто, когда и при каких условиях писал проблемный код, потому инспектор явно заинтересован в проведении инспекции кода, вливаемого в его проект.
Sign up to leave a comment.

Articles