Серьезно. Кода на который можно посмотреть и сказать "это сделано на отлично" почти не бывает – в основном один фарш из легаси, гвоздей, и иероглифов.
Это не пессимизм. Откройте почти любой коммерческий проект, где люди решают задачи, живут с тем что есть, проект уже прожил сравнительно долгую жизнь, а команда меняется (и это нормально).
Тема пойдет про причину, почему оно происходит, и почему не надо создавать себе иллюзий хорошего кода.
Не ходя вокруг и около – всё дело в экспертизе. Берем 20 разработчиков на проект, из них все минимум миддлы и сениоры, может быть пара джунов, и получаем тот самый фарш.
Я скажу со своей кухни, разработки фронта. Всё дело в том, что сейчас миддл, или даже сениор – это человек который знает как собирать компоненты, использовать некоторые библиотеки, но дальше стандартных инструкций 95% разработчиков не смотрят.
Задайте хотя бы эти общие вопросы разработчикам:
Почему ты выбрал эту архитектуру решения?
Какие есть другие варианты решения этой задачи?
Почему ты решил что ты написал хороший код?
Как ты определил нужный уровень абстракции сущностей в решении?
Можно конкретизировать:
Как ты решил проблему тесной связи между сущностями?
Можно ли будет развить твое решение без рефакторинга?
Почему здесь необходим цикл?
Почему время выполнения этого цикла не будет проблемой при росте количества входных данных?
Исходя из каких принципов ты проектировал эту HTML-разметку?
Поэтому в среднем получается картина – разработчик написал код, и там есть ошибки кодирования, ошибки проектирования.
Что дальше? – Ревью! Кто же как ни лид и/или команда должны выгрести технические ошибки?
Вариантов несколько.
Если людей много, то лид зашивается. Точка. Он физически не может пропустить через себя весь поток кода от 20+ человек. Если он решит что супергерой и сможет это сделать – флаг ему в руки, но он всё-равно пропустит ошибки и не сможет нормально делать ревью, потому что физически на нормальное ревью ему времени не хватит. Это мое мнение. Допустим, прилетит ему ~15-25 PR каждый день, и надо проверить это за 6 часов, да еще откомментить, да еще и архиктектуру проверить, да еще и созвониться, да еще и донести мысль и идею, а потом еще и повторное ревью сделать, и потом еще может быть по новой понесется. И это мы только минимум перечислили. Да вперед, все мы герои. Но это нереально.
Если лидов много (большая команда дробится на небольшие), то надо иметь хороших лидов для каждой из таких команд, но на практике так не бывает. Если вы побывали в такой компании – вы счастливчик.
Если ревью делается просто командой, то люди которые делают косяки, за другими и проверяют, т.е. в среднем уровень решения на выходе сильно не выйдет за это среднее значение экспертизы по команде. Собери 100 джунов, заставь вместе кодить, и они тебе всё-равно супер-код не напишут.
Поэтому как ни крути, на большом проекте качество не может быть выше чем средняя экспертиза в команде (за редкими исключениями). Не может.
Хотите дальше? – пожалуйста, давайте поднимем градус, и добавим легаси
Да, в проекте рано или поздно появится легаси. Сделали мы машину, а потом оказалось что нужны гусеницы. Оп, а так нельзя, не поддерживается. Значит надо менять архитектуру решения, чтобы трансмиссия была модульной, и можно было ставить разные типы трансмиссии.
Так вот, берем мидлов, они пишут рабочее решение без хорошей архитектуры, получаем новые требования, и вуаля, надо выкинуть код и переделать.
Посмотрите на свою команду, и задумайтесь:
Кто реально закладывает время на серьезное изменение архитектуры?
Кто у вас в команде действительно изменяет существующую архитектуру приложения?
У вас были случаи когда PR посмотрели, сказали что это мержить нельзя, и вообще чувак переделывай, там жесть, мы с этим через полгода офигеем?
В среднем ответ – мало кто так делает. В лучшем случае лиды, а если ревью идет всей командой, так почти не бывает. Хотя бы потому что человек работал неделю, и многие просто не могут сказать что ему надо всё это выкинуть и переделать.
Я не противник чужого кода, я часто одобряю PR других не одобряя решения, но понимания что это альтернативное решение и выбранная архитектура тоже имеет право на жизнь, серьезных последствий это не принесет. Но часто бывают и обратные случаи.
Вот команда всё это дружно смержила, и.. привет бардак в кодовой базе – пролезли архитектурные косяки, ошибки кодирования, очередное легаси. Оно бы и ладно, но дальше с таким подходом проблемы будут только нарастать как снежный кодм. Если повезет, будут проблемы только с производительностью. Если нет, то разработка может колом встать, и тогда лидов возьмут за одно место на букву "я", и спросят какого хобота у нас такие проблемы.
Знаете что будет дальше? – либо проект успеет зарелизиться и дальше его не надо развивать (ага, конечно), либо надо это исправить, потому что дальше так нельзя
Угадаете кто это будет делать?
Эти же люди, которые написали это, и начнут исправлять эти проблемы! Это не может работать по-определению (инженеры ВАЗ перестроят завод ВАЗ и качество станет как у иномарок, ага), но так делают почти все!
И вот мы получаем стабильное падение качества продукта.
Хотите еще поднять градус? – а давайте добавим обязательства
Вот есть разработчик, а ему сказали что сделать задачу за 1 месяц. Всё, без вариантов, и никакие его аргументы не помогут сдвинуть дедлайн. Мы не говорим про проблемы управления, но когда разработчика ставят перед фактом, и он не может влезть в рамки, ему приходится срезать критически важные вещи – тесты, рефакторинг, изменение архитектуры, хотя всё это является частью разработки, но часто воспринимается как отдельные задачи.
Это самый настоящий конвейр стальных гвоздей для нашей кодовой базы.
Итого имеем – выше средней экспертизы команды качество кодовой базы вырасти не может, а вот под воздействием факторов ползти вниз, это запросто.
Поэтому три истины:
Хотите изменить качество проекта к лучшему – качественно меняйте людей, чтобы поднять средний уровень качества решений на выходе.
Хотите нормальное качество – не бойтесь людей и команды, бейтесь за качество. Правильные решения всё-равно всплывут, и лучше сейчас, даже если начальство или команда будут недовольны, чем на потопленном корабле потом.
Идеального или даже хорошего коммерческого кода в больших командах не существует, или почти не существует
Конечно, все это личный опыт. Если у вас другой опыт, это очень круто, и вам повезло работать с очень крутыми ребятами. Отпишитесь в комментах, интересно как построены ваши процессы, если у вас нет таких проблем. Мистика на ночь, это интересно.
