Хороший программист или архитектор всегда знает – идеальных решений нет. За любое решение мы платим какими-то ресурсами. Любая оптимизация, как правило, повышает шанс возникновения новых багов (просто за счет изменений кода, даже если ваш код «идеален и оттестирован» – есть мизерный шанс на баг в используемой библиотеке). Меня учили, что даже исправление багов это внесение новых, но просто более трудно уловимых.
К чему я это все говорю? Идеальных решений нет совершенно точно, хорошие решения бывают, но это порой набор компромиссов. А вот плохие решения есть. А еще они были и будут, и вот о них как раз и хочется призадуматься.
Размышлять буду над проектом, над которым работаю сам в составе нескольких групп. Буду говорить о тех решениях, которые вызывают мою личную боль. Боль возникает при использовании данных решений либо при попытке их додумать или развить.
Проблема №1 – методы единственного назначения. Меня тут можно сразу попрекнуть, дескать везде учат что метод должен решать одну единственную задачу. Один класс должен решать только какую-то одну задачу и т.д. А я с этим и не спорю. Вот предположим у нас есть 1 метод для получения списка сущностей для вкладки №1, а вот второй метод для получения списка тех же самых сущностей для вкладки №2. У этих методов 1 единственная задача. Кто-то может с этим поспорить? Просто эта задача настолько частная, что переиспользовать этот же метод в другом сценарии не всегда представляется возможным. Предположим мы захотим взять этот метод и вызвав его добавить вызов еще какого-нибудь метода дополнив набор данных для вашей задачи. И тут бац, и оказывается что для своей работы он делает 3 запроса данных, которые вам не нужны. Как быть? В нашей «практике» старшие и ведущие разработчики рассказывают, что скопировать код и «доработать» это методика, а потом в личной беседе «жалуются» что им не пригодились знания Объектно-ориентированного программирования. Да, это «методика». Методика фрилансера – нагадил в проект, забрал деньги и свалил. А в долгом проекте рано или поздно чуть-чуть меняется какой-то архитектурный нюанс и ты, как Геракл в авгиевых конюшнях, лазишь по проекту ради копеечного изменения. А потом приходит задача сделать вкладку №3 где нужен этот же список и ты сидишь думаешь – толи переписывать всё это, толи «сделать нормально». И вот у вас уже 3 метода про одно и тоже без объяснений что как работает и когда должно использоваться.
Проблема №2 – Простые входные параметры. Точнее безумное добавление входных параметров простых типов. Может быть даже со значениями по умолчанию или еще как-то. Лично я сторонник методологии при которой методы бизнес-логики на вход принимают 1 параметр Request и возвращает 1 объект Response(сразу скажу, список – это не 1 объект, это список). Данный подход позволяет беспроблемно расширять метод новыми входными параметрами(бывает полезно когда раньше вы сортировали всегда по одному полю, а теперь пришла задача с выбором направления и поля сортировки) просто за счет расширения полей объекта Request или расширять объем возвращаемых данных. Бонусом идет факт того что такой интерфейс совершенно элементарно мокируется при использовании его в unit-тестах. Но так делают не все. Если придя в новую компанию обнаружите интерфейс с 8 входными параметрами строкового и булева типа, припорошенных цифровыми, бегите сломя голову. Авторы данного произведения – скорее всего дегенераты или мазохисты, не написавшие в жизни ни одного теста. Меня снова тут можно попрекнуть, дескать стандартная библиотека .NET переполнена страшными интерфейсами в 8 сложных входных параметров. Только когда соберетесь так делать, уточните - кто и когда их так вызывает. Окажется что с использованием перегрузки методов – находится 1 простой интерфейс вызова, а если уж вам понадобится более изощренный вариант – то вот тогда добро пожаловать. Или вам всегда нужен самый изощренный? Тогда простите, что брюзжу и трачу ваше время.
Проблема №3 – результат резонанса первых двух. Это как раз мой случай. А именно – помойка.
Дело в том, что когда вы постоянно добавляете новые методы без переиспользования – проект поразительно быстро обрастает кодом, который никто не использует. Одна масштабная оптимизация и сразу целый набор методов становится кандидатом на удаление из проекта. Но видимо для получения высоких зарплат, нужно оправдываться большим проектом, а чтобы проект был большим – нужно много кода и удалять его, при таких раскладах, преступление. И вот ты сидишь и второй час выкачиваешь рабочую ветку, думая, что у тебя проблемы с сетью, но потом замечаешь, что ветка весит 20Гб и картина мира снова складывается. Такой объем одним кодом получить нельзя? Согласен полностью. Но дело в том что «поросята» не аккуратны везде. Скорее всего, проект захламлен копированием каких-то левых ресурсов, сборок и всего на свете. И никому не нужно это удалять, так как мы живем по Agile с недельными спринтами, и перед нами стоят важные для клиента фичи.
Подведем итог? Хотите работать на проекте с красивым кодом? Пишите его сами. Хотите работать в чистом проекте? Удаляйте обнаруженный мусор сами. Не надо ждать волшебных задач на оптимизацию – решайте их в рамках своих текущих. Ни одному руководителю или директору не нужен чистый удобный и красивый проект, им нужен функционал, выданный клиенту. В лучшем случае чистота и удобства будет способствовать более быстрой разработке этого функционала, но если вы будете выдавать функционал в устраивающем руководство темпе – им будет плевать что вы работаете на помойке. Это ваше рабочее место и только вам нужно чтобы оно было удобным.