Мои любимые антипаттерны

За прошедшие годы работы над самыми разными проектами, в разных компаниях, с разными специалистами я перестал верить в то, что где-то существует та самая компания, в которой налажены процессы, кодовая база на высоком уровне, начальство хорошее и так далее. Я хочу поговорить про кодовую базу. На мой взгляд, на сегодняшний день она не может быть на высоком уровне по определению. Нет, отдельно взятые проекты, которые поддерживает узкий круг специалистов высокой квалификации, могут иметь высокую культуру кода. Но про высокий средний уровень говорить вряд ли можно. А причину я уже называл – низкий уровень подготовки специалистов. И высокому уровню сегодня взяться неоткуда – в разработчики идут после самостоятельной подготовки, а дальше - куда кривая выведет. При этом если человек внезапно окажется очень талантливым – велик шанс что уедет за рубеж, а мы останемся с теми, кто остался. К чему это всё? Я попробую описать анти-паттерны, на которые натыкаюсь чаще всего, и которые вызывают наибольшую боль пониже спины. И оговорюсь сразу – мне все равно, если данный список уже где-то публиковался, и данные паттерны называются иначе. Если это так – закиньте ссылку в комментарии, с радостью ознакомлюсь. Я пишу, чтобы выговориться. Да и вдруг найдется пара человек, которые увидят эти примеры впервые.

1. «Платные функции». А именно – создается впечатление, будто за каждую написанную функцию – у программиста вычитают деньги из зарплаты. Нет, речь даже не про копирование одних и тех же блоков кода. Даже если функция достаточно уникальна и описывает сложный бизнес-процесс – на кой дьявол ее писать в 200 строк и более? Прямо совсем-совсем не бьется на более мелкие компоненты? Да, скорее всего есть исключения и такой подход оправдан. Но сколько я не встречал портянок текста – я такого оправдания ни разу не встречал. Можно ли с этим бороться? Метод решения вроде как очевиден – ревью задач. Но тут не все так просто. Во-первых, реализация может затянуться, и руководитель недвусмысленно намекнет выдавать как есть, а потом разберемся. А во-вторых – представьте что вы «просто добавили строчку» или парочку. Разве это криминал? Ведь в противном случае вам вместо пары строк – понадобится проводить рефакторинг. Ревьювер будет смотреть строго на ваши пару строчек, а вот обратит ли внимание что происходит до и после – уже под вопросом. И вот мало по малу рождается Франкенштейн.

2. Мега-методы. Чисто теоретически они даже могут быть достаточно компактными и красиво оформленными. Но они выполняют десятки задач, необходимость каждой из которых под вопросом. Предположим, мы хотим получить некую сущность – например, корзину покупок. Нам нужно получить две вещи – состав заказа и имеющиеся данные о получателе. Вроде всё? Нееет. Представьте что попутно еще отправляется запрос в Почту России для бронирования трек-номера, в налоговую для загрузки какой-нибудь информации о получателе. А еще пробные запросы в онлайн-банки, поддерживающие выставление счета. Это не реальные примеры, видимые мною, но суть та же. Обработчик запроса начинает заниматься вещами, которые вроде как полезны и может быть даже нужны конечному пользователю, но вычислительные ресурсы тратятся сейчас, время запроса растет тоже сейчас, а будет ли использован результат этих телодвижений – под вопросом. Нет, я понимаю, что современное серверное оборудование очень мощное и подобные задачи может выполнять довольно быстро. Но не быстрее нуля. А как это всё заработает под серьезной нагрузкой – предсказать трудно.

3. Мега-интерфейсы. Вообще этот пункт без первых двух наверное существовать не может. Или даже является причиной их существования. Суть – у нас есть методы, которые согласно собственному интерфейсу, принимают штук 6 входных параметров. Нет, это не подобие стандартных библиотечных методов, которые за счет перегрузки имеют более компактные интерфейсы вызова. Это методы, для вызова которых нужно передать строго все входные параметры. Причем почему-то вместо одной сложной модели – передается 5 простых переменных. Или помимо модели – передается еще горсть каких-то параметров, назначение которых явно корректирует порядок выполнения метода. Моим личным идеалом интерфейса метода бизнес-логики является 2 входных параметра – модель запроса и модель контекста текущего пользователя. Однако встречаю передачи флагов из цикла «что-то проверять или нет». Флаги из настроек приложения, вплоть до определения типа приложения. И еще много какие сюрпризы.

Когда подобные вещи пишет стажер или просто новичок – проблемы нет, все такими были. Человек учится и на этапе code-review эта чушь должна быть отправлена на переработку. Однако этого не происходит и из этого я неявно делаю вывод, что люди, находящиеся на должности middle-программистов проблемы не видят. И возможно даже сами пишут подобное. А это уровень базового учебника. Видимо уровень обучения специалистов как раз застрял где-то на уровне этого учебника