Комментарии 21
Да ведь вам ещё приходится пользоваться языками программирования которые написаны не вами. Вот я по работе пишу на Go, но я не всем в нём доволен. Может надо компании всё бросить и свой язык уже писать.
Или лучше на ассемблере все микросервисы забабахать. Правда войны синтаксисов неизбежны - но по крайней мере за переносимость переживать не надо (пока) т.к. решение деплоится в строго определённые контейнеры...
А уж про зависимость разработчиков от IDE я вообще молчу. И с выходками отщепенцев JetBrains эта проблема для многих стала острой. Надо писать свой редактор. Каждой компании свой редактор! И компилятор. И процессор производить собственные (моя текущая компания этим занимается отчасти, но по другой причине).
В целом я хотя согласен с автором насчет того что излишняя зависимость от фреймворков (особенно в тех направлениях где они вырастают как грибы каждый год и объявляют прошлогодние морально устаревшими) - но не думаю что этот пойнт тянет на такую серьёзную статью, извините :)
Вот я по работе пишу на Go, но я не всем в нём доволен. Может надо компании всё бросить и свой язык уже писать.
Вы только что разблокировали новый уровень понимания, поздравляю.
Язык Go был создан Google как раз ради независимости от чужих технологий (одна из причин), так что да, все крупные компании рано или поздно приходят к собственным средствам разработки.
А ещё библиотеками, разработанными на ими, операционными системами, оборудованием, сетями, всякими там СУБД, брокерами, оркестраторами и многим другим. Но это ещё полбеды, ведь за пределами ИТ проблема ещё острее, приходится жить и работать среди неподконтрольных людей в неподконтрольных странах по неподконтрольным законами в нестабильной по определению неподконтрольной экономике. Столько всего может пойти не так!
Читал с недоумением - о чем вообще ЭТО?! Последний параграф ответил на этот вопрос.
Я в своё время отказался строить ядро системы на стороннем фреймворке по трём причинам:
Много лишнего. Универсальные фреймворки пытаются удовлетворить всех и каждого, в результате приходится тянуть в проект массу фич, которые никогда не будут использоваться.
Скорость. В значительной степени следствие предыдущего пункта: универсальность тянет за собой множество слоёв абстракций, что с высокой вероятностью приведёт к снижению производительности в высоконагруженных системах (у меня как раз такая).
Безопасность. При всём том, что над ней работают профессионалы высокого класса, атаки на популярные фреймворки разрабатывают профессионалы ничуть не худшие, потом эксплойты быстро становятся общедоступными и активно используются. Постоянно фиксирую попытки проникновения через известные уязвимости – которые благодаря использованию кастомного решения ни к чему не приводят.
Пока (15+ лет) не пожалел – всё работает, требует минимального обслуживания, производительность удовлетворительная, безопасность тоже.
Но разумеется, такой подход целесообразен только в больших, долгосрочных проектах.
Это конечно зэеер гуд, что Вы написали про боли больных. Однако, целеполагание нарушено. Модные "фрейморки" - не о программной инженерии, а о том как взять боб$ла с очередного кролика, которому монополисты прозузжжали ухи о "бесплатной" волшебной таблетке от них же любимых. Ну, которую сьел, водой запил - и всё супер-пупер. Мозги ему не вправить - ему жэ Гугл про Angulal и цэлы Цукер про ПиторчЪ сказали. Зато ?$$.$$$+ выдаиваются. В общем, чтобы полюбить котов - следует научиться их готовить. ;)
По моему опыту, ПО пишется раз, а потом лет десять пятнадцать проводит в эксплуатации без резких движений по миграциям и серьезных переписываний. И только потом, если требуется, проводится тотальная модернизация. В любом случае за такое время подходы и инструменты себя изживают, и их надо полностью менять. Если же писать фреймворки самим, то будущее у них то же самое, при этом будет потрачена куча времени на разработку и выгребание ошибок. А если другим языком, это раздувание бюджета с потерей качества.
ПО пишется раз, а потом лет десять пятнадцать проводит в эксплуатации без резких движений по миграциям и серьезных переписываний.
Ооочень большая редкость, настолько большая что хотел бы услышать как минимум название отрасли, в которой подобное еще возможно.
Более обыденная ситуация, это все же постоянный процесс доработки «без резких движений» — пока софтом пользуются, к нему постоянно будут какие‑то требования и хотелки.
Госсектор, документооборот. Вам грубо говоря разок насыпают на разработку, дальше бюджеты поддержки. Естественно, революций там не будет, будут точечные работы. А особенно, если какая то криптография или межведомственное взаимодействие, там всё очень туго, контракты между подсистемами обновляются очень редко с кучей согласований, бюрократией, испытаниями, сертификацией, где то даже с тематическими исследованиями и контрольными суммами на бинарниках.
Да и по теме доработок, ведь это же не полная переработка. К примеру, если у вас штук 20 сервисов и надо сделать 21й, то первые двадцать получат точечные доработки, и никто там революцию с тотальной миграцией устраивать не будет. Или всё таки будет? Просто если заказчик заплатил только за 21й сервис, то прожирать бюджеты на остальные 20 - сомнительная идея.
Естественно, революций там не будет, будут точечные работы.
В которые вполне попадают и вопросы миграции. Не назвал бы такие работы "революцией", просто банальное обновление используемых библиотек.
С учетом вала критических ошибок с безопасностью везде, обоснование для таких работ очень даже есть и находит понимание у РП.
если какая то криптография или межведомственное взаимодействие
Межвед вне СМЭВ же запретили давно?
К примеру, если у вас штук 20 сервисов и надо сделать 21й, то первые двадцать получат точечные доработки, и никто там революцию с тотальной миграцией устраивать не будет.
Зависит от. Мы честно выдаем список CVE и объясняем чем это грозит, включая штрафы и увольнения.
Обмены вне СМЭВ не запретили, есть конструкции, которые работают по сей день. Там главный принцип обеспечения безопасности - выдернутые сетевые кабеля, закрытые контура, глушилки, и прочие криптографические фокусы. В остальном - всё современное ПО - сплошное решето, CVE тут не более, чем самообман.
Насчет апгрейдов, не всегда всё одинаково, тот же ангуляр апгрейдят примерно +2 версии за один раз, так наиболее комфортно, иначе бардачный веб через года три превратит ПО в тыкву. Но вот тот же спринг бут обновляется очень редко. Его версию в рамках 2.X поменять легко, перейти с 2го на 3й - уже ощутимо. Вдобавок к этому есть еще сертификация, к примеру сертифицирована только java 11 и postgre определенной версии и всё, никуда вы с них не рыпнетесь, иначе ваша сертификация слетит.
Есть еще момент, когда вы работаете на субподряде и код сервисов вообще не ваш, один раз отработали и передали генподрядчику.
тот же ангуляр апгрейдят примерно +2 версии за один раз
С учетом выхода по новой версии раз в полгода - вполне нормально, как раз укладывается в обычное сопровождение проекта.
Но вот тот же спринг бут обновляется очень редко.
Зря, мы прям показываем что-то такое в живую, очень помогает в вопросах обновления )
Вдобавок к этому есть еще сертификация, к примеру сертифицирована только java 11
Если речь про небезизвесный Astra Linux, то там вопрос в сертификации самого Astra Linux и всех инструментов, с ним поставляемых -т.е. смысл в том чтобы использовать только сертифицированные (а не сторонние) инструменты и рантайм.
Последняя Java там 17, если память не изменяет.
Чтобы сертифицировали отдельно JDK не видел, зачем?
Можно, конечно, обновлять, но вас это не спасёт, Spring Boot как был сплошной дырой, так и остался таковым после обновления. К тому же, если человек уже работает в закрытом контуре - через какой то несчастный сервис он не полезет, а будет использовать другие методы, к примеру, напрямую работая с СУБД или чем-нибудь другим. Когда такие вопросы(безопасности) прорабатываются, сервисы в них вообще не фигурируют, по причинам, указанным выше. Они считаются дырой при любых условиях.
По Java - мне при разработке указывали сертифицированную версию OpenJDK, которую я мог использовать. В этом вопросе я вам предельно точно ничего сказать не смогу, не знаю как это работает, и что там можно, что нельзя. Основная мысль только в том, что там ограниченный набор версий и он важен больше с точки зрения соблюдения формальных требований.
Самое обычное дело, более чем частый кейс. Что у бизнеса, что в госсекторе. Регулярно обновляют и развивают только то, что регулярно продают. Коммерческий продукт, по лицензиям, или подписке. И то далеко не всегда. Масштабное переписывание убыточно, в подавляющем большинстве случаев.
Компьютерные игры. Там своих движков все меньше и меньше вроде
Обратная сторона фреймворков