наличие регулярных кодревью выливается в минимум двоих людей знакомых с каждым отдельно взятым куском кода, а так же решает проблему "сделаю криво -- потом поправишь". и никакого запугивания не надо :)
У нас с кодревью как раз все очень неплохо. И был еще человек, который теоретически мог это сделать хорошо и быстро. Проблема была только в том, что он был занят на супер важной и срочной фиче C, и привлечь его не было возможности.
у нас такое обычно решается тем, что неопытный человек (в твоем случае, ты) шлет на ревью драфт реализации опытному, опытный делает замечания, и только после этого реализация доводится до конца и шлифуется... просто чтобы не было "а косяки потом поправим" хотя бы в плане грубых ошибок.
Ну как бы это, код ревью сложной фичи, реализованной неумелым человеком, может потребовать времени, вполне сравнимого с реализацией фичи самим ревьюером. И уж точно сравнимо по времени с "косяки потом поправим".
Вопрос спорный, время ревью очень сильно падает с ростом навыка (написать "тут надо было сделать через Б, а не через А" занимает пару минут, а мелочи можно проверять только на финальном этапе).
Что точно, так это то, что если фичу сделал "ревьювер", то и следующую опять придется делать ему. В случае же делегирования кодобаза получает нового человека, который с ней умеет работать.
Разумеется, как всегда, вопрос баланса: если случай исключительный, и еще один человек не нужен, то зачастую проще подождать/загрузить тех, кто есть (как это сделал Тимур). Если же тех, кто есть, регулярно не хватает -- через такие ревью их количество увеличивается вполне естественным путем без ущерба для кодобазы.
Я о сложных и писал, "А" и "Б" подразумевали что-то архитектурное и высокоуровневое, что требует понимания системы, которым, предположительно, новый человек не обладает, и потому требует ревью от более опытного коллеги. А не вещи в духе "тут надо массив на ArrayList заменить".
Каким образом этот пример требует понимания существующей системы?
Тимур писал про "фичу", которую надо реализовать внутри существующей системы. У таких задач всегда больше объем, чем хотелось бы: надо решить, как реализовывать фичу; обсудить ее со всеми заинтересованными сторонами; написать код и отладить его; покрыть хотя бы бегло тестами; починить и обновить те тесты, которые сломались или перестали иметь смысл; поправить доки; убедиться, что после коммита ничего не сломалось, и починить, если сломалось; ответить на вопросы тех, у кого они появятся после коммита, и объяснить, как фичей пользоваться; добавить диагностику для админов; выкатить фичу пользователям, и т.п.
Ревью краткого дизайн дока, и чуть позже его реализации -- легко может быть каплей в море. Все это вопрос того, о какого масштаба "фиче" шла речь.
Ну в общем в моем случае кодревью качественной реализации заняло бы время, сравнимое с реализацией, может даже больше. То что я предлагал сделать самостоятельно - это был костыль, который бы прокатил для горящего срока, но потом его бы пришлось вырезать и переписывать по нормальному. И на первом месте был именно вопрос сроков, а все остальное было сильно вторично.
> В случае же делегирования кодобаза получает нового человека, который с ней умеет работать.
Серебрянной пули нет. Введение нового человека в процесс один чорт занимает столько времени, что в среднесрочной перспективе себя не оправдывает от слова "совсем". Оправдывает либо если надо срочно забить шуруп кувалдой и гори оно всё после этого, либо если закладываться на годы вперёд. В последнем случае что код ревью, что парное программирование, что старое-доброе "бросили в воду - плыви" приблизительно одинаково.
Reply
Reply
Reply
Reply
Что точно, так это то, что если фичу сделал "ревьювер", то и следующую опять придется делать ему. В случае же делегирования кодобаза получает нового человека, который с ней умеет работать.
Разумеется, как всегда, вопрос баланса: если случай исключительный, и еще один человек не нужен, то зачастую проще подождать/загрузить тех, кто есть (как это сделал Тимур). Если же тех, кто есть, регулярно не хватает -- через такие ревью их количество увеличивается вполне естественным путем без ущерба для кодобазы.
Reply
> написать "тут надо было сделать через Б, а не через А" занимает пару минут
Так и в коде об этом написать занимает сравнимое время. Речь о сложных фичах, а не о правописании.
Reply
Reply
Reply
Время на ревью совпадает со временем на написание - проверить что все плюс-минус 1 ошибки, путаницу с < и <=.
Reply
Тимур писал про "фичу", которую надо реализовать внутри существующей системы. У таких задач всегда больше объем, чем хотелось бы: надо решить, как реализовывать фичу; обсудить ее со всеми заинтересованными сторонами; написать код и отладить его; покрыть хотя бы бегло тестами; починить и обновить те тесты, которые сломались или перестали иметь смысл; поправить доки; убедиться, что после коммита ничего не сломалось, и починить, если сломалось; ответить на вопросы тех, у кого они появятся после коммита, и объяснить, как фичей пользоваться; добавить диагностику для админов; выкатить фичу пользователям, и т.п.
Ревью краткого дизайн дока, и чуть позже его реализации -- легко может быть каплей в море. Все это вопрос того, о какого масштаба "фиче" шла речь.
Reply
Reply
Reply
Серебрянной пули нет. Введение нового человека в процесс один чорт занимает столько времени, что в среднесрочной перспективе себя не оправдывает от слова "совсем". Оправдывает либо если надо срочно забить шуруп кувалдой и гори оно всё после этого, либо если закладываться на годы вперёд. В последнем случае что код ревью, что парное программирование, что старое-доброе "бросили в воду - плыви" приблизительно одинаково.
Reply
Leave a comment