Любой вменяемый программист призывает использовать готовые решения. Будь то решения сторонних разработчиков и компаний или уже реализованные коллегами библиотеки. И я в этом вопросе нисколько не отличаюсь от них. К сожалению это теории из учебников. На практике порой задача кажется, слишком простой для покупки готовых решений или еще по каким-то странным причинам решается велосипедом. Сейчас хочется вспомнить ряд задач, которые преследуют меня из компании в компанию, из проекта в проект и пока понять, как это изменить - я не могу.
Задача №1 – рассылки или информационные уведомления. В основном электронные письма. Не понимаю в чем парадокс, но все проекты, на которых я работал, испытывали неуемное желание реализовать свой метод формирования и отправки писем. Вереница шаблонизаторов от готовых, до кастомных. Различные методы отправки – через очередь отправки, через синхронные обращения к API mail-сервисов. Почему это проблема? Вообще-то библиотек для шаблонизации писем вагон и маленькая тележка. Однако хорошая требует оплаты лицензии, а убедить компанию в том, что опытный программист неспособен сформировать такую простую вещь как email, и надо оплачивать какую-то лицензию – не так просто как кажется. В итоге грабли, костыли и необходимость погружения не только в бизнес-процессы приложения, но и в механику отправки и формирования писем.
Задача №2 – заявки. Вопрос шире, чем кажется, так как под заявками понимается много чего. И заказы и тикеты и еще какие-то непонятные конструкции. В данный момент я поговорю только о статусах заявок. Времена меняются, программисты меняются, шишки набиваются, но почему-то не все знают такое понятие как «Автоматное программирование», «state-машины» и подобное. В итоге разработчики постоянно придумывают нелепые конструкции для бизнес-логики. Вместо методов процессинга заявки в следующий статус – 100500 строк с логикой из серии «потом сделаем лучше» «потом порефакторим».
Задача №3 – таргетинг. Поясню про что говорю – представьте, что вы реализуете механизм генерации баннеров с учетом статистики просмотров и кликов по ним. Дело в том, что данная задача подразумевает работу под нагрузкой и имеет высокие требования по производительности. Здесь обязательно необходимо использовать или чужие решения или чужой опыт. Но однажды я видел реализацию такой задачи методом синхронного обновления бд проекта в SQL-базе update-скриптом. В чем проблема? В ДНК-программиста. Если читатель-программист не понимает что же здесь не так – поясняю. На каждый просмотр баннера на сервере бд создается задача на обновление данных и прикол в том что пока не отработает одна – не запустится следующая. Из-за плевого процесса создается дикая нагрузка на сервер БД.
Какой итог? Молодые специалисты часто слышат фразу - «Забудьте чему вас учили в институтах». Ну, вот похоже что многие так и поступают. Забывают базовые решения, базовые алгоритмы. Достают запас чугуна, ядерные спицы, микроскопы и начинают трудиться. Хочется напомнить что 90% (если не больше) задач, возникающих перед программистом уже кто-то решал. Уже набил шишки и убрал грабли. Какое может быть оправдание пройти по этому пути повторно – я не знаю. Экономия? Ну, так на разработку всех этих велосипедов уходят трудочасы. На поддержку костылей уходят трудочасы. И это не экономия. Это растрата в чистом виде.