погоди, нафига?

почему не парно просто ?

зачем приучать делать хуево и прееделывать?

или я чот не так понял 🙁

ну есть уже у людей код ревью, отказываться не собираются, классика

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

а

сорри, я протупил 🙁

Если бы я внедрял уход от Code Review, я бы делал так:
1) Написал бы чеклист для code review: что нужно проверить и о чем думать сейчас.
Там было бы и "проверка кодстайла" и "проверка осмысленности решения" и "знакомство в практиками" и т.п.
2) Внедрял бы новые варианты peer review и вычеркивал пункты из code review
например, добавил линтер и вычеркнул "проверку кодстайла"
добавил design review, вычеркнул "проверка осмысленности решения" и добавил "проверка соответствия design и сode"
3) Потихоньку свел бы чеклист к пустому.

красиво! спасибо

круто

Чеклисты рулят )

чеклисты конечно рулят, кто б спорил
любое осмысление это дорого в плане когнитивной нагрузки, структурирование всегда помогает

но вот это вот вызывает сомнения - добавил design review, вычеркнул "проверка осмысленности решения"
на каком моменте, кто и когда проверит соответствие кода дизайну?
а так же отсутствие в коде всякого палева, которое мог не словить линтер, типа попытка трансформации очень большой и тяжёлой структуры, или же 1000 раз в цикле делание чего-то, чего так часто лучше и не делать?

и это я уже не говорю про консистентность (с человеческой точки зрения) названий параметров в конфигурации ))

Чаечные ревью?

Прочитала "интервью"

😅

Читай внимательно, " добавил "проверка соответствия design и сode"

Представила чаек, которые на камеру интервью дают)

А откуда в коде миддла (хотя бы) такое палево будет? И если perf test не падает, то даже если оно и есть, то какая разница?

А параметры в конфигурации - они вообще в design review должны быть