спасибо!

спасибо 👍

из моих траншей с передовой, где пишется реальный код, через который проходят реальные деньги реальных людей - мне лично кажется, что design review - какая-то теоретическая туфта в вакууме

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

если фича достаточно фундаментальная, то пишется ещё и ADR с пояснениями
(кто не знает что такое ADR - https://github.com/joelparkerhenderson/architecture-decision-record)

а смотреть на сам код всегда нужно, потому что при правильности дизайна - можно просто в коде сделать что-то неправильно, что видно будет глазами
можно сделать фичу но не покрыть тестами все edge cases
можно функционально всё сделать правильно но в конфиг параметр запихнуть не туда, или назвать неконсистентно, и потом не вырубишь топором
особенно изменения которые наружу торчат в API, должны быть консистентными и гармоничными, иначе возникает technical debt-on-delivery, "грязь" и "шум", которые повышают cognitive load инженеров и как следствие - косты поддержки кода
на этапе code review это починить ничего не стоит, а потом уже часто и невозможно

Ты доклад сначала послушай? Там про все это есть.

ах вот бы где найти ещё 2 часа ... вот если бы какое-то executive summary минут на 20
я просто изначально не согласен с тезисом что code review не нужны и чем-то их можно заменить
формально всегда 4-eyes principle в любой серьёзной организации на любое изменение

ну вот доклад и послушать надо 🙂

https://github.com/sharovatov/teamlead/blob/master/codereview.md вот это еще читнуть можно

в дополнение докладу

Поставь на ускоренной и нужно 15 минут и все.

спасибо, текст познавательный, но

1 неэффективность code review в плане производительности - да, это примерно как pair programming, оно не про производительность, оно про качество результата, обмен знаниями и консистентность, минимизацию шума и создаваемого technical debt
2 линтеры полезны но не заменят code review
3 в токсичной среде, где на сениор позициях царствуют упыри, code review, как и любые другие взаимодействия между индивидуумами, приведут только к увеличению градуса токсичности
очевидно, что сениор упырь будет использовать code review как инструмент для укрепления своей значимости
4 в больших организациях code review _формально_ обязательны, по требованиям от регуляторов

нет, pair programming нельзя сравнивать с код ревью

в плане поиска багов код ревью не приносит чаще всего эффекта

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

очевидно, что сениор упырь будет использовать code review как инструмент для укрепления своей значимости

простите что вклиниваюсь, но вот это такая ЖИЗА, что вот готова подписаться под каждым словом
много где похожие паттерны видимо )

> 3 в токсичной среде, где на сениор позициях царствуют упыри, code review, как и любые другие взаимодействия между индивидуумами, приведут только к увеличению градуса токсичности
очевидно, что сениор упырь будет использовать code review как инструмент для укрепления своей значимости

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

сама суть код ревью побуждает к конфликатм, в статье об этом прямо говорится

подумайте, это кажется очевидным

> 4 в больших организациях code review _формально_ обязательны, по требованиям от регуляторов

это не про величину организации вовсе

есть контуры, где это необходимо (например, PCI DSS)
таких контуров мало

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

Всё-таки какой-то профессионализм нужно развивать в индустрии

да? а я ничего подобного не наблюдаю
может потому что я работаю с нормальными командами, где все вместе друг за друга, code review пишутся дружелюбно и воспринимаются позитивно

вам, может, среду починить, упырей подразогнать, а не на code review пенять, которые "побуждают"?
это примерно как алкоголь, может показаться что он "побуждает к конфликтам", хотя на самом деле просто выпускает наружу то, что в человеке внутри