ну да. у нас и фичи такие есть, типа предоставить crud api, отослать в определенный момент емейл и так далее. Это примерно как UI баги на фронте. типа низкоприоритные фичи на беке.
Обычно онбординг выглядит примерно так: - инструкции по разворачиванию среды - описание домена и архитектуры - code style/чеклисты/HowTo - специально подобранные задачи для входа в проект - выделенный бадди, который первые задачи делает в режиме "непрерывного ревью" (или вообще парное программирование с бадди на его задачах). - задачи по написанному техдизайну (c review по запросу) - написание своего техдизайна Но если в "задаче по техдизайну" вылезают антипаттерны - то это проблема или бадди или тимлида, не новичка.
И где тут "code review с наваливанием реджектов" как метод обучения? Реджект на code review при онбординге - это сигнал проблем с обучением, это надо идти и говорить с бадди и с лидом
Не, надо не просто реджектнуть, а выяснять, почему он сделал что-то, несоответсвующее гайдам. Так как это признак проблем в предыдущих шагах онбординга
В общем, мы говорим об одном и том же. Просто, наверное, Фил и Егор не ставят реджект, а просто код ревью типа подвисает в воздухе, пока чел не зарезолвит все комменты.
Мы про очень разные процессы говорим, на самом деле ) Так как цель code-review в онбординге для меня - это улучшение процесса онбординга и определение причин нарушений гайд-лайнов без обсуждения. Так как обучение "писать по гайдлайнам" проходит до этого.