Лысый дядькаlisttoviewпросто получается что объективных технических причин для того что бы отдать предпочтение какой либо платформе - нет.
меня интересует именно это
вот так элегантно можно выстрелить себе в ногу в любой программе на динамическом языке
1.
2.
3.
4.
5.
6.
7.
8.
9.
buBaIBoba = True
lelikIBolik = 1
if buBaIBoba:
lelikIBoLik = 2
print(lelikIBolik)
какой результат? Правильно, 1. Потому что в четвертой строке я допустил ошибку. Тут надо немедленно начать выть, айяяяй, товарищ, а где же твои юнит-тесты?
Рассказываю, что такое энтерпрайз. Энтерпрайз -
это работа на заказчика, которому глубоко насрать на твои тесты и вообще на то , что происходит с кодом. Его задача - по максимуму выдаивать исполнителя за оплачиваемые ему средства. А задача менеджера - впарить заказчику как можно больше услуг, потому что от этого зависит его материальное благополучие.
Программист получает задачу от менеджера, которую надо было отдать в тестирование еще позавчера , потому что менеджер продал код, которого еще нет в проекте.
При этом техническое задание меняется как облака, а умные мысли по развитию фич и рюшек заказчику приходят внезапно и неожиданно . А еще параллельно с кодом надо решать задачи техподдержки, а еще есть специфичные для конкретного участка внедрения нюансы, которых никто не пр
едусматривал N лет назад, есть текучка кадров и куча легаси . Покрытие тестами в лучшем случае слабое, а обычно никакое. Не потому что программисты козлы, а потому что это труд, как ты выразился "кучи обезьян", мнение которых никто не спрашивает - они лишь инструмент зарабатывания денег. И нафиг здесь никому не впились академики и язык программирования Хаскель, каким бы он ни был замечательным - есть досужие рассуждения о некой абстрактной хорошести, а есть кодинг поставленый на поток. И в этом плане очень хорошо, когда средства программирования включая ЯП минимализируют ошибки рантайма. А еще очень хорошо, когда есть единая платформа, в рамках которой есть как ты выразился "сервисы, морда, модули, кластер ... ". Её задача обеспечить эту поточность обезьянами без изобретиений, фантазий, выдумок и экспериментов. Ты читаешь Фаулера, там слой такой-то, слой-сякой-то, доменная модель, предметная область, репозиторий, транзакция, херакция.... Потом ты вливаешься в проект на Java EE, и все это видишь воочию, и видишь, что все эти
абстракции стандартизированы и решены на уровне сервера приложений, который малой кровью можно заменить на другой от другого производителя, потому что они все
обязаны реализовывать набор одних и тех же интерфейсов. И уж тем более у тебя вдруг не возникает потребность, скажем, в кешировании, и ты начинаешь выбирать ин-мемори БД и прикручивать её к своим модулям, или вдруг ты понимаешь, что твоя ОРМ не наботает с СУБД-нейм, и тебе приходится переписывать половину бизнес-логики, потому что 99 предприятий из ста работают с Ораклом или Постгрессом, а на пятый год проекта ты попал на заказчика у которого MS-SQL, и никого из участников процесса не интересуют твои (программиста) сложности.
душевно, но давайте по порядку
1) согласен, заказчику насрать на чем и как, хотя, не всегда. Это скорее плюс к уже готовым решениям.
2) согласен, надо было сделать еще вчера. Это тоже скорее плюс к готовым решениям.
3) согласен, тз может поменяться в самый неподходящий момент, и в места блога сделайте форум). Так это то же плюс к готовым решениям.
4) не согласен насчет кадров и легаси. У меня проекты новые. А с кадрами еще вопрос, кого проще найти и про порог входа.
5) не согласен насчет некой стандартизации зависимостей. О чем вообще речь? Для полноценного DI нужны интерфейсы, имитация объектов. Оно что в дотнете что пыхе, подозреваю в яве зоопарка библиотек не меньше.
6) согласен. Выбор СУБД вещь действительно важная. И платить за сиквел сервер, когда мускуля оверхватит просто неразумно. Опять битриксу привет.
вообщем объективных технических причин для выбора технологии не приведено
что такое ентерпрайз не раскрыто
