Здравствуйте, peer, Вы писали:

P>Есть система написанная год назад. Сейчас система работает в проде, но новые фичи пилятся.
P>Текущее состояние системы очень плохое и хотим внедрить код ревью для начала.
P>Но есть сомнения что текущий код не позволит соблюдать правила кода.

Код-ревью — это когда члены команды просматривают изменения в коде друг друга и дают замечания, если видят проблемы в них.
Оно может внедряться при вообще любом качестве кода системы. Имеет смысл заранее проговорить что и как проводится на код-ревью.
Т.е. замечания "тут надо бы переписать все вот это и еще полсистемы старого, и тогда будет хорошо" они бессмысленны. Замечания должны быть про то, как можно лучше сделать то, что нужно сделать, с имеющимися ресурсами на задачу.

В плане code-style имеет смысл согласовать как нужно писать новый код, и на ревью следить за тем чтобы он соблюдался в новых и изменяемых частях, и и не важно что там в тех частях, которые не затрагиваются текущей задачей (если хочется быстро привести весь код к единому стилю, то под это лучше отдельные задачи заводить). Если на ревью вдруг заметили проблему в "соседней" части кода — это стоит заводить отдельную задачу на исправление (дефект или техдолг, в зависимости от критичности)

P>Я вижу что покрытие системы тестами на ключевых операциях, потом рефактор ключевых проблем в коде и потом внедрение код ревью.
P>Но боюсь что это надолго, а код хочется начать контролировать.

На мой взгляд, код-ревью это одна из самых простых и при этом чуть ли не самая эффективная из методик улучшения кода.
Когда будешь проводить рефакторинг ключевых проблем — в чем беда, что проведенный рефакторинг посмотрит кто-то из коллег? А он может заметить существенную проблему ведь. Взгляд замыливается и со стороны частенько видно лучше.

Да и с тестами то же самое — ты сделал покрытие тестов, коллега посмотрел и подсказал какие случаи остались непокрытыми, или заметил ошибку в тесте

Здравствуйте, peer, Вы писали:

P>Есть система написанная год назад. Сейчас система работает в проде, но новые фичи пилятся.
P>Текущее состояние системы очень плохое и хотим внедрить код ревью для начала.
P>Но есть сомнения что текущий код не позволит соблюдать правила кода.

Код-ревью — это когда члены команды просматривают изменения в коде друг друга и дают замечания, если видят проблемы в них.
Оно может внедряться при вообще любом качестве кода системы. Имеет смысл заранее проговорить что и как проводится на код-ревью.
Т.е. замечания "тут надо бы переписать все вот это и еще полсистемы старого, и тогда будет хорошо" они бессмысленны. Замечания должны быть про то, как можно лучше сделать то, что нужно сделать, с имеющимися ресурсами на задачу.

В плане правил кода имеет смысл согласовать как нужно писать новый код, и на ревью следить за тем чтобы он соблюдался в новых и изменяемых частях, и и не важно что там в тех частях, которые не затрагиваются текущей задачей (если хочется быстро привести весь код к единому стилю, то под это лучше отдельные задачи заводить). Если на ревью вдруг заметили проблему в "соседней" части кода — это стоит заводить отдельную задачу на исправление (дефект или техдолг, в зависимости от критичности)

P>Я вижу что покрытие системы тестами на ключевых операциях, потом рефактор ключевых проблем в коде и потом внедрение код ревью.
P>Но боюсь что это надолго, а код хочется начать контролировать.

На мой взгляд, код-ревью это одна из самых простых и при этом чуть ли не самая эффективная из методик улучшения кода.
Когда будешь проводить рефакторинг ключевых проблем — в чем беда, что проведенный рефакторинг посмотрит кто-то из коллег? А он может заметить существенную проблему ведь. Взгляд замыливается и со стороны частенько видно лучше.

Да и с тестами то же самое — ты сделал покрытие тестов, коллега посмотрел и подсказал какие случаи остались непокрытыми, или заметил ошибку в тесте