Как вы уже знаете, StepOne работал в многих крупных компаниях и что-то знает про культуру программирования в такой среде
В каком-то смысле этот пост логически развивает мысль о том, что правки на ревью будут всегда
И скорее дальше расскажу, как эти правки минимизировать
Как уже было сказано, для успеха работы в команде надо минимизировать эго и индивидуальность
Никого не волнует как хорошо вы можете внедрить SOLID, и какую лаконичную иерархию наследования построите
Даже больше скажу, это скорее будет проблемой, чем пользой
Есть две ключевые вещи, на которые работает код-ревью:
1. читаемость
2. поддерживаемость
Надо понять, как привыкли писать код в конкретной команде, конкретной компании и писать также
Смысл бизнеса - сделать разработчика заменимым, так что попытка сопротивления станет минусом на перформанс ревью
Кадровички бьют тревогу о том, что средняя продолжительность работы год, но не понимают, что архитектура отрасли нацелена на такие паттерны