Почти всю свою карьеру я так или иначе занят в продуктовой разработке. Помимо продуктов я делал собственно демо-проекты и разнообразные прототипы других продуктов.
На старой работе у нас был такой термин "продуктизация". Это когда бралось решение, сделанное кастомного под определенного заказчика, творчески переосмыслялось и впихивалось в продукт. Идея была в том, что эта кастомная функциональность могла бы пригодиться кому-нибудь в будущем. Одной из моих задач, как технического руководителя одного из продуктов, было отбиваться от запросов на такие всякие разные продуктизации. А если уж и брать что-то — то думать, как сделать фичу как можно более универсальной.
Вся эта штука здорово профдеформирует личность. Теперь я не могу просто так взять и закодить что-нибудь жестко под спецификации, даже если понятно что проект одноразовый. Мозг непроизвольно начинает думать как бы сделать решение более гибким, какие сценарии предусмотреть, как бы это все генерализировать так, чтобы потом, когда, может быть, придут за доработкой, то сделать её не из говна и палок а изящно встроить в как раз подготовленное год назад место.
Впрочем, ожидания часто разбиваются о жестокую реальность и оказывается, что предусмотрели далеко не все, и уже в красивую архитектуру нужно добавлять немножко костылей, чтобы новая фича завелась.
С другой стороны, мне кажется, что для инженера это все-таки полезная привычка — продумывать сценарии использования как можно более общими, и строить решение с оглядкой на них. Естественно, везде важен баланс. Когда времени мало, то не до разработки фреймворков, захардкодили, чик чик и в продакшн. Так этот уродец и живет, пока не сменится поколение разработчиков, и новые ребята не сожгут все напалмом, поверху построив как им кажется на этот раз уже хорошее решение. Вот правда ожидает судьба предшественников...
Вот сегодня приехала мне задача увеличить максимальный размер принимаемых определённым API файлов. Раньше ограничения не было, но какие-то ребята додумались слать видео по 50 мегабайт. Сделали ограничение в 10 мегабайт, хардкодом, потому что не было времени (или уже не помню почему). Сегодня оказалось что один из клиентов этого API присылает файлы по 11 мегабайт и здорово было бы лимит увеличить. Можно перехаркодить значение. Можно внести настройку в базу. Но тогда на каждый запрос надо ходить в базу, а это плохо. Значит нужно сверху навернуть кеширование. Хорошо. Но клиентов у API много и разных. Некоторые могут попросить оставить 10 MiB. Делать настройку per-application или per-customer? Если добавлять настройку то нужно добавлять поле в базу для этого клиента. Или записать в json-конфиг его подключения. Но если добавлять в json-конфиг, то нужно добавлять поля в классы(прости Господи) дто, нужно добавлять настройку в админку (которая написана отдельным приложением), добавлять валидацию, устаналивать дефолтное значение, мигрировать существующие конфиги на новые, с добавленным полем, добавлять код чтения настройки уже не из общесистемных настроек, а из конфига подключения...В общем работы на день есть точно.
А начиналось-то все просто, давайте увеличим лимит на 10 мегабайт? Поэтому я перехардкодил существующее значение. Будем проделывать правильную работу в следующий раз, когда потребуется изменение, градуируя улучшения.
Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred