Есть система написанная год назад. Сейчас система работает в проде, но новые фичи пилятся.
Текущее состояние системы очень плохое и хотим внедрить код ревью для начала.
Но есть сомнения что текущий код не позволит соблюдать правила кода.
Я вижу что покрытие системы тестами на ключевых операциях, потом рефактор ключевых проблем в коде и потом внедрение код ревью.
Но боюсь что это надолго, а код хочется начать контролировать.
Здравствуйте, peer, Вы писали:
P>Текущее состояние системы очень плохое и хотим внедрить код ревью для начала.
Почему Вы считаете, что состояние системы "плохое". В чем это выражается?
P>Но есть сомнения что текущий код не позволит соблюдать правила кода.
Не надо создавать слишком сложные правила кода. Начните с малого — хотя бы просто приучите людей к ревью.
Для этого нужно ревью сделать обязательным перед заливкой в мастер-ветку. Это само по себе уже даст прибавку в качестве кода.
Требования к коду можно добавлять/усиливать по мере улучшения кодовой базы.
P>Я вижу что покрытие системы тестами на ключевых операциях, потом рефактор ключевых проблем в коде и потом внедрение код ревью.
Нужно поощрять писать хоть какие-то осмысленные юнит-тесты. Это можно включить в правила ревью.
Но нужно учитывать, что при плохом качестве кода иногда невозможно протестировать вообще.
На существующий код можно (и нужно) написать функциональные тесты.
Это позволит отрефакторить основные проблемные участки.
Здравствуйте, peer, Вы писали:
P>Есть система написанная год назад. Сейчас система работает в проде, но новые фичи пилятся. P>Текущее состояние системы очень плохое и хотим внедрить код ревью для начала. P>Но есть сомнения что текущий код не позволит соблюдать правила кода.
Код-ревью — это когда члены команды просматривают изменения в коде друг друга и дают замечания, если видят проблемы в них.
Оно может внедряться при вообще любом качестве кода системы. Имеет смысл заранее проговорить что и как проводится на код-ревью.
Т.е. замечания "тут надо бы переписать все вот это и еще полсистемы старого, и тогда будет хорошо" они бессмысленны. Замечания должны быть про то, как можно лучше сделать то, что нужно сделать, с имеющимися ресурсами на задачу.
В плане правил кода имеет смысл согласовать как нужно писать новый код, и на ревью следить за тем чтобы он соблюдался в новых и изменяемых частях, и и не важно что там в тех частях, которые не затрагиваются текущей задачей (если хочется быстро привести весь код к единому стилю, то под это лучше отдельные задачи заводить). Если на ревью вдруг заметили проблему в "соседней" части кода — это стоит заводить отдельную задачу на исправление (дефект или техдолг, в зависимости от критичности)
P>Я вижу что покрытие системы тестами на ключевых операциях, потом рефактор ключевых проблем в коде и потом внедрение код ревью. P>Но боюсь что это надолго, а код хочется начать контролировать.
На мой взгляд, код-ревью это одна из самых простых и при этом чуть ли не самая эффективная из методик улучшения кода.
Когда будешь проводить рефакторинг ключевых проблем — в чем беда, что проведенный рефакторинг посмотрит кто-то из коллег? А он может заметить существенную проблему ведь. Взгляд замыливается и со стороны частенько видно лучше.
Да и с тестами то же самое — ты сделал покрытие тестов, коллега посмотрел и подсказал какие случаи остались непокрытыми, или заметил ошибку в тесте
Здравствуйте, peer, Вы писали:
P>Текущее состояние системы очень плохое и хотим внедрить код ревью для начала. P>Но есть сомнения что текущий код не позволит соблюдать правила кода.
Какое отношения имеют правила или тесты к код ревью? Код ревью это о том, что один (или несколько) разработчиков посмотрят на чужой код и напишут к нему замечания или одобрения. Правила и тесты это как бы отдельный вопрос.
P>Я вижу что покрытие системы тестами на ключевых операциях, потом рефактор ключевых проблем в коде и потом внедрение код ревью. P>Но боюсь что это надолго, а код хочется начать контролировать.
Я предлагаю отделять мух от котлет. Код ревью в любом случае штука полезная. И без правил и тестов.
А покрывать тестами и рефакторить — это может быть надо, а может быть и пустой тратой времени. Без специфики не скажешь. Но в целом скорей всего это будет в конечном счёте полезно, если удастся убедить руководство тратить ресурсы на деятельность, не приносящую прямого дохода.
Здравствуйте, peer, Вы писали:
P>Есть система написанная год назад. Сейчас система работает в проде, но новые фичи пилятся. P>Текущее состояние системы очень плохое и хотим внедрить код ревью для начала. P>Но есть сомнения что текущий код не позволит соблюдать правила кода.
Ну вы выработайте себе какие-то разумные правила написания нового кода, с учетом имеющейся реальности, и контролируйте их соблюдение на review.
Вообще, смысл core review не в том, чтобы придумать какие-то бессмысленные правила, и обцессивно им следовать, а в том, чтобы на новый код посмотрел второй человек. Свои собственные глаза нередко "замыливаются" и не видят очевидных проблем, которых другой человек легко увидит, посмотрев свежим взглядом.
А правила, ну, нет смысла контролировать каждую запятую. В принципе, правила должны упрощать людям жизнь, а не усложнять. Любые разумные правила сводятся к поддержанию единого стиля, к тому, чтобы код был читаемым и к тому, чтобы программисты избегали стремных конструкций.
Б>Но нужно учитывать, что при плохом качестве кода иногда невозможно протестировать вообще.
Получается код который нельзя протестировать плох?
Если код работает его можно протестировать на стенде.
Вот если и так нельзя, то да тут уже конкретный монолит.
Здравствуйте, peer, Вы писали:
P>Есть система написанная год назад. Сейчас система работает в проде, но новые фичи пилятся. P>Текущее состояние системы очень плохое и хотим внедрить код ревью для начала. P>Но есть сомнения что текущий код не позволит соблюдать правила кода.
P>Я вижу что покрытие системы тестами на ключевых операциях, потом рефактор ключевых проблем в коде и потом внедрение код ревью. P>Но боюсь что это надолго, а код хочется начать контролировать.
P>Ваши мысли
Если команда нормальная ревью на любой коммит (всех веток: и транка и рефакторинга и фичи).
Прямо сейчас.
Так будут ловится откровенные косяки и работать будет веселей.
Здравствуйте, fmiracle, Вы писали:
F>Код-ревью — это когда члены команды просматривают изменения в коде друг друга и дают замечания, если видят проблемы в них.
Почему? Ничто не мешает под этим термином понимать и ревью существующего кода.
Да, чаще про это говорят "аудит", но формально противоречия нет.
Вероятно, ТС просто не знает, какие тут стандартные термины.
F>Оно может внедряться при вообще любом качестве кода системы. Имеет смысл заранее проговорить что и как проводится на код-ревью. F>Т.е. замечания "тут надо бы переписать все вот это и еще полсистемы старого, и тогда будет хорошо" они бессмысленны. Замечания должны быть про то, как можно лучше сделать то, что нужно сделать, с имеющимися ресурсами на задачу.
Вполне осмысленны, если из них следует или что надо перед изменениями поставить рефакторинг, или что он уйдёт потом в отдельную задачу. Дальше весь вопрос в том, кто что успевает.
F>На мой взгляд, код-ревью это одна из самых простых и при этом чуть ли не самая эффективная из методик улучшения кода. F>Когда будешь проводить рефакторинг ключевых проблем — в чем беда, что проведенный рефакторинг посмотрит кто-то из коллег? А он может заметить существенную проблему ведь. Взгляд замыливается и со стороны частенько видно лучше.
Здравствуйте, vaa, Вы писали:
Б>>Но нужно учитывать, что при плохом качестве кода иногда невозможно протестировать вообще. vaa>Получается код который нельзя протестировать плох?
В общем да. Исключения для чего-то уровня песочницы — неинтересны в общем случае.
vaa>Если код работает его можно протестировать на стенде.
Или ты не покроешь все случаи, или это будет чрезмерно дорого.
Компонентное тестирование, начиная с юнит-тестов, тут удешевляет процесс на порядки, позволяет автоматизацию тестирования...
