LINUX.ORG.RU
ФорумTalks

Самый вредный и опасный подход в программировании

 ,


0

3

По мотивам: Поделитесь мнением про оптимизации и подходы, которые вам никогда не пригодились или оказались ложными/вредными

Отказ от ORM приводит к двум возможным сценариям:

  1. Написанию своего ORM. Только он будет кривой, косой, глючный и не безопасный.
  2. Написанию лапши, как в 99.9% PHP бэка времён нулевых (хотя и сейчас ситуация не сильно изменилась).

Оба сценария требуют дополнительного времени на разработку и отладку, а код становится не поддерживаемым другими разработчиками. Со временем проект превращается в тыкву, потому что его в принципе нельзя никак изменить — при любой правке он весь рассыпается.

Есть 1% случаев, когда отказ от ORM оправдан, а обвязку пишет гуру. По ссылке как раз такое исключение (имеется в виду ссылка на холивар из оригинальной темы). В таком случае возникает ещё один сценарий:

  1. Бизнес-логика переезжает из кода проекта в код на SQL. Без скиллового гуру такой код быстро становится кривым, косым и не безопасным говнокодом.

Ситуация подобна возбуханиям сишников против Rust — каждый раз они визжат, что нужно просто лучше писать код. И каждый раз происходит обсёр, потому что реальный мир не подчиняется правилам должного, обитающим лишь в головах фанатиков. В реальном мире люди постоянно совершают ошибки, поэтому чем сильнее они ограничены инструментарием — тем лучше.

В большинстве случаев ORM удобен, быстр для разработки и безопасен, а дебажить SQL запросы никогда не понадобится, потому что там простой CRUD.

Крупные проекты содержат говнокод. ORM, фреймворки, библиотеки — они им напичканы. Профаны, видя такое, кидаются писать своё решение. Но они не знают, что за каждым хаком стоит необходимость, продиктованная особенностями и ограничениями, выясняющимися лишь в процессе разработки. В итоге своё «правильное» решение превращается в ещё более худший говнокод. Только вот за инструментами стоит команда, тестировщики, сообщество — которое пишет баг-репорты, кидает PR. А за своим решением стоит 1 разработчик. Поэтому своё решение всегда оказывается хуже готового.

А теперь самый сок:

  • Своё решение приводит к выгоранию. Такие проекты всегда доставались мне с формулировкой: «предыдущий разработчик ушёл в депрессию». Потому что вместо работы над проектом появляется ещё работа над своими «правильными» фреймворками и библиотеками, никому больше не нужными.
  • Это «правильное» решение, занявшее месяцы страданий и бессонных ночей, а на деле приносящие одни лишь проблемы проекту, сносится и переписывается на готовые за 1 вечер. Проект одним махом вылезает из всех багов, лагов и ограничений.

Писать своё решение вместо использования готового, когда это не оправдано технической необходимостью — самый вредный подход из всех, заканчивающийся психическими заболеваниями.

P.S. Помнится, на ЛОРе был некто с псевдонимом царь. Был против всех CMS, скриптовых языков, фрейморков и ORM-ов. Несколько лет писал свой движок на сях, а за неимением хоть чего-то рабочего, вёл блог в blogspot. У меня не осталось ссылки. Кто в курсе — написал ли он своё поделие, или же «разработчик ушёл в депрессию»?

P.P.S. Другой, более известный велосипедист, допускает примитивный XSS в самописной CMS. Лучше читать оригинальную новость, она более содержательна. И всё это во имя отказа от СУБД, ведь когда на сервере заканчивается дисковое пространство, файлы могут повредиться (такой аргумент звучал в интервью Бороде)!

P.P.P.S. Меня тоже не обошло стороной, ведь я свои парсеры и прочую херомуть писал. Хорошо, что вовремя остановился.

★★★★★

С ORM такая заковыка, что по уму под неё нужно проектировать схему. А обычно бывает всё наоборот: имеется забористая схема, сделанная при царе горохе, и нужно как-то натянуть пиджак на этого осьминога. И тут от ORM больше гемора, чем пользы. Может я неосилятор, но никогда не было гладко с ними, постоянно мучительная борьба с протекающими абстракциями. Чтобы оно само генерило более-менее оптимальные запросы и не теребило базу как истеричка, это нужно превозмогать. Пока будешь оптимизировать, пхпшник на коленке вдвое быстрее напишет более эффективную лапшу.

bread
()
Ответ на: комментарий от bread

Вообще, если стартовать с нуля, я т.п., трансляция сущности БД в ООП (это же ORM, я правильно понимаю?), может быть нормальным инструментом. А может быть и нет. Жизнь же сложная штука, от задачи зависит.

tiinn ★★★★★
()
Ответ на: комментарий от tiinn

Думаю, что нормально это когда первична объектная модель, а схема БД уже от неё пляшет. То есть трансляция из O в R, а не наоборот. Но так никто не делает же. Все натягивают реляционную модель на объекты, получается так себе.

bread
()
Ответ на: комментарий от tiinn

Может я один такой рукожоп, но при теневом удалении сущностей постоянно огребаю на нюансах кеширования. Ну это присказка, мякотка в том что лишний слой ORM жутко мешает дебажить. И чем дальше от помидорно-архитектурного клуба, тем больше лулзов можно словить.

Lordwind ★★★★★
()
Ответ на: комментарий от bread

Думаю, что нормально это когда первична объектная модель,

Пожалуй.

tiinn ★★★★★
()
Ответ на: комментарий от Lordwind

Ну это присказка, мякотка в том что лишний слой ORM жутко мешает дебажить.

Вроде же, помогать должно. Т.е. вы в любой момент можете посмотреть состояние любого объекта по базе.

tiinn ★★★★★
()
Ответ на: комментарий от tiinn

А слой между кодом и базой? А в условии многопоточности? Там нюансов дохера. Так что я хоть и пользуюсь, но понимаю почему и когда этот геморрой не нужен.

ЗЫ. Эти нюансы надо постоянно держать в голове, при том что SQL и так все знают (ну или должны). Я вот только год назад узнал что в хибере селективность IN ограничена 200, да еще и работает с нормальной скоростью только по степени 2.

Lordwind ★★★★★
()
Последнее исправление: Lordwind (всего исправлений: 1)
Ответ на: комментарий от Lordwind

А слой между кодом и базой?

Так, этот слой не программистом делается. Во всяком случае, ещё в Visual Studio 2010 эта прослойка автоматом генерировалась.

Многопоточка - да, там могут быть нюансы.

tiinn ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)