В тексте статьи есть упоминание "Инспекция решения (design inspection);", но в итоге предложенное решение всё равно лечит симптомы, а не причины.
Вот этот этап должен быть ДО начала разработки. То есть "подумать над решением, предложить и обосновать (если надо)". На этом же этапе могут быть чеклисты, про что не забыть при имплементации (в т.ч. "если планируются тяжелые sql-запросы или многопоточка, то проконсультироваться/показать эксперту"). После апрува такого дизайна, обращаться к ревьюеру дизайна имеет смысл только в том случае, если во время имплементации стало понятно, что появился drift-решения от согласованного и нужно "пересогласование".
Далее необходимость в код-ревью в принципе отпадет, т.к. если выстроены процессы, где верификация работоспособности кода автоматическая - код проходит все необходимые acceptance-тесты и static analysis (aka "автоматические инспекции кода"), то нет смысла копаться в деталях имплементации. Код ревью становится опциональным и post-factum (ну, типа, разраб может попросить более опытного товарища посмотреть и дать фидбэк, если у автора остались какие-то сомнения)
проблема в том, что приходится с аналитики на русском переводить в коде на английский, а потом в комменте или где-то еще - опять на русский. два преобразования могут давать различия в терминах плюс многие вещи на английском можно выразить короче и яснее.
В ADR есть четыре составляющие:
Prologue (Summary)
Discussion (Context)
Solution (Decision)
Consequences (Results)
В описанном PDR нет Discussion, то есть опций и контекста, из которых делался выбор.
В тексте статьи есть упоминание "Инспекция решения (design inspection);", но в итоге предложенное решение всё равно лечит симптомы, а не причины.
Вот этот этап должен быть ДО начала разработки. То есть "подумать над решением, предложить и обосновать (если надо)". На этом же этапе могут быть чеклисты, про что не забыть при имплементации (в т.ч. "если планируются тяжелые sql-запросы или многопоточка, то проконсультироваться/показать эксперту").
После апрува такого дизайна, обращаться к ревьюеру дизайна имеет смысл только в том случае, если во время имплементации стало понятно, что появился drift-решения от согласованного и нужно "пересогласование".
Далее необходимость в код-ревью в принципе отпадет, т.к. если выстроены процессы, где верификация работоспособности кода автоматическая - код проходит все необходимые acceptance-тесты и static analysis (aka "автоматические инспекции кода"), то нет смысла копаться в деталях имплементации. Код ревью становится опциональным и post-factum (ну, типа, разраб может попросить более опытного товарища посмотреть и дать фидбэк, если у автора остались какие-то сомнения)
проблема в том, что приходится с аналитики на русском переводить в коде на английский, а потом в комменте или где-то еще - опять на русский. два преобразования могут давать различия в терминах плюс многие вещи на английском можно выразить короче и яснее.