Про CRUD-ошлёпство, ticket-оделание и Митрофанушек

Широкое введение в обиход термина CRUD восходит к заре объектно-реляционных проекторов (ORM). Любой проектор - "вещь в себе", даже легковесный. Тяжелые же фреймворки вроде SQL Alchemy или Hibernate, не к ночи будет помянутого, представляют собой многофункциональный продукт, по сложности уже сравнимый с СУБД начального уровня, с поддержкой накопленного за долгие годы тяжелого наследия, требующий знания "магии вуду", обладающий совершенно нестандартным языком и прочими прелестями. Не могу сказать, что Entity Framework чем-то принципиально лучше, ну, да и ладно, речь не о силе издаваемых ими запахов.

CRUD -- это, собственно, четыре базовых операции создания, извлечения, обновления и удаления объекта из базы данных. Любой проектор предоставляет программисту удобные способы манипуляции таким одиночным объектом. Как только манипулировать приходится множеством объектов, коса находит на камень, о чем неоднократно писано-переписано и не только мной. Но за последнее десятилетие расширился класс несложных приложений уровня заполнения экранных формочек и просмотра введенного по простым фильтрам, где большего и не требуется.

У некоторых программистов на этой почве даже возникло неверное представление, что большая часть работы в отрасли -- это CRUD-ошлёпство. В эпоху, когда на тему bullshit jobs пишут целые книги, было бы неверным осуждать их за такой профессиональный пессимизм. Не будем забывать и профессиональные деформации: например, в амплуа технического эксперта по СУБД у меня тоже часто возникало ощущение, что вокруг ~~мухи и говно~~ люди изо всех сил стараются превратить свои базы данных в свалку хаотично набросанной информации, а запросы к ней пишут с минимальным пониманием предмета и языка.

Чтобы коллегам не стало обидно за "несложные приложения", вспомню "лихие 90-е", когда автоматизация была поставлена на широкий поток: зарубежные готовые системы были неподъемны по стоимости, в отрасль влилось множество классных специалистов (те, кто не уехал сразу), а собственные тиражируемые системы еще только зарождались. По стечению перечисленных обстоятельств мне довелось принимать активное участие в процессе зарождения, что вылилось в итоге в интересный опыт создания малотиражных ERP-систем (примеры здесь).

Интересно, что оперативный контур таких систем, будучи реализованным сотни раз различными командами на разных предприятиях, получил пренебрежительное название "опердень", несмотря на сотни выполняемых функций и высокую транзакционную нагрузку. Название пришло из банковского сектора, где автоматизация началась раньше всех. Для обеспечения работы банка контур так и назывался "Операционный день", доброхоты лишь подсократили название.

Так что не обижайтесь за "крудошлепство", потому как автор текста пару-тройку раз "писал опердень".

В середине 1990-х уже было четкое деление на программистов и администраторов инфраструктуры. Администраторы при виде очередной малотиражной "опердени", предлагаемой их предприятию, морщили уставшее от трудов личико, и сквозь зубы цедили, что будь у них побольше времени, то они сами тут наваяли бы такое же за выходные на Delphi.

Похоже на отношение DevOps-ов (техников и инженеров-компоновщиков) к программистам, кстати. И небезосновательно -- массовость труда резко снизила планку качества выкатываемого девопсам ПО.

Но вернемся к теме, к первой части заголовка. Как же все-таки отличить CRUD-приложение от более сложного? Метод, как мне кажется, прост и доступен каждому:

поищите в тексте более-менее длинные запросы к БД на языке вашего проектора, строк так на 20-30;
посмотрите, в какой SQL этот запрос конвертируется (я не употребляю термин "транслируется", потому что SQL, в отличие от ассемблеров или Си, находится, как минимум, не ниже уровня абстракции основного языка вашей программы);
почистите этот SQL-запрос любым инструментом и руками от ненужных частей и автоматически сгенерированных имен;
если итоговый SQL покажется вам проще и понятнее, значит вы вышли за пределы CRUD. Теперь вам придется жить с осознанием того, что ваш код сложнее, чем мог бы быть, и таки надо учить SQL хотя бы на уровне "английского со словарем".

Иногда на практике попадаешь в ситуации, описанные в бессмертном произведении Фонвизина "Недоросль". Митрофанушки от программирования по-прежнему уверены, что "география не нужна, потому что есть извозчики". Поэтому все эти заумные штуки про зависимости, внедрения, интерфейсы, нормализацию базы данных не требуются для "крудошлёпства".

Действительно, для написания "Hello world" не нужны паттерны. Однако использование даже простых техник модульного программирования и многоуровневого API убережет вас от тотального тестирования и удручающих открытий "изменил в одном месте, повалилось в другом", а знание трех нормальных форм и механизмов индексации -- от дублирования данных и просадки производительности при накоплении уже первого гигабайта.

Извините, но про ticket-оделание я напишу в следующий раз. Тема обширнее, чем может показаться, и тесно сопряжена с навязываемой микросервисной архитектурой, аджайлами и коллективной безответственностью.