Давайте представим гипотетическую ситуацию, вас в команде 2-3 сеньора +

тимлид
можно ли в такой команде отказаться от код ревью?
если да, то какие условия должны быть реализованы, чтобы можно было отказаться (ну аля четкий беклог и декомпозированные юзерстори, etc)

есть много инструментов, которые автоматизируют эту оценку и ищут баги

ни один статический анализатор не заменит человеческого мозга)

запишитесь на мой курс, я расскажу про баланс между кодом и бизнесом

человеческий мозг тоже довольно часто дает промахи, иначе бы не было ни этих инструментов, ни QA как пласта 😁

в таких случаях делают дабл-ревью

самая главная метрика - читабельность эту проверку не заменишь ничем

Та ты уже всё раньше рассказал, я себе цитаты главные сохранил.

а если сложившаяся команда из сеньоров только, все уже знают, как пишут

а потом трипл? :) время поставки фичи затягивается

знают, что точно коллега ничего не забудет ? ванги в деле

где гарантия, что ревьювер тоже ничего не забудет? да и второй ревьювер тоже? у всех свои задачи нарезаны, и ревьюверы не всегда будут погружаться в твою

разработка вообще сложная сфера

нет гарантий, но на опыте, частенько кто-то подсвечивает моменты сторонний взгляд

может быть тогда позитивные сценарии, которые описаны в фиче, просто покрывать тестами, и тогда будет гарантия, что ничего не забудется?

тесты тоже надо ревьювить

ревью помогает: 1) отследить какие-то моменты, которые могли быть упущены, какие-то незаметные баги и тд 2) всем участникам команды быть в контесте сделанного 3) возможность отслеживать взаимодействие между разными тасками ( условно говоря, можно на ревью попросить не мержить таску, пока не замержена другая, чтобы конфликтов меньше было) 4) отследить кодстайл и тд

нет, покрыл ситуации: А, А1 и А2, Б1 и Б2 приходит коллега и говорит, слушай, а мы же тогда обсудили закроиться под АБ, а тут у тебя все на А или Б завязано и я уже под эту догвооренность кода понаписал

2, 3, 4 - всё это уже давным давно автоматизировано

Может ещё и от qa отказаться? И от тестов? )))

как автоматизировать то, чтобы коллеги были в контексте сделанного?

когда коллега вспомнит такое, то он придет и так, без код ревью

это достигается скрамом и прочими методологиями мы же все по скраму работаем 😁

он даже не посмотрит на код

лучше на код-ревью

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

В одной из компаний, куда я собесился, мне сказали, что у них нет qa, а код тестируется разработчиками с помощью тестов.

"в контексте сделанного" это не только закрытые таски. Важно также делиться кодовой базой чтобы пока занимаешься своей задачей, по итогу не обнаружил что рядом приложение превратилось во что-то чего ты не понимаешь + чтобы обращать внимание на используемые утилиты и не городить свои

Мнэ... И разрабов еще, небось, штрафовали за баги в проде? ))

это опять же всё заменяется атмосферой в команде, если вы постоянно общаетесь и делитесь какими-то подходами, то у тебя нет необходимости смотреть, кто же какие утилиты где заюзал

Сеньоры если что тоже люди, а не идеальные боги, которые никогда не ошибаются.

никто с этим не спорит, тут скорее вопрос, что важнее, поставлять фичи на прод, или тратить высокооплачиваемое время на это?

Если у вас стартап где нужно быстрей быстрей катить фичи, то конечно не стоит. Если хочется долго поддерживаемый продукт, то ревью необходимо.

а как одно противоречит другому? Важно поставлять хорошо проверенные и отревьюеренные фичи на прод И иногда лучше немного фичу задержать и проверить, чем выпускать пораньше

мы сейчас всё свели к микросервисам (только ситхи всё возводят в абсолют 😁), и, как правило, микросервис - это не долго поддерживаемый продукт "идеальный микросервис пишется одним человеком за 2 недели" (c) нужен ли тут код ревью?

А то есть вы каждый раз по две недели микросервисы переписываете когда нужно новую фичу вводить?

Лень проводить - значит нахер надо

А как ты для себя даёшь определение микросервисам ?(Просто офтоп интересный)

новая фича - это новый микросервис, по заветам, так сказать @MikhailGulkin это и на твой вопрос ответ но это в идеале конечно, в реальности всё сугубу индивидуально

Микросервисы - это тоже код, который тоже нужно поддерживать. Плюс микросервисы сложнее монолита. Особенно в плане архитектуры. Если неправильно их приготовить, то будут серьёзные проблемы в итоге. Поэтому всегда лучше делать монолит пока не упрётесь в его ограничения.

А старые фичи не меняются никогда, да?

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