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 ★★★★★
()

Имел неосторожность написать свой сайт https://webhamster.ru на CodeIgniter v.2, потому что для него был сделан прекрасный перевод документации на русский язык.

Но CodeIgniter перестал развиваться, а перетягивать проект на Yii или Laravel у меня времени не было.

Поэтому до сих пор на хостинге ставлю порты PHP 5.x чтобы вся эта древность работала.

И я даже не знаю, хорошо ли что я воспользовался сторонним решением. Может быть, если б писал все сам, я сейчас хотя бы дотянул код до PHP 8.x, и не парился со старыми операционками и портами.

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

Если ты пилил велосипед несколько лет, а переписал его за 1 вечер, то цена твой работы и есть этот самый вечер.

Неправильное умозаключение. Перед тем как переписать проект за вечер надо несколько лет пилить велосипед. Именно поэтому специалистам платят за то, что они знают куда ударить молотком один раз.

https://anekdotov.net/anekdot/all/nvplttgnrrplnst.htm

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

специалистам платят

они знают куда ударить молотком один раз

У вас сразу два когнитивного искажения. Первое - объединение этих фактов в один. Второе - представление что любой велосипед может быть заменен кратно меньшим числом кода да еще и с обратной совместимостью. Я же о частном случае, когда навыки настолько низкие, что обрастание велосипеда лапшой тянет максимум на пет-проект или курсовую работу, в этом случае навыки многолетнего говнокодинга не превратятся за один вечер в стронг синьор скиллз.

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

навыки многолетнего говнокодинга не превратятся

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

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

Если человек работает в нормальном режиме

то ему никакой велосипед мешать не будет.

человек способен из джуна перепрыгнуть

А что объем кода\фич уже грейдом стал измеряться? К тому же вы это, либо крестик снимите, либо трусы наденьте. В точке входа могут быть два варианта. Первый - велосипед настолько жалок, что его можно переписать за вечер. Но не силами того же человека, который такое убожество писал. Второй - велосипед настолько оброс фичами и легаси, что его за вечер не перепишет никто.

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