Перепутье программиста

by on April 13, 2014


Последние несколько дней неторопливо размышляю о непростых проблемах выбора.
Имею в виду первоначальный выбор архитектурного решения на этапе проектирования – через несколько месяцев разработки неправильный выбор особенно сильно бьет и наказывает.
Самое нехорошее в этой ситуации – непонятно, как быть? Переписывать все заново и терять время? Тащить дальше кривое решение? Пресловутый рефакторинг?



О чем это я?
Был у меня выбор: использовать старый добрый ORM или попробовать обойтись низкоуровневым драйвером mongodb.
В условиях задачи не было никаких особых ограничений: ни по производительности, ни по "гибкости".

Поскольку предыдущие несколько лет я посвятил программированию под rails, где ORM в виде ActiveRecord – практически стандарт, захотелось мне попробовать как же это будет выглядеть работа с низкоуровневым обращением к базе через низкоуровневый драйвер? К тому же mongodb интерфейс – это вам не SQL, который я мало того что плохо знал, так ещё и забыл, в mongodb всё мне нужное достаточно просто и однотипно.

Поначалу всё шло весьма неплохо.
Первую версию проекта сделал, отладил, оттестировал, задеплоил на стейджинг.
Как обычно это водится, пришли улучшения, дополнения, замечания.
И тут полезло.
Захотел кастомную валидацию (ну, сервис, считай открыт для мира, хотя и для внутреннего применения, но – значит надо валидировать входные значения на запись весьма строго). Ну захотел и захотел – добавил новый класс валидатора, описал там правила, написал тесты. И так для каждой модели.
Хотя моделей как таковых не так уж и много, но все равно – либо много похожего кода, отличающегося всего-лишь в малости, либо городить абстрактные классы валидатора, от них наследоваться, перекрывать методы – вот это вот всё. Код становится чертовски связанным, абстракции мешают видеть смысл, через месяц черт пойми, где что и от чего зависимо.
Печаль.
Мало того.
Добавляешь новое поле в модель – приходится лезть и править сразу несколько файлов. Валидатор, саму модель, места, где создаются объекты этой модели и так далее.
В общем – грустно. Хотя, несмотря на вот это всё, я понимаю прекрасно преимущества: решение достаточно гибкое, легковесное и весьма шустрое. Ну и удалось на среднем уровне пощупать как выглядит работа с mongodb: все достаточно просто и логично. Удовлетворил, так сказать, своё любопытство за чужой счет.
С другой стороны у меня же не было никаких особых ограничений по производительности и любая ORM могла бы с легкостью удовлетворить моим скромным запросам. Кода вышло бы гораздо меньше, он выглядел бы как хорошо мне знакомый DSL, особо тестировать ничего не надо было бы.

Резюме таково: 10-15 лет опыта программирования не спасает от неудачных архитектурных решений, по крайней мере в моем случае, что, несомненно печалит.

P.S. Нет, переписывать не буду, но приму к сведению в следующем проекте.


There is 1 comment in this article:

  1. Че грустно, все хорошо же! Зато все просто и понятно как работает, нету активрекордной магии и валидации вынесены отдельно от модели, SRP, все дела.

    ReplyDelete