Привет, Хабр! Я — один из команды разработчиков SmartNut, web-сервиса для небольших компаний, занимающихся поддержкой и it-аутсорсингом. Мы гордимся тем, что мы делаем и ничуть не меньше тем, как мы это делаем. Хочу поделиться с вами историей из реальной жизни на тему code review.
Все люди внутри перфекционисты. Если Вы не видите этого в человеке, то это совсем не означает, что этого в человеке нет. Возможно, у себя дома у него идеальный порядок, хотя код он пишет и не очень. Другой же наоборот, может держать порядок в коде или в машине, но где-то попустительствовать в отношении себя.
Однако, проще всего найти перфекциониста в отношении к окружающим. Очень просто требовать идеального выполнения работы, конечно, если ты сам знаешь как её хорошо делать.
Программист Вася писал строки кода, проверял их. Возможно, писал какие-то тесты, а может быть и не писал. После чего со спокойной душой коммитил в общий репозиторий. Через некоторое время другие программисты, изучая код новой ревизии и видя что написал Вася,вскрывали себе вены и делали харакири приходили к Васе и вскрывали ему вены и делали себе харакири рассказывали, что не так, и как можно было сделать лучше. Вася покорно соглашался, все получали удовлетворение, но код оставался как есть, т.к. уже был закоммичен и, возможно протестирован. И по нему были исправлены ошибки.
Многие из нас знакомы с практиками eXtreme Programming. Одна из них — это парное программирование. По опыту очень сложно полноценно использовать данную практику — сложно отказаться от “личного пространства”, сложно “продать” эту практику начальству (“программисты будут работать в два раза медленнее?!”) и т.п.
Но можно начать есть слона по частям. Первая часть — code review!
Программист Вася выполнил задачу. Чтобы задача считалась выполненной, нужно, чтобы она прошла через колонку code review на нашей scrum доске.
Таким образом мы:
А чтобы не было вопросов “кто должен провести Code Review?” каждую итерацию у нас есть дежурный по проведению данной процедуры.
Мы не используем какой-либо дополнительный инструментарий для Code Review, а всегда садимся вместе и просматриваем изменения.
Использование каких-то инструментов в данном случае только замедлит процесс. Если вы находитесь в одной комнате, то незачем заниматься email-пинг-понгом — намного проще и понятнее объяснить всё словами, а лучше — показать. К тому же, личное общение намного полезнее для развития каждого сотрудника и для команды в целом.
Так мы делаем smartnut.ru и вам того же желаем.
Будьте гибче, друзья, и до новых встреч!
Все люди внутри перфекционисты. Если Вы не видите этого в человеке, то это совсем не означает, что этого в человеке нет. Возможно, у себя дома у него идеальный порядок, хотя код он пишет и не очень. Другой же наоборот, может держать порядок в коде или в машине, но где-то попустительствовать в отношении себя.
Однако, проще всего найти перфекциониста в отношении к окружающим. Очень просто требовать идеального выполнения работы, конечно, если ты сам знаешь как её хорошо делать.
Как у нас процесс выглядел раньше
Программист Вася писал строки кода, проверял их. Возможно, писал какие-то тесты, а может быть и не писал. После чего со спокойной душой коммитил в общий репозиторий. Через некоторое время другие программисты, изучая код новой ревизии и видя что написал Вася,
Как стало
Многие из нас знакомы с практиками eXtreme Programming. Одна из них — это парное программирование. По опыту очень сложно полноценно использовать данную практику — сложно отказаться от “личного пространства”, сложно “продать” эту практику начальству (“программисты будут работать в два раза медленнее?!”) и т.п.
Но можно начать есть слона по частям. Первая часть — code review!
Программист Вася выполнил задачу. Чтобы задача считалась выполненной, нужно, чтобы она прошла через колонку code review на нашей scrum доске.
Таким образом мы:
- получаем анализ кода другим программистом ещё до коммита;
- улучшаем дизайн кода;
- передаём знания на ранней стадии;
- избавляемся от некоторого количества очевидных ошибок, невидимых для замыленного глаза Васи.
А чтобы не было вопросов “кто должен провести Code Review?” каждую итерацию у нас есть дежурный по проведению данной процедуры.
Мы не используем какой-либо дополнительный инструментарий для Code Review, а всегда садимся вместе и просматриваем изменения.
Использование каких-то инструментов в данном случае только замедлит процесс. Если вы находитесь в одной комнате, то незачем заниматься email-пинг-понгом — намного проще и понятнее объяснить всё словами, а лучше — показать. К тому же, личное общение намного полезнее для развития каждого сотрудника и для команды в целом.
Так мы делаем smartnut.ru и вам того же желаем.
Будьте гибче, друзья, и до новых встреч!
