минимальная поверхность для атаки; лучшая простая система на сегодня.
Тут скорее имелось ввиду написание тех же библиоте с минимумом зависимостей и фичей. Например - те же рест клиенты написаные на java без дополнительных зависимостей. В этом случае - чем меньше кодовая база - тем меньше поверхность для атаки. Очевидно, тут автор имел чуть другое - меньше код = проще комплексити = меньше когнитивной нагрузки = проще меинтейнить. Но, конечно же, сомневаюсь, что речь шла про урезание углов по типу экранирования.
> XStream - тем не менее одна из самых популярных библиотек для Xml. В целом я бы лучше пример привел - IDEA-ная библиотека для работы с XML. Она вообще очень маленькая. Просто, понятно. Не всегда удобно, но понятно)
Тут в пример с упрощением фичей можно привести в пример GSON который умер и овер-хед Jackson. Рабочий вариант который покрывает все фичи, проще и понятнее против усложненного продукта в котором стоит разобраться только при прочтении мануала о полях, политиках маршал-анпаршал и те. И это простые примеры - написание бибиотеки - всегда конечный (почти) процесс. В то время как написание проектов / продукто для User End пользования почти всегда завязан на продолжительную подджержку. Тут, как мне кажется - правила, которые говорит автор - начинают играть новыми красками. Например, заказчик хочет, чтобы БП делал тоже, что по тз - но по соверменному с какой то микро-фичей, которая особо не играет функциональной роли - но несет существенную нагрузку на кодовую базу или что хуже - разработчики пытаются напилить на кодовую базу миллионы абстракций на будущее, которые надо будет меинтейнить в будущем.
tl;dr;
Статья про то, что инженерия - это борьба за оптимальное решение и мы, программисты, решаем задачу Min-Max, при работе зачастую в попытках максимизировать результат - на деле его минимизирует. Ну, во всяком случае я так вижу эту статью.
Ну автор делится мнением, к которому он пришел за большое количество времени, видимо он встречал не мало проблем связанных с балансированием между прагматичной скоростью выпуска фичей и поддержкой на будущее. Как мне видится - даже щас многие этого не понимаю и уходят в крайности.
Ну вот LSP это уже круто, да. Но все еще сложный апи для модернизации и написания своих плагинов. В будущем вероятно так в OpenIDE и в Giga будут поддерживаться и другие языки. Он те же LSP это лишь малая часть, там еще нужно всякие ран конфигурации, анализы экосистемы делать и те (да да, привет тому же c# с его прекрасными манифестами). В общем, lsp это круто, но он не решает всех проблем, все равно надо пилить плагины для поддержки связок язык + фреймворк.
Пожалуй, самый простой пример где все просто это Golang где lsp почти все решит. Но не везде так, так что lsp не панацея. А для статических языков IDEA как платформа имхо лучше, хоть и жрет много памяти.
В 251 билде идеи видели Junie? Вот он неплохо работает по контексту, как я понимаю через генеративную состязательноую нейросеть. В общем, идея классная, он строит план, каждую сточку кода пишел как программист, но, очевидно и закапывается еще быстрее обычных llm. Но, думаю, будущее настало)
Ну это сравнение двух IDE. Если пытаться сделать нейтральное сравнение – это будет уже не сравнение. Я просто пробежался по фичам и сказал кейсы что использовать, что нет и в каких сценариях.
На счет некрасиво – лично у меня не вызывает никакой неприязни Giga, я не пытался выставить в не лучшем свете Giga. Тут объективная реальность и конкурентность.
Ребята из гиги, я уверен, почитают и добавят какие-то планы у себя, идеи какие-то (как это было с тем же закрытым скачиванием через SberID). Это рынок. Да и к тому же, я не скрывал ссылки на гигу, объективно сказал что из коробки увы нету у опен какого-либо ассистента и надо будет тащить свой. Так что относительно охвата - двусторонний пиар, если таковым вообще его можно называть.
Ну во многом, ИМХО, Open действительно более продуманная, нежели гига. Однако, разницы мало. Я в статье написал, ждем их Ultimate версию, о которой заявлялось год назад.
Пока в гиге мало пользы(доп. фич в сравнении с CE) – из самого главного свой AI ассистент и чат, которые хоть и далеки от зарубежных аналогов, но по крайней мере внутри гиги бесплатные. Так что инструмент есть за что выбирать, но как я уже сказал - на этом, я больше достоинств не вижу.
Мне не хотелось в статье как то принижать гигу или что-то в этом роде. Я сказал все, что мне пришло на голову из плюсов и минусов о Giga (слабые отличия от CE). Если я пропустил какие-то плюсы(маловероятно) по сравнению c OpenIDE - пишите тут, если будет важно можно будет внести в UPD в статье.
UDP На счет Giga AI – я написал, что он год назад был нуу так себе, но лучше чем ничего. Недавно был релиз новых версий, которые протестить не было времени, потому я в статье написал, что вероятно они стали намного лучше.
Но это не меняет факта, что если у меня есть JB AI (JB Assistant/Jb Junie) + ChatGPT - я ими буду пользоваться. Это факт. Но, если бы у меня не было таких возможностей, конечно же далее выбор пал бы на сберовские ai. Так что, опять все в приоритетах, 0 претензий к сберу, тут выбор идет только из конкурентности и доступности.
А где тут реклама? Просто обзор и мое мнение. Очевидно, что тут просто про приоритеты. 1. IDEA Ultimate самая приоритетная 2. IDEA CE тк обслуживание лучше, но тут уже кому как, особо плюшек кроме стабилити нету. 3. Уже выбор между Giga и Open. Имхо, разницы мало. Выбирал бы OpenIDE из за открытости и встроенного Amplicode если я бут разраб. Giga если у меня нету доступа к другим AI агентам и тут из коробки оно есть.
Если в кратце, в IntelliJ Platform очень продвинутый способ парса AST, его анализа и прочее. Что дает достаточно глубокую поддержку разных механизмов рефактора и подсвета ошибок и те. И замечу, что это касается только строго типизированных языков.
В свою очередь, многие плагины для VSCode делают все сами, не полагаясь на "базу" платформы на которой они находятся. Из-за этого есть кучи плагинов в вс коде, которые просто регексом все делают. Но, конечно, это не обо всех идет речь.
В общем, просто IDEA куда круче именно для написания всяких приколов именно под java тк дает кучу апи который за тебя уже все сделал.
На данный момент, как база, IntelliJ Platform намного более функциональная, по крайней мере для Java/Kotlin. Хотя, от тех же Go разработчиков, я слышал что-то подобное и про GoLand. Собственно, потому и не VsCode - интроспекция, хайлаты и все-все просто лучше в IDEA.
UPD: найти бы мем "У нас так не принято" про Java-разрабов которые ни на чем не пишут, кроме как IDEA-платформы)
Согласен, но. Это все узконаправленный инструмент рассчитаный на то, что вы всегда примерно знаете, сколько пользаков у вас буде на ui заходить. Очевидно, но не generic киллер-фича на все случаи жизни, но вот свой узконаправленный кейс он решает, имхо, почти идеально.
Познавательная статья, спасибо. Вопрос - если делать нечто большее, чем MVP для интеракции пользователей в рантайме, а полноценное решение для конечного клиента, например, показывать на карте - где сейчас находится курьер, как думаете, не лучше ли будет использовать реактивный стек или Virtual Threads хватит? ПС полноценный вопрос - не будет ли virtual thread "троттлить" вычисления?
Камунда хороша в оркестрировании бизнес процессов на микросервисах. Вместо саги и еще десятка паттернов, чтобы приготовить устойчивый и удобный бизнес процесс в микросервисах - можно ограничится централизированным процессом, котороый НИЧЕГО не знает о самих микросервисах, а лишь двигается вперед. Микросервисы знаю малую часть контекста процесса ввиде каких-то взаимодействий. То есть мы остаемся в рамках микросервисов, имеет всякие возможности по типу логирования, откатов процесса, обработки ошибок и тд и те и все в 1 месте. Крайне удобная штука, если у вас сложные бизнес-процессы внутри продуктов, где при прохождении 1 процесса взаимодействуют десятки микросервисов. Ну а так да - с ней очень долго разбираться и это реально боль, а еще визуальный редактор - он сразу вызывает срах и панику) Но по факту очень хорошая вещь в простроении сложных процессов с компенациями и устойчивостью
UPD: на счет дебага - тут тоже плюс за камундой тк все можно трейсить(и ошибки и логи и все все, в микросервисах в целом сложно отлавливать ошибки, с ней чуть попроще)
Сомневаюсь, что Дан Норт младше вас. Если вы посчитали, что преамбула к данному переводу крайне серьезный текст, несущий какие-то неверные трактаты - это не так. Это по большей части кликбейт для более интересного чтения.
Советую все же прочитать статью, а не только первые абзацы, чтиво, имхо, интересное.
Классная ретроспектива вышесказанного. Очевидно, что вряд ли будет время, что когда-то (хотя бы) меньшая часть сообщества будет знать про данные принципы. С моей точки зрения, в первую очередь данные перевод - просто красивое чтиво. Но теперь по делу.
1. Быть юникс означает "стараться" делать одно, и делать что-то хорошо. Не зря автор приводит пример с пайпами и утилитами юникса. Можно рассмотреть пример, что тот же iptable. Делает что-то одно? ну, не одно. Так, что SRP - это конечная точка минимизации в рамках текущего свойства. В целом, вся статья про то, что мы можем решать СЛАУ под названием "программирование", а можем и вместо этого начать минимизировать приближенное решение. Такой подход просто выглядит удобнее и быстрее. Однако, как вы заметили, да, это все субъективщина и это главный недостаток данного подхода.
2. Композиционность - это больше про UI. В Java я сталкиваюсь с такой библиотекой как Vaadin, которая, на мой взгляд демонстрирует суть этого принципа. Опять же все та же субъективщина и минимизация. То есть по сути, ваш код просто должен смотреться одинаково монолитно будучи в любых формах композиции. Пример - у нас есть кнопка и текст филд. Будучи в форме или фильтре они как и с уровня Кода, так и с уровня интерфейса они должны выглядеть как единое целое, и далее новые компоненты которые мы написали - форма и фильтр также должны выглядеть как отдельные компоненты, которые также могут быть скомпанованы в единое целое, например, экран или страницу, итд.
3. Предсказуемость - это BLP в солид, который мы также минимизирует. Однако, тут - как раз двойственная ретроспектива код и софт - оба должны вести себя одинаково. Опять же, можно привести пример текст филда и кнопки, но пусть это будут только интерфейсы, допустим, какой то бизнес логики сложной обработки документов. Если мы обрабатываем хлмх и ворд - не важно что, в любом случае, не зависимо от реализации, на выходе мы будем получать одинаковый результат, а поведение не меняется координально лишь от того, что у нас другой тип документа. Имхо, все те же принципы солид, но в рамках свойств, а не догм.
4. Идиоматичность. Самый тривиальный пункт, пожалуй, который невозможно отнести к какому-то из принципов солид. Тут все просто - в первую очередь разработчик, приходящий в новый проект должен оперировать теми терминами которыми оперирует сообщество (и его команда). Например, на Java не писать открывающую фигурную скобку с новой строки, как это принято в дотнете. Имхо, самый очевидный и итак всеми соблюдаемый принцип(свойство).
Вы не поверите, но, например, большая часть разработчиков видит устаревший синтаксис сишных циклов for как весьма идиоматичный и понятный, тоже самое у них с && вместо and и т.д. А от синтаксиса python, nim и rust они будут плеваться, говоря, что чёт какая-то шляпа и нифига не понятно
5. С доменностью полностью согласен, да как и со всем - это все вкусовщина. Да вся статья про то, что SOLID это объективно и, потому, не так "приятно". В то время как КУПИД - субъективно и приятно, но в глазах каждого из разработчика это будет трактоваться по разному.
6. Вывод
Вывод: автор не понял принципы SOLID, не осознал, что они говорят об объективных вещах, так ещё и в рамках конкретного уровня абстракции (интерфейсов) и поспешил выкинуть их в трубу ради пяти красиво звучащих и весьма субъективных принципов, потому что они "современные и интуитивно понятные".
Не знаю про какого из авторов вы тут говорите) Если про меня - тут как бы статья обрамлена в кликбайт, все остальное - сам перевод. Да, вы правильно заметили, Дан Норт именно это и хочет - чтобы разработчики думали своей головой и приявляли креатив(адекватный). А еще - КУПИД классно транслируется не только на код, но и на весь софт - то есть эти свойства могут оценивать не только "классы" и "связи/композации", но и конкретные высокоуровневые реализации и даже конечные продукты. PS Солид никто выкидывать не собирается) все эти принципы, очевидно, будут применимы и в будущем.
Cпасибо за конкретезированный комментарий! Тоже было интересно почитать.
Вообще да, подход трудно реализовать, так как нужна специальная область, где домены легко разбиваются, но опять же это проблема не подхода, а архитектуры.
В первую очередь - RpS, который ложиться на систему с общим Layout. Вторая - проработка кейсов с CORS/CSRF и XXS - тут у нас будут ссылки на какие то системы, логично, что ссылки кто-то захочет заабузить, потому стоит с осторожностью относиться к приведению ссылок и написанию таких приложений, внимательно следить за сериализацией данных в браузере и осторожно вносить фичи "которые упростят жизнь пользователю". На безопасность стоит обращать больше всего внимания при построении "микро-фронтентдов" на фуллстак фреймворках.
Еще один минус - это DevUX. Если вы будете строить большую систему, придется тестировать и по отдельности и вместе. В общем, над UI придется париться. Если у вас стартап, то лучше начать с монолита, а потом уже думать, куда лучше уходить. Если enterprise - то, тут люди привыкли к сложностям, тут скорее будет легче с root layout-ом.
Опять же, в статье говорил, придется с заказчиком уставливать стандарт того, как выглядит UI. Постановки, изменения, постановки, регламенты. В общем, много боли с согласованиями.
В бекенде/Фулл стаке (то что ближе к моей работе) К сожалению, сама архитектура module federation построена на идеи того, что у вас сборка фронта из исходников происходит. В случае использования фулл-стак фреймворков такое не подойдет, тк происходит или частичный или полный рендер страниц. И тут можно сделать 3 отступления: * Классические фреймворки(RnR, Django, Laravel), где просто генерируются страницы - можно с этим что то сделать, но это крайней степени костыль, вряд ли кто то будет так заморачиться, тут проще с iframe сделать. Касательно классики - тут я подразумеваю, что у нас фреймворк именно фуллстак, а не только апишка. Когда есть фронт отдельно от этих фреймворков - там можно такое замутить. * Jmix / VAADIN - тут можно прям сделать сразу все, если отключить дев сборку и получать не за-chunk-анный / minify-енный билд, его теоретически можно подтягивать в отдельное приложение, где есть вебпак или другая сборка, из разных проектов все это в один собирается и мы делаем аналог. Вот вроде и круто, а вроде на прод такое не запустишь, ибо страшно. * Next/Nuxt - если исхольовать их как фуллстак(в случае каких то простых сервисов с большим UI и малой бекендной логикой) - то можно придумать, как извернуться и собрать все это ПС - в любом из случаев - проще написать маленький фронтеенд и поставить на нем iframe, а от этой архитектуры отталкиваться
Фронтент Тут мне кажется, он раскрывается на максимум, когда у тебя исходники лежать, желательно в монорепозитории и вы не хотите строить микросервисный фронтент - вы делаете модульную федерацию. Это по концепции, как раз, ближе к Self-Contained Systems, но в фронтенде. И получается есть выбор писать фронт, писать микро-фронт и федерацию. Ноооо, как по мне, все термины, которые содержать federation обычно более применимы к экосистеме Node/JS, ведь +- вся эта движуха пошла с apollo
В реальном времени, мне кажется, может быть любая система, которая реагирует за стабильное N время. То есть задержка до ответа прогнозируемая и не выходит за рамки задачи. Где нибудь это время в 10ms, а где-то и пару секунд норма. JVM может быть заменена GraalVM и нативностью, если GC мешает, ну или просто поменять реализацию GC. К тому же, зависит от нагрузки, для одного человека и руби(медленнее питона) может работать в реальном времени даже с неоптимизированном коде.
Но да, если большие данные, вероятно придется заморачиться с нативностью и реактивностью, оптимизациями алгоритмов и все еще иметь боль в заднем месте. Но тут уже дело вкуса и предпочтений. Вопрос другой - насколько бизнесу нужно реальное время и что дешевле и проще - найти джавистов шарящих в нейтиве и реактивщине или найти команду плюсовиков или раст разрабов, которые еще достаточно компитентны в этом вопросе. Не даром у нашего любимого Яндекса есть целое легаси фреймворки по поддержки асинхронности, реактищины в с++. P.S. Я думаю это густые дебри, где решение "риал тайм хайлоада" решается обычной задачей оптимизации - много денег и слишком много данных, то мы берем команды c++/rust. В ином случае - запариваемся с джавистами и реактивным стеком или напираем go разрабов и тоже запариваемся. Имхо, все решается на уровне бюджета и бекграунда компании.
Тут скорее имелось ввиду написание тех же библиоте с минимумом зависимостей и фичей. Например - те же рест клиенты написаные на java без дополнительных зависимостей. В этом случае - чем меньше кодовая база - тем меньше поверхность для атаки. Очевидно, тут автор имел чуть другое - меньше код = проще комплексити = меньше когнитивной нагрузки = проще меинтейнить. Но, конечно же, сомневаюсь, что речь шла про урезание углов по типу экранирования.
> XStream - тем не менее одна из самых популярных библиотек для Xml. В целом я бы лучше пример привел - IDEA-ная библиотека для работы с XML. Она вообще очень маленькая. Просто, понятно. Не всегда удобно, но понятно)
Тут в пример с упрощением фичей можно привести в пример GSON который умер и овер-хед Jackson. Рабочий вариант который покрывает все фичи, проще и понятнее против усложненного продукта в котором стоит разобраться только при прочтении мануала о полях, политиках маршал-анпаршал и те. И это простые примеры - написание бибиотеки - всегда конечный (почти) процесс. В то время как написание проектов / продукто для User End пользования почти всегда завязан на продолжительную подджержку. Тут, как мне кажется - правила, которые говорит автор - начинают играть новыми красками. Например, заказчик хочет, чтобы БП делал тоже, что по тз - но по соверменному с какой то микро-фичей, которая особо не играет функциональной роли - но несет существенную нагрузку на кодовую базу или что хуже - разработчики пытаются напилить на кодовую базу миллионы абстракций на будущее, которые надо будет меинтейнить в будущем.
tl;dr;
Статья про то, что инженерия - это борьба за оптимальное решение и мы, программисты, решаем задачу Min-Max, при работе зачастую в попытках максимизировать результат - на деле его минимизирует. Ну, во всяком случае я так вижу эту статью.
Ну автор делится мнением, к которому он пришел за большое количество времени, видимо он встречал не мало проблем связанных с балансированием между прагматичной скоростью выпуска фичей и поддержкой на будущее. Как мне видится - даже щас многие этого не понимаю и уходят в крайности.
Ну вот LSP это уже круто, да. Но все еще сложный апи для модернизации и написания своих плагинов. В будущем вероятно так в OpenIDE и в Giga будут поддерживаться и другие языки. Он те же LSP это лишь малая часть, там еще нужно всякие ран конфигурации, анализы экосистемы делать и те (да да, привет тому же c# с его прекрасными манифестами). В общем, lsp это круто, но он не решает всех проблем, все равно надо пилить плагины для поддержки связок язык + фреймворк.
Пожалуй, самый простой пример где все просто это Golang где lsp почти все решит. Но не везде так, так что lsp не панацея. А для статических языков IDEA как платформа имхо лучше, хоть и жрет много памяти.
В 251 билде идеи видели Junie? Вот он неплохо работает по контексту, как я понимаю через генеративную состязательноую нейросеть. В общем, идея классная, он строит план, каждую сточку кода пишел как программист, но, очевидно и закапывается еще быстрее обычных llm. Но, думаю, будущее настало)
Ну это сравнение двух IDE. Если пытаться сделать нейтральное сравнение – это будет уже не сравнение. Я просто пробежался по фичам и сказал кейсы что использовать, что нет и в каких сценариях.
На счет некрасиво – лично у меня не вызывает никакой неприязни Giga, я не пытался выставить в не лучшем свете Giga. Тут объективная реальность и конкурентность.
Ребята из гиги, я уверен, почитают и добавят какие-то планы у себя, идеи какие-то (как это было с тем же закрытым скачиванием через SberID). Это рынок. Да и к тому же, я не скрывал ссылки на гигу, объективно сказал что из коробки увы нету у опен какого-либо ассистента и надо будет тащить свой. Так что относительно охвата - двусторонний пиар, если таковым вообще его можно называть.
Ну во многом, ИМХО, Open действительно более продуманная, нежели гига.
Однако, разницы мало. Я в статье написал, ждем их Ultimate версию, о которой заявлялось год назад.
Пока в гиге мало пользы(доп. фич в сравнении с CE) – из самого главного свой AI ассистент и чат, которые хоть и далеки от зарубежных аналогов, но по крайней мере внутри гиги бесплатные. Так что инструмент есть за что выбирать, но как я уже сказал - на этом, я больше достоинств не вижу.
Мне не хотелось в статье как то принижать гигу или что-то в этом роде. Я сказал все, что мне пришло на голову из плюсов и минусов о Giga (слабые отличия от CE). Если я пропустил какие-то плюсы(маловероятно) по сравнению c OpenIDE - пишите тут, если будет важно можно будет внести в UPD в статье.
UDP
На счет Giga AI – я написал, что он год назад был нуу так себе, но лучше чем ничего. Недавно был релиз новых версий, которые протестить не было времени, потому я в статье написал, что вероятно они стали намного лучше.
Но это не меняет факта, что если у меня есть JB AI (JB Assistant/Jb Junie) + ChatGPT - я ими буду пользоваться. Это факт. Но, если бы у меня не было таких возможностей, конечно же далее выбор пал бы на сберовские ai. Так что, опять все в приоритетах, 0 претензий к сберу, тут выбор идет только из конкурентности и доступности.
А где тут реклама? Просто обзор и мое мнение. Очевидно, что тут просто про приоритеты.
1. IDEA Ultimate самая приоритетная
2. IDEA CE тк обслуживание лучше, но тут уже кому как, особо плюшек кроме стабилити нету.
3. Уже выбор между Giga и Open. Имхо, разницы мало. Выбирал бы OpenIDE из за открытости и встроенного Amplicode если я бут разраб. Giga если у меня нету доступа к другим AI агентам и тут из коробки оно есть.
В целом, об этом вся статья.
Если в кратце, в IntelliJ Platform очень продвинутый способ парса AST, его анализа и прочее. Что дает достаточно глубокую поддержку разных механизмов рефактора и подсвета ошибок и те. И замечу, что это касается только строго типизированных языков.
В свою очередь, многие плагины для VSCode делают все сами, не полагаясь на "базу" платформы на которой они находятся. Из-за этого есть кучи плагинов в вс коде, которые просто регексом все делают. Но, конечно, это не обо всех идет речь.
В общем, просто IDEA куда круче именно для написания всяких приколов именно под java тк дает кучу апи который за тебя уже все сделал.
На данный момент, как база, IntelliJ Platform намного более функциональная, по крайней мере для Java/Kotlin.
Хотя, от тех же Go разработчиков, я слышал что-то подобное и про GoLand. Собственно, потому и не VsCode - интроспекция, хайлаты и все-все просто лучше в IDEA.
UPD: найти бы мем "У нас так не принято" про Java-разрабов которые ни на чем не пишут, кроме как IDEA-платформы)
Вот ссылка на репу с платинами
Согласен, но. Это все узконаправленный инструмент рассчитаный на то, что вы всегда примерно знаете, сколько пользаков у вас буде на ui заходить. Очевидно, но не generic киллер-фича на все случаи жизни, но вот свой узконаправленный кейс он решает, имхо, почти идеально.
Познавательная статья, спасибо.
Вопрос - если делать нечто большее, чем MVP для интеракции пользователей в рантайме, а полноценное решение для конечного клиента, например, показывать на карте - где сейчас находится курьер, как думаете, не лучше ли будет использовать реактивный стек или Virtual Threads хватит?
ПС полноценный вопрос - не будет ли virtual thread "троттлить" вычисления?
Камунда хороша в оркестрировании бизнес процессов на микросервисах. Вместо саги и еще десятка паттернов, чтобы приготовить устойчивый и удобный бизнес процесс в микросервисах - можно ограничится централизированным процессом, котороый НИЧЕГО не знает о самих микросервисах, а лишь двигается вперед. Микросервисы знаю малую часть контекста процесса ввиде каких-то взаимодействий. То есть мы остаемся в рамках микросервисов, имеет всякие возможности по типу логирования, откатов процесса, обработки ошибок и тд и те и все в 1 месте. Крайне удобная штука, если у вас сложные бизнес-процессы внутри продуктов, где при прохождении 1 процесса взаимодействуют десятки микросервисов. Ну а так да - с ней очень долго разбираться и это реально боль, а еще визуальный редактор - он сразу вызывает срах и панику) Но по факту очень хорошая вещь в простроении сложных процессов с компенациями и устойчивостью
UPD: на счет дебага - тут тоже плюс за камундой тк все можно трейсить(и ошибки и логи и все все, в микросервисах в целом сложно отлавливать ошибки, с ней чуть попроще)
Рассматривате ли в будущем фичу по работе с фронтом/реакт админом не только в VS Code, а например, в IntelliJ IDEA Ultimate/WebStorm?
Сомневаюсь, что Дан Норт младше вас. Если вы посчитали, что преамбула к данному переводу крайне серьезный текст, несущий какие-то неверные трактаты - это не так. Это по большей части кликбейт для более интересного чтения.
Советую все же прочитать статью, а не только первые абзацы, чтиво, имхо, интересное.
Классная ретроспектива вышесказанного. Очевидно, что вряд ли будет время, что когда-то (хотя бы) меньшая часть сообщества будет знать про данные принципы. С моей точки зрения, в первую очередь данные перевод - просто красивое чтиво. Но теперь по делу.
1. Быть юникс означает "стараться" делать одно, и делать что-то хорошо. Не зря автор приводит пример с пайпами и утилитами юникса. Можно рассмотреть пример, что тот же iptable. Делает что-то одно? ну, не одно. Так, что SRP - это конечная точка минимизации в рамках текущего свойства. В целом, вся статья про то, что мы можем решать СЛАУ под названием "программирование", а можем и вместо этого начать минимизировать приближенное решение. Такой подход просто выглядит удобнее и быстрее. Однако, как вы заметили, да, это все субъективщина и это главный недостаток данного подхода.
2. Композиционность - это больше про UI. В Java я сталкиваюсь с такой библиотекой как Vaadin, которая, на мой взгляд демонстрирует суть этого принципа. Опять же все та же субъективщина и минимизация. То есть по сути, ваш код просто должен смотреться одинаково монолитно будучи в любых формах композиции. Пример - у нас есть кнопка и текст филд. Будучи в форме или фильтре они как и с уровня Кода, так и с уровня интерфейса они должны выглядеть как единое целое, и далее новые компоненты которые мы написали - форма и фильтр также должны выглядеть как отдельные компоненты, которые также могут быть скомпанованы в единое целое, например, экран или страницу, итд.
3. Предсказуемость - это BLP в солид, который мы также минимизирует. Однако, тут - как раз двойственная ретроспектива код и софт - оба должны вести себя одинаково. Опять же, можно привести пример текст филда и кнопки, но пусть это будут только интерфейсы, допустим, какой то бизнес логики сложной обработки документов. Если мы обрабатываем хлмх и ворд - не важно что, в любом случае, не зависимо от реализации, на выходе мы будем получать одинаковый результат, а поведение не меняется координально лишь от того, что у нас другой тип документа. Имхо, все те же принципы солид, но в рамках свойств, а не догм.
4. Идиоматичность. Самый тривиальный пункт, пожалуй, который невозможно отнести к какому-то из принципов солид. Тут все просто - в первую очередь разработчик, приходящий в новый проект должен оперировать теми терминами которыми оперирует сообщество (и его команда). Например, на Java не писать открывающую фигурную скобку с новой строки, как это принято в дотнете. Имхо, самый очевидный и итак всеми соблюдаемый принцип(свойство).
5. С доменностью полностью согласен, да как и со всем - это все вкусовщина. Да вся статья про то, что SOLID это объективно и, потому, не так "приятно". В то время как КУПИД - субъективно и приятно, но в глазах каждого из разработчика это будет трактоваться по разному.
6. Вывод
Не знаю про какого из авторов вы тут говорите) Если про меня - тут как бы статья обрамлена в кликбайт, все остальное - сам перевод. Да, вы правильно заметили, Дан Норт именно это и хочет - чтобы разработчики думали своей головой и приявляли креатив(адекватный). А еще - КУПИД классно транслируется не только на код, но и на весь софт - то есть эти свойства могут оценивать не только "классы" и "связи/композации", но и конкретные высокоуровневые реализации и даже конечные продукты.
PS Солид никто выкидывать не собирается) все эти принципы, очевидно, будут применимы и в будущем.
Cпасибо за конкретезированный комментарий! Тоже было интересно почитать.
Можно и не верить, но есть факты.
Вот ссылки на статьи innoq которые пилят подобные e-commerce SCS приложения:
- https://www.innoq.com/en/cases/kommunikationsportal-edeka/|
- https://www.innoq.com/en/cases/best-in-industry-e-commerce-plattform-fuer-elektronikkomponenten/
Вообще да, подход трудно реализовать, так как нужна специальная область, где домены легко разбиваются, но опять же это проблема не подхода, а архитектуры.
В первую очередь - RpS, который ложиться на систему с общим Layout. Вторая - проработка кейсов с CORS/CSRF и XXS - тут у нас будут ссылки на какие то системы, логично, что ссылки кто-то захочет заабузить, потому стоит с осторожностью относиться к приведению ссылок и написанию таких приложений, внимательно следить за сериализацией данных в браузере и осторожно вносить фичи "которые упростят жизнь пользователю". На безопасность стоит обращать больше всего внимания при построении "микро-фронтентдов" на фуллстак фреймворках.
Еще один минус - это DevUX. Если вы будете строить большую систему, придется тестировать и по отдельности и вместе. В общем, над UI придется париться. Если у вас стартап, то лучше начать с монолита, а потом уже думать, куда лучше уходить. Если enterprise - то, тут люди привыкли к сложностям, тут скорее будет легче с root layout-ом.
Опять же, в статье говорил, придется с заказчиком уставливать стандарт того, как выглядит UI. Постановки, изменения, постановки, регламенты. В общем, много боли с согласованиями.
Супер гуд.
В бекенде/Фулл стаке (то что ближе к моей работе)
К сожалению, сама архитектура module federation построена на идеи того, что у вас сборка фронта из исходников происходит.
В случае использования фулл-стак фреймворков такое не подойдет, тк происходит или частичный или полный рендер страниц. И тут можно сделать 3 отступления:
* Классические фреймворки(RnR, Django, Laravel), где просто генерируются страницы - можно с этим что то сделать, но это крайней степени костыль, вряд ли кто то будет так заморачиться, тут проще с iframe сделать. Касательно классики - тут я подразумеваю, что у нас фреймворк именно фуллстак, а не только апишка. Когда есть фронт отдельно от этих фреймворков - там можно такое замутить.
* Jmix / VAADIN - тут можно прям сделать сразу все, если отключить дев сборку и получать не за-chunk-анный / minify-енный билд, его теоретически можно подтягивать в отдельное приложение, где есть вебпак или другая сборка, из разных проектов все это в один собирается и мы делаем аналог. Вот вроде и круто, а вроде на прод такое не запустишь, ибо страшно.
* Next/Nuxt - если исхольовать их как фуллстак(в случае каких то простых сервисов с большим UI и малой бекендной логикой) - то можно придумать, как извернуться и собрать все это
ПС - в любом из случаев - проще написать маленький фронтеенд и поставить на нем iframe, а от этой архитектуры отталкиваться
Фронтент
Тут мне кажется, он раскрывается на максимум, когда у тебя исходники лежать, желательно в монорепозитории и вы не хотите строить микросервисный фронтент - вы делаете модульную федерацию. Это по концепции, как раз, ближе к Self-Contained Systems, но в фронтенде. И получается есть выбор писать фронт, писать микро-фронт и федерацию. Ноооо, как по мне, все термины, которые содержать federation обычно более применимы к экосистеме Node/JS, ведь +- вся эта движуха пошла с apollo
В реальном времени, мне кажется, может быть любая система, которая реагирует за стабильное N время. То есть задержка до ответа прогнозируемая и не выходит за рамки задачи. Где нибудь это время в 10ms, а где-то и пару секунд норма. JVM может быть заменена GraalVM и нативностью, если GC мешает, ну или просто поменять реализацию GC.
К тому же, зависит от нагрузки, для одного человека и руби(медленнее питона) может работать в реальном времени даже с неоптимизированном коде.
Но да, если большие данные, вероятно придется заморачиться с нативностью и реактивностью, оптимизациями алгоритмов и все еще иметь боль в заднем месте. Но тут уже дело вкуса и предпочтений. Вопрос другой - насколько бизнесу нужно реальное время и что дешевле и проще - найти джавистов шарящих в нейтиве и реактивщине или найти команду плюсовиков или раст разрабов, которые еще достаточно компитентны в этом вопросе. Не даром у нашего любимого Яндекса есть целое легаси фреймворки по поддержки асинхронности, реактищины в с++.
P.S. Я думаю это густые дебри, где решение "риал тайм хайлоада" решается обычной задачей оптимизации - много денег и слишком много данных, то мы берем команды c++/rust. В ином случае - запариваемся с джавистами и реактивным стеком или напираем go разрабов и тоже запариваемся. Имхо, все решается на уровне бюджета и бекграунда компании.