LINQ или foreach?

Добрый день, коллеги по цеху!

Пишу высоконагруженные сервисы как для корпоративного сектора, так и для массового потребителя.
Стек технологий: от чистого Python-Perl-PHP до .NET и Java, не считая всяких 1С, SAP и прочего узкоспециализированного ПО.

В последнее время стал задавать себе вопрос: а не далеко ли мы, программисты, зашли в вопросе облегчения себе труда?
Я, как поклонник Entity Framework, Doctrine (и не только, вообще ORM), jQuery (XQuery и им подобные), в разумных, конечно, пределах, не могу избавиться от мысли, что облегчая себе работу (шаблонизаторы, фреймворки с генерацией кода, различные хелперы всех мастей) мы нагружаем сервера, которые и без того дороговато стоят (я даже не про стоимость железа, сколько про облачную инфраструктуру AWS, Azure, Google, DigitalOcean, вот Яндекс тут порадовал ценами на Облака на уровне почти как у AWS)?

Абстрагирование от реальности в области программирования в последние лет 10 идет к тому, что скоро бОльшая часть программистов просто забудет про стек, кучу, оптимизацию SQL-запросов, ведь MS, Oracle, Zend и независимые разработчики средств разработки ПО просто идут навстречу не оптимальному коду и закупке серверов в космических масштабах...

Вот, например LINQ или его аналоги в других языках... Скорость отработки запросов на LINQ существенно (в разы) ниже, чем прямой перебор коллекций, однако мы, разработчики, внедряем всякие умные Parallel LINQ или начинаем заниматься разделением потоков вместо того, чтобы не писать LINQ-запрос, а просто перебрать коллекцию...
Тоже самое относится в некотором роде и к jQuery - можно ведь написать все на чистом JS, применяя jQuery там где это нужно.
Мне всегда казалось, что использование технологии ради удобства чтения кода - это абсурд, посмотреть мои коды на Delphi 5-6-7 15-летней давности, так там все понятно и читаемо, код поддерживается, тесты проходят, однако там даже ORM-подхода нет, вообще половина на stored proc сделана, половина на прямом SQL, а уж про перебор коллекций в Object Pascal тех лет вообще молчу)

Рискуя на себя навлечь тонны ненависти и лучи коричневой радуги, все таки сделаю вывод, исходя исключительно из своей практики: неужели принцип “лучше день потерять, потом за 5 минут долететь” не работает в нашей отрасли? В большинстве случаев в моей практике, когда я получал какой-то код на доработку или участвовал в конкурсе на получение контракта мои конкуренты выдавали такие астрономические суммы по закупке серверных мощностей, что я их “уделывал” только на стоимости серверов: мои расчеты по серверам оказывались в 2-3-5 иногда в 10 раз меньше, чем расчеты конкурентов именно из-за архаичности моих подходов к экономии на стороне исходного кода и созданию баланса в решении, чтобы прежде всего экономить средства заказчика как сейчас так и на стадии поддержки проекта.
Кстати, если кто скажет про то что код на LINQ и прочих “упростителях жизни” проще тестировать, то тут возможно соглашусь, но ведь и тесты пишут программисты, пусть и называющиеся тестировщиками...

Программист, как мне кажется, это прежде всего инженер, а инженерный подход предусматривает создание оптимального, с точки зрения экономики, решения.

Это не значит, что я противник прогресса, но “лучшее - враг хорошего” тоже надо учитывать и не бросаться на все новомодные фишки, особенно если их навязывает производитель серверных мощностей (например MS со своим LINQ)

Так что, будем продолжать идти на поводу у гиков MS и Google, создающих фреймворки и прочие “удобные” решения для быстрой разработки или все-таки научимся сами “держать баланс”?

Кстати, для любителей вывести все в абсолют, скажу сразу: я не считаю, что раз я такой умный, то писать надо все на C и ASM, а лучше на перфокартах, чего уж там…
Еще раз подчеркиваю, инженерный подход! Экономим средства заказчика.

Am I wrong?
  • Вопрос задан
  • 2718 просмотров
Пригласить эксперта
Ответы на вопрос 10
@EvgeniiR
https://github.com/EvgeniiR
1. Такая ситуация складывается от того что бизнесу обычно нужно чтобы было готово ещё вчера, и плевать ему какие костыли при этом будут в коде, в худшем случае он не подумает даже о сложности поддержки всего этого.

2.
Программист, как мне кажется, это прежде всего инженер, а инженерный подход предусматривает создание оптимального, с точки зрения экономики, решения.

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

https://habr.com/company/badoo/blog/430722/ - хорошая статья от badoo, с выводами на счёт целесообразности оптимизировать код / добавлять сервера
Ответ написан
Комментировать
Stalker_RED
@Stalker_RED
в последние лет 10 идет к тому, что скоро бОльшая часть программистов просто забудет про стек, кучу, оптимизацию SQL-запросов
бОльшая часть программистов никогда и не умела в оптимизацию SQL-запросов.

“лучше день потерять, потом за 5 минут долететь” не работает в нашей отрасли?
Бизнес смотрит где выгода. Если он без этой схемы тратит два дня, то да, лучше потерять и долететь. Если он без этой схемы тратил 10 минут, и летал раз в месяц, то пятиминутная экономия окупится через 288 "полетов" (через 24 года). Оно ему точно надо?

80 лет назад практический каждый водитель умел в автомеханику. А сейчас за рулем все чаще можно встретить людей, которые не могут бачок омывайки от масла отличить, например.

Это не значит, что никому в мире не нужен хайлоад и хороший код. Просто массовому рынку это не всегда выгодно, это норма.
Ответ написан
Комментировать
sim3x
@sim3x
Что с точки зрения економики лучше:
- искать 12мес команду из талантливых программеров, которые за год могут не_написать проект
- найти команду из средних и плохих разрабов и на фреймворках наклепать решение за 6 мес
?

Про стоимость железа / быстродействие.
Если ваш набор тулз не дает огромного прироста в скорости разработки, или набор сам не оптимизирует код, или набор не заставляет писать оптимальный код, то вам стоит его сменить
И название набора не имеет никакого значения
Ответ написан
Комментировать
profesor08
@profesor08
Если что-то позволяет больше зарабатывать, то почему бы и нет?
Ответ написан
Комментировать
gadfi
@gadfi
https://gamega.org
не вижу проблемы, нагруженые системы так часто и пишут, а просое приложение которое должно решать конкретную задачу .. дешевле сервер рядом воткнуть
вот когда цена за сервера становится сильно дороже цены за разработку тогда и начинают оптимизировать
Ответ написан
Комментировать
@Free_ze
Пишу комментарии в комментарии, а не в ответы
Скорость отработки запросов на LINQ существенно (в разы) ниже, чем прямой перебор коллекций, однако мы, разработчики, внедряем всякие умные Parallel LINQ или начинаем заниматься разделением потоков вместо того, чтобы не писать LINQ-запрос, а просто перебрать коллекцию

Почему же? Если какое-то решение выгоднее, то его мы и используем. Параллельная обработка запросов нужна там, где нужно именно это, а не "пофиг как, но хочу быстрый LINQ". Такая логика может означать лишь низкую очень низкую квалификацию индивидума.

однако там даже ORM-подхода нет

Не от лучшей жизни же. Да и сейчас, если дотнет брать, достаточно популярен тот же Dapper. Что так же не мешает совмещать EF с Dapper в одном приложении. Возможно, вам не попадались задачи, где игра стоила бы свеч.

код на LINQ и прочих “упростителях жизни” проще тестировать

Напротив, функциональные цепочки вызовов в отладке сложнее императивного кода.

ЗЫ Разработчику нужно обязательно:
  1. знать, как работают его "улучшайзеры" на уровне имплементации, чтобы прогнозировать сложность алгоритмов;
  2. оценивать требования по производительности для отдельных участков ПО;
  3. грамотно проектировать архитектуру, позволяющую проводить рефакторинг в изоляции;
  4. НЕ заниматься микрооптимизациями и НЕ писать велосипеды без нужды.


Озвученный вопрос - сугубо технический. А все эти: "Воткнуть еще один сервер, они ж дешевые!" - означает факап бизнеса, который изначально сэкономил на компетентных специалистах, а теперь вынужден деньгами затыкать дыры из-за неверных технических решений. Такие конторы стоит обходить стороной, а поддерживающих идею коллег - гнать тряпками и насмехаться.
Ответ написан
Комментировать
tema_sun
@tema_sun
мы нагружаем сервера, которые и без того дороговато стоят


Время разработчика в бесконечность раз дороже и важнее, чем оплата нескольких лишних долларов за серевер.
Ответ написан
@ponaehal
Естественный процесс, увы, никуда от этого не денешься....
Так не только в программировании, так во всем. Вам же не нужно знать весь курс физики и электротехники что бы вкрутить лампочку... Вам не надо знать как работает карбюратор/инжектор чтобы ездить на машине...
И опять же даже среди электриков есть те кто способен посчитать нагрузку на сеть, что-то там еще (ничего в этом не понимаю), а есть те которые могут провода в стенку "заштробить" и розетки с автоматами поставить. Но если бы таких не было, то вызов электрика "с образованием" обходился бы нам в круглую копейку.
Экономика блин.... ненавистное слово для перфекциониста :)
Не переживайте так! Удачи!
Ответ написан
Комментировать
@oldhowl
Ну как бы и linq ef тоже надо с умом юзать.
https://habr.com/post/269901/
Ответ написан
Комментировать
мы нагружаем сервера, которые и без того дороговато стоят

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы