Не душните на Code review Боль, с которой я сталкиваюсь буквально на каждом месте работы - люди тратят свое и чужое время на споры о том, как "читаемее/лаконичнее/красивее" с их точки зрения написать какой-то совершенно неважный блок кода. Особенно фрустрирует, когда чтобы удовлетворить чувство прекрасного очередного ревьюера, нужно перелопатить уже готовый и оттестированный на основных сценариях код - с неизвестными последствиями в дальнейшем 🫠 Можно возразить - но это же наша работа, код ревью позволяет избежать ошибок и прочее. Попробуйте сами себе честно ответить на вопрос - насколько чаще вы правите очередной неверный отступ (который вообще-то фиксится через настройку линтера и код ревью не требует вовсе) или спорите о нейминге переменной, чем вносите неочевидный и действительно важный фикс, который бы позволял избежать багов? Как правило - если в проекте есть уже устоявшаяся архитектура и разработчики пишут промышленный стандартизированный код, а не занимаются творчеством (что я особенно осуждаю, кстати), то такие фиксы - единичный кейс. А если нет, тогда у меня плохие новости - ваша архитектура отвратительна и требует рефакторинга, так как у вас слишком много неочевидных вариантов отстрелить себе конечности. Но таких очевидно проблемных проектов на рынке - меньшая часть. Давайте все дружно признаемся, что последние 3-5 проектов, на которых вам довелось работать, были написаны по Clean-у, имели разделение на Presentation, Data и Domain (в рамках отдельных фича-модулей или глобально), на Presentation слое была вариация MVVM/MVI с использованием коктейля из Flow/Corountines/RxJava/LiveData, а ваши Usecases по большей части проксировали получение данных из репозиториев. И что никакого rocket science в этом нет. И вы наверняка согласитесь, что большая часть багов возникает именно во взаимодействии всех элементов этой связки между собой - будь то неверные стейты на UI, ошибки с многопоточкой или сломанный маппинг моделей при передаче между слоями. И мой главный вопрос - как при код ревью разработчик вникнет в бизнес-логику твоей задачи так, что сможет указать на возможные ошибки? Насколько много времени на это может уйти? А занимается ли кто-то этим вообще или просто ищет, в какой переменной у тебя некрасивый нейминг? 😁 Мое предложение - не спорьте в пулл реквестах, а просто сделайте так, как вам указали - сэкономите кучу времени и нервов, они вам еще пригодятся. Естественно исключая вариант, когда чтобы удовлетворить чьи-то очень специфичные вкусы, вам придется фактически переделывать всю работу. Здесь включайте все свои софт скиллы и настаивайте на дополнительной задаче на рефакторинг с отдельной оценкой (перфекционист не оценит, но ваш менеджер будет доволен, что задача закрыта в срок). И последнее - не становитесь таким же перфекционистом. Бейте себя по рукам, когда в очередной раз хотите упрекнуть кого-то в вызове invoke() или неиспользовании деструктора. Берегите свое и чужое время ⏳ 🦝 • Менторство