Пишу высоконагруженные сервисы как для корпоративного сектора, так и для массового потребителя.
Стек технологий: от чистого 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, а лучше на перфокартах, чего уж там…
Еще раз подчеркиваю, инженерный подход! Экономим средства заказчика.
Т.к. тема вопроса всё-таки не LINQ, было бы лучше добавить какой-нибудь более общий тег типа "Программирование" или "Проектирование". Довольно мало людей следит за такими узкоспециализированными тегами.
1. Такая ситуация складывается от того что бизнесу обычно нужно чтобы было готово ещё вчера, и плевать ему какие костыли при этом будут в коде, в худшем случае он не подумает даже о сложности поддержки всего этого.
2.
Программист, как мне кажется, это прежде всего инженер, а инженерный подход предусматривает создание оптимального, с точки зрения экономики, решения.
Вы предусматриваете создание оптимального с точки зрения разработки, поддержки и производительности решения. Оптимальным с экономической точки зрения для бизнеса чаще оказывается сделанный из костылей за неделю продукт, чем качественный за месяц.
Все эти "модные" фишки что вы описываете, как раз и существуют для увеличения скорости разработки. Да и деньги то нужны, внезапно, не только на железо.
в последние лет 10 идет к тому, что скоро бОльшая часть программистов просто забудет про стек, кучу, оптимизацию SQL-запросов
бОльшая часть программистов никогда и не умела в оптимизацию SQL-запросов.
“лучше день потерять, потом за 5 минут долететь” не работает в нашей отрасли?
Бизнес смотрит где выгода. Если он без этой схемы тратит два дня, то да, лучше потерять и долететь. Если он без этой схемы тратил 10 минут, и летал раз в месяц, то пятиминутная экономия окупится через 288 "полетов" (через 24 года). Оно ему точно надо?
80 лет назад практический каждый водитель умел в автомеханику. А сейчас за рулем все чаще можно встретить людей, которые не могут бачок омывайки от масла отличить, например.
Это не значит, что никому в мире не нужен хайлоад и хороший код. Просто массовому рынку это не всегда выгодно, это норма.
Что с точки зрения економики лучше:
- искать 12мес команду из талантливых программеров, которые за год могут не_написать проект
- найти команду из средних и плохих разрабов и на фреймворках наклепать решение за 6 мес
?
Про стоимость железа / быстродействие.
Если ваш набор тулз не дает огромного прироста в скорости разработки, или набор сам не оптимизирует код, или набор не заставляет писать оптимальный код, то вам стоит его сменить
И название набора не имеет никакого значения
не вижу проблемы, нагруженые системы так часто и пишут, а просое приложение которое должно решать конкретную задачу .. дешевле сервер рядом воткнуть
вот когда цена за сервера становится сильно дороже цены за разработку тогда и начинают оптимизировать
Скорость отработки запросов на LINQ существенно (в разы) ниже, чем прямой перебор коллекций, однако мы, разработчики, внедряем всякие умные Parallel LINQ или начинаем заниматься разделением потоков вместо того, чтобы не писать LINQ-запрос, а просто перебрать коллекцию
Почему же? Если какое-то решение выгоднее, то его мы и используем. Параллельная обработка запросов нужна там, где нужно именно это, а не "пофиг как, но хочу быстрый LINQ". Такая логика может означать лишь низкую очень низкую квалификацию индивидума.
однако там даже ORM-подхода нет
Не от лучшей жизни же. Да и сейчас, если дотнет брать, достаточно популярен тот же Dapper. Что так же не мешает совмещать EF с Dapper в одном приложении. Возможно, вам не попадались задачи, где игра стоила бы свеч.
код на LINQ и прочих “упростителях жизни” проще тестировать
Напротив, функциональные цепочки вызовов в отладке сложнее императивного кода.
ЗЫ Разработчику нужно обязательно:
знать, как работают его "улучшайзеры" на уровне имплементации, чтобы прогнозировать сложность алгоритмов;
оценивать требования по производительности для отдельных участков ПО;
грамотно проектировать архитектуру, позволяющую проводить рефакторинг в изоляции;
НЕ заниматься микрооптимизациями и НЕ писать велосипеды без нужды.
Озвученный вопрос - сугубо технический. А все эти: "Воткнуть еще один сервер, они ж дешевые!" - означает факап бизнеса, который изначально сэкономил на компетентных специалистах, а теперь вынужден деньгами затыкать дыры из-за неверных технических решений. Такие конторы стоит обходить стороной, а поддерживающих идею коллег - гнать тряпками и насмехаться.
Естественный процесс, увы, никуда от этого не денешься....
Так не только в программировании, так во всем. Вам же не нужно знать весь курс физики и электротехники что бы вкрутить лампочку... Вам не надо знать как работает карбюратор/инжектор чтобы ездить на машине...
И опять же даже среди электриков есть те кто способен посчитать нагрузку на сеть, что-то там еще (ничего в этом не понимаю), а есть те которые могут провода в стенку "заштробить" и розетки с автоматами поставить. Но если бы таких не было, то вызов электрика "с образованием" обходился бы нам в круглую копейку.
Экономика блин.... ненавистное слово для перфекциониста :)
Не переживайте так! Удачи!
мы нагружаем сервера, которые и без того дороговато стоят
Ничего страшного, докупят еще памяти, а через год появится более мощный процессор. Сервера выдюжат, производитель получит прибыль, программисты - больший уровень автоматизации, и все счастливы.
Простой
Средний
