Куда сложнее история с тем, что функциональный код часто весьма непросто читать непривычным взглядом.
Вопрос привычки. Если взять того кто с функциональщины начинал, для него ООП также будет взрывом мозга.
Сложность реализации тривиальных вещей может быть избыточна.
Ну во-первых, ФП ФП рознь. Есть экстремальные вещи вроде чистого Haskell подобного ФП а есть умеренные вроде Clojure. Во-вторых, в ООП такая же история. Сколько часто нужно нагородить классов, отнаследоваться, попереопределять, открыть закрыть чтобы написать тривиальную вещь на ООП языке.
Во всех остальных случаях более сложная доменная модель имеет сильное преимущество в поддерживаемости: моделирование делает код нагляднее, в абстрагирование снижает coupling и позволяет убрать дублирование.
Это правда. Но почему то все забывают что это привносит кучу проблем, потому что такое моделирование не налазит на реальную действительность: работа с базой превращается в костыль, повсюду маппинги ради маппингов, проблема с инвариантами объектов т.к. домена 18 полей а из интеграции пришло 3, что же делать, и прочее прочее прочее.
У ООП свои очень серьезные преимущества, которые я рекомендую не игнорировать. Повторюсь, эти преимущества:
высокий cohesion за счет хранения данных и поведения в одном месте
хорошие инструменты инкапсуляции модели, защищающие вашу модель от некорректного состояния
полиморфизм, позволяющие устранять дублирование там, где в ином случае вы были бы обречены.
Может быть в теории. На практике это не очень работает и почти все пишут опираясь на анемичную модель.
По поводу полиморфизма - забавно. Во первых, не в ООП придумали полиморфизм. Во вторых в ООП используется не самый его продвинутый его вид. Так что в чем эти серьезные преимущества непонятно.
Анемичная доменная модель
Когда вся логика лежит в сервисах, а не в доменных объектах, то это все еще работает, но уже не особо что-то моделирует. Таким образом вы лишили себя всех преимущств ООП: высокого cohesion, инкапсуляции модели, полиморфизма для разруливания дублирования и абстракции логики. Помимо этого вы перемешали логику уровня приложения с логикой предметной области, и теперь каждый раз надо отделять виски от колы, чтобы что-то понять.
В целом, анемичная доменная модель - это Transaction Script с издержками доменной модели, худшее из двух подходов.
Опять таки, в теории да. На практике, лично на моем опыте, богатает модель просто нежизнеспособна. Оно все хорошо только и только пока нам хватает данных которые есть в объекте для валидаций и вычислений. Как только нам нужно что-то еще, все это превращается в тыкву и костыль. И судя по тому что подавляющее большинство используют анемичную модель, это не только мои выводы.
А зачем ссылаться на штучных визионеров, если в обсуждаемой статье речь идёт про работу в найме на линейных позициях? У них свой независимый путь.
Действительно, а зачем вообще какой-то логике придерживаться доказывая свое мнение как это делаете Вы? Мат модел не работает не важно, у нас своя математика, есть опровергающие примеры - нее таких единицы, у нас же в мире нет такого что чем талантливее и умнее человек тем часто он надменнее и высокомернее. Такого же не бывает в мире и не может быть чтобы сотруднику сходило с рук многое и его терпели только потому что он хороший или отличный специалист.
Вообще, это интересная психологическая ловушка. Когда хочется быть похожим на Линуса или Стива - ну результатами пока не получается, так хоть тяжестью характера, уже приятно.
но в реальной жизни если человек создает явные проблемы, то они как правило перекрывают любую пользу от него.
Я правильно понимаю что Линус Торвальдс создал больше проблем чем решил, в силу своего отвратительного проблемного характера? Джон Кармак, Стив Джобс, Ричард Столлман, продолжать можно долго. Про высокомерие и проблемность сотен ученых которые построили этот мир мне кажется и говорить не приходиться. Но у Вас логика прямая как палка - явные проблемы перекрывают любую пользу от человека .
А вот если не секрет, если заболеете Вы пойдете к какому врачу, к хамоватому, высокомерному проверенному мега-специалисту или к очень вежливому и приятному бездарю?
Сами того не заметив, вы случайно притопили за противоположную точку зрения :)Потому что бесполезный сотрудник это меньшее зло, чем проблемный. Ноль предпочтительнее минуса. Это может быть неочевидно, но это так.
У Вас небольшие пробелы с мат моделированием. Если k - это условный показатель пользы от конкретного сотрудника то проблемный сотрудник это k-n, где n - это условный показатель вреда от такого сотрудника. Таким образом, польза k от такого сотрудника может быть как больше так и меньше 0. В то время как польза от бесполезного сотрудника всегда k = 0.
В начале кажется, что главное — хорошо написать код. Всё остальное — вторично. Но очень быстро выясняется: код — только половина работы. Вторая половина — это люди.
Программист который умеет хорошо писать код но не умеет общаться - проблемный.
Программист который умеет все на свете кроме того как писать код - бесполезный.
Выводы делайте сами. Конечно софт скилы имеют особую важность особенно от лидских позиций и выше. Но не нужно их настолько переоценивать. Есть гениальный программист с отвратительным характером и коммуникациями. Можем ли мы создать для него условия чтобы решить проблемы с коммуникациями и получать огромные выгоды от его хардскилов? Да может. С другой стороны если у нас есть программист(не тимлид) которого все любят и он умеет договариваться со всеми но абсолютно безнадежный в техническом плане. Что мы получим? Человека который будет нравиться всем но по факту делегировать все задачи кому-то другому при этом получая большую зп и премии от начальства.
На собеседованиях и в процессе работы они оценивают не только знание технологий, но и то, как ты ведёшь себя в обсуждении: умеешь ли задавать уточняющие вопросы, доносишь ли свои мысли ясно, способен ли аргументированно отстаивать решение или соглашаешься, когда неправ.
В идеале может быть. В реальности чаще всего на это ни у кого нет времени.
Но если посмотреть на статистику от IT-рекрутеров и отчёты команд, становится видно: увольняют чаще всего не за плохой код.
Один из HR-отчетов Hays показал: до 70% джунов не проходят испытательный срок, особенно в крупных и технологически зрелых компаниях. Причины? Ошибки в коммуникации, неумение работать в команде, отказ воспринимать фидбек и пассивная позиция в процессе. Технический пробел — лишь на четвёртом месте.
Мне вот интересно это как? Работает человек с высоким техническим скилом делает задачи без ошибок а его увольняют за ошибки в коммуникации? Я лично про такое не слышал.
Скорей всего, 70% не тянут технически, при этом у них не хватает софт скилов чтобы это компенсировать. Это не доказывает что 30% увольняют из-за нехватки технических навыков а 70% из-за нехватки софтскилов.
В общем в статье вроде бы все правильно написано и идеальный разработчик для бизнеса это и технарь и рубаха парень.
Но все-таки основное занятие работаботчика - решать технические проблемы.И чем больше следуя современной моде, компании меняют приоритет в сторону софтскилов, тем ниже мы наблюдаем компетенции современных команд и качество современного продукта.
Kotlin это менее многословная Java с большим количеством синтаксического сахара.
Ну, на самом деле нет. Kotlin - это язык который гораздо ближе к C# и Scala чем к Java.
У языка должна была быть главная киллерфича - Kotlin Multiplatform (KMP) один язык для решения большинства проблем: backend/frontend/mobile. KotlinJVM это только одна из частей языка.
Идея хорошая но проблема в том что JB не вывезли такую глобальную задачу. KotlinJS не взлетел и думаю не взлетит. KMM идея оказалась не самой удачной и по моему личному мнению проиграла флаттеру. KotlinNative вообще не понятно кому нужен, кроме как часть проекта KMM. По итогу, из всего этого зоопарка взлетел только Kotlin на Android, потому что там разрабы устали от работы на Java 7 ну и чуть чуть занял backend.
Почему так вышло? Потому что JB не смогли реализовать свои замыслы. Если бы на kotlin можно было писать и back и front и mobile это было бы преимуществом. Так это не взлетело в сухом остатке только KotlinJvm, где да, более удобный чем Java язык и даже более надежный. Но вот это "чуть более" не перевешивает неудобств по внедрению, поддержке, обучению и найму на дополнительный язык. Никому не нужно "чуть лучше".
Ещё слышал мнение, что Kotlin это Scala, из которой убрали фичи, которые были добавлены только для защиты чьего-то PhD, и причесали оставшиеся. Функциональное программирование для широких масс.
Не совсем. Kotlin - это смесь Scala + C# с щепоткой Groovy. От Scala действительно много чего досталось, но брали адекватные части языка и не брали сложные и неадекватные. В Kotlin в отличии от Scala почти нет ФП и это осознанное решение разработчиков. Сами разработчики заявляли - полноценной поддержки ФП нет и не будет.
Go → Пиши бек-энд и тулзы к нему как в Google (Google)
А в чем аргумент вида "как в Гугл"?
Мой мнение, Go взлетел благодаря фиче мега-хантинга. Это наверное самый простой язык для перехода. Когда компании поняли что могут пылесосить разные стеки и сделать из кандидатов гоферов вместо того чтобы искать чисто свой стек - Go пошел на взлет. Т.е. был язык который дает неплохие характеристики(производительность/память,простота и многопоточка из коробки ) в купе с некромантией найма, вот и рецепт его успеха. Без некромантии скорей всего бы не взлетел, так как экосистемы не было как и разработчиков.
Другой отличный пример Kotlin. При всех плюсах взлетел только на Android и то потому что там всем уже надоело сидеть на 7 джаве. В других местах не очень взлетел так как по сути не привнес ничего кардинально нового и у языка действительно нет никакой киллер фичи. Ну точнее киллер фича была - стать универсальным языком для бэка, фронта, мобилок и т.д. Но JB такое просто не вывезли.
Есть такая вещь называется доказательная медицина. Это когда лечение выбирается на основании доказанного метода а не того что какой то человек на основе своего опыта и субъективного мнения считает что метод работает. Про инженерное дело я вообще молчу.
То что Вы пришли к каким то идеям это замечательно. Но если человек развивается, то через какое-то время есть определенный шанс что с опытом его мнение измениться. Так очень часто бывает. Более того, многие люди склонны к одержимости идеями и могут оказаться в их плену доказывая свою правоту ни смотря ни на что.
Именно поэтому, если нас интересует рабочая методика а не поклонение идеям, мы должны эти идеи активно критиковать.
Вместо этого что мы видим в области DDD? Бесчисленное количество теоретических статей и заявления об эффективности методики основанные исключительно на вере и субъективном восприятии. На любые просьбы хоть как то обосновать методику, находиться 100 и 1 причина, почему это невозможно сделать. Просто верьте на слово.
Что до конкретных примеров - устройтесь на работу в FAANG и увидите, как это делается на практике.
Проще говоря - DDD в полную силу оправдывает себя в тех проектах, которые обычно в Open Source не попадают. Большие проекты, над которыми несколько высокопрофессиональных команд согласованно работают на протяжении нескольких лет.
Браво. Ответ который мы заслужили. Зачем доказывать и показывать идеи, пусть лучше кому интересно идут лесом в FAANG и сами проверяют да и вообще это нельзя показать - это все в закрытых репозиториях, где исключительно профессиональные команды над этим работают, главное просто верить что все это работает. Инженерный подход 10 из 10.
PS мне это один в один напоминает подход школ восточных боевых искусств, которые на словах рассказываются про свою невероятную эффективность но при попытке вызвать на спарринг для практического эксперимента сразу идут в ход рассказы что в школе спарринги запрещены потому что школа настолько смертоносная что бьются они только насмерть и только когда другого выхода нет. Удобно.
Занимательно что с Ваших же слов, DDD это что-то само собой разумеющееся, которое само собой изобретается и все до этого сами доходят. Я позволю себе усомниться и поверить что все вокруг настолько идиоты что нужно написать сотни статей на эту тему и целые книги о том что Документ нужно называть Document в коде и продолжать это делать годами. Сдается мне вопрос тут не только в отделении и именовании.
Мне кажется вы маленько не туда смотрите, всетаки проблема которую решает DDD - помощь при разработке, когда разработчик не погружен глубоко в область, по идее вы должны бизнес процессы перевести в код и общаться в компании в контексте этих кодовых процесов.
Я никуда не смотрю, у меня простой вопрос - где примеры и доказательства того что это действительно упрощает разработку. И вроде б у нас деятельность практического - "Talk is cheap. Show me the code.". Но нет, все сводиться в словесную демагогию.
Я рассуждаю проще. Есть проблема и есть решения проблемы. Решение должно быть настолько простым и понятным насколько это возможно и не должно порождать еще больше вопросов, проблем и сложностей чем изначальная проблема. Думаю это логично, иначе какой смысл данного решения?
Что нужно разработке? Простой, понятный и эффективный механизм, доказавший свою целесообразность и эффективность.
Что лично я вижу. Вал статей про одно и тоже с околонулевой прикладной составляющей из года в год. Кучу теоретики. Отсутствие хоть каких то доказательств эффективности, кроме "нужно просто верить" и "на работе пишу и там триумф но показать не могу".
Что я вижу когда сталкиваюсь с реальными проектами где применяли философию DDD и "чистый код"? Тотальный оверинжиниринг простейших вещей. Абстракции ради абстракций. Высокий уровень привнесенной сложности. Куча костылей, потому что то что фантазировали не налезло на реальный мир.
Может быть мне конкретно не везет а может быть подход не так хорош а популярен из-за того что из него сделали микро-религию.
Наверное потому что это в какой-то степени как картина, DDD у всех одно (условно простые фигуры/примитивы из рисования) но результат у всех разный, который зависит от компетенции архитектора.
Да я не против разного резултата. Есть утверждение что - "DDD снижает сложность". Я хочу увидеть доказательства данного утверждения. Потому как часто бывает, снижение сложности на словах выливается в оверинжиниринг и реальное увеличение сложности на практике.
Причём если вы посмотрите на проект, вы не увидите снижения сложности.
Просто замечательно. Видимо, как говориться, нужно просто верить.
Для того, чтобы её увидеть, нужно взять два проекта: один в бардаке, второй после рефакторинга по DDD.
Вы не поверите, но если взять два проекта один в бардаке, второй после любого адекватного рефакторинга, то второй всегда будет в выигрыше. Это не отвечает на вопрос что даст DDD.
и каждый раз при прочтении очередной статьи возникает когнитивный диссонанс - а где собственно простой инструмент борьбы со сложностью? Почему пишут такое огромное количество статей, где практически никогда ничего не уходит дальше бесконечного теоретизирования? Почему хоть кто-то из DDDшников не может написать проект, который читатели могут посмотреть и ответить для себя: да оно работает или нет, оно приносит больше сложностей чем решает и нежизнеспособно?
Для борьбы со сложностью людям нужен простой и рабочий инструмент а не сотни теоретических статей и десятки книг, да еще и без подтверждения того что на практике это решить больше сложностей чем принесет.
Мне это дико напоминает ту же историю с чистым функциональным программированием. Вам обещают простой и надежный код, но для этого нужно изучить: монады, моноиды, все виды функторов, теорию категорий и прочее прочее прочее. При этом реальный проекты написанный с чистым функциональным подходом напоминают ад, т.к. заменяют одну сложность на другую. Но ведь смысл не заменять одну сложность другой.
Удивительно, что в 2025м до сих пор где-то проблемы с асинхронностью. В той же Scala еще в 2015м нормальный, но не асинхронный фреймворк еще надо было поискать. И примерно тогда же появились чисто асинхронные коннекторы к Postgres-MySQL. Плюс есть async/await макросы (библиотека).
Не очень понятно про что Вы. Если про C# то это некорректно. Высокоуровневая работа с асинхронностью пришла в C# в 2010 году с TPL а уже в 2012 в нем придумали новую концепцию async/await которая повлияла на большинство мейнстримных языков. Так что C# в этом плане пионер.
А вот что удивительно действительно, это то что такой популярный язык как Java затянул до 2023 года просто игнорируя эту проблему.
Таким образом, в Go получилось избавиться от разноцветных функций и при этом реализовать современный и эффективный механизм асинхронности.
Я бы заметил что при всех плюсах данного подхода - вышеупомянутого избавления от цветных функций, мой опыт показывает что обратная сторона - это неудобство работы с параллельными запросами и там где нужно задавать последовательности. Если в C# достаточно просто сделать то в Go это превращается в городьбу из каналов WaitGroups и так далее, раз за разом. Плюс, я до конца не уверен, хорошо это или плохо что я не знаю блокирующий вызов функции или нет. К примеру я вызываю функцию у которой под капотом системный вызов не сетевой природы и это стоит мне нового потока, а я бы хотел знать что функция будет создавать отдельный поток и грузить приложения.
Можно заметить общий механизм между Golang и Project Loom в JVM, который заключается в перехвате рантаймом блокирующих операций и выполнение их в неблокирующей манере. Если в Go это было реализовано изначально, то в JVM подобные масштабные изменения заняли 5 лет:
При всем тот что в Java худо бедно выпустили работу с асинхронностью аж в 2023 году по старой доброй традиции сделали это слегка неуклюже на мой взгляд. В том же Go достаточно ключевого слова go в Java это возня с разными видами потоков.
Уже после изобрели концепцию, что нужно кодить не качественно, а быстрее - под нее выпустили 100500 фреймворков с во столько же раз увеличившимся весом и требованиями. После чего наши программы стали работать не быстрее - пропорционально растущим согласно закону Мура железным мощностям, но зато типа труд разработчика экономился, а он дороже.
Юмор ситуации в том что после выпуска 100500 фреймворков скорость разработки только упала, вместо с качеством и производительностью приложения а стоимость разработки наоборот взлетела.
Нет, нет, и еще раз нет! Архитектура - это искусство выстраивания системы сейчас под требования, которые в моменте не предъявляются, не осознаются, и возможно даже не существуют. Проектирование системы под известные требования - это инженерия.
Когда архитектор проектирует новый ЖК он видимо делает это с расчетом что из него можно будет сделать в будущем аэродром? А если он просто проектирует ЖК в качестве ЖК, реализуя требования но вводя свое виденья по внешнего вида и конструктивных особенностей, он видимо и не архитектор чтоли?
Архитектор же из своего опыта и общей эрудиции - понимает что одинокий молодой человек не всегда будет одиноким и молодым. И поэтому сразу ("вотпрямщас") закладывает в конструкцию избыточность, определяя конюшню отдельным строением, и прокладывая к ней удобную дорожку.
А молодой человек будет платить за тут избыточность которую заботливый архитектор внес в стоимость? А может быть вообще молодой человек будет жить с семьей не там а здесь только отдыхать а Вы ему построите дом для всей семьи, зачем?
Пример плохой архитектуры - это трущобы какого-нибудь мумбая или сан-паоло. При любом изменении обстановки - они подлежат сносу (если не рухнут сами или сильный дождь не смоет). В противовес этому, примеры хорошей архитектуры - например, дворцовые комплексы, продолжают использоваться даже сейчас (хотя функцию "родового гнезда" или "цитадели знати" уже давно не выполняют).
Хотелось бы спросить, а Вы сами то живете во дворце? А если нет то почему? Может быть в мире существуют такие понятия как стоимость, сроки, доступность и возможности? И лучше построить трущобы здесь и сейчас, чтобы люди могли бы жить хоть где-то, чем расселить всех по дворцам через 1000 лет?
Вопрос привычки. Если взять того кто с функциональщины начинал, для него ООП также будет взрывом мозга.
Ну во-первых, ФП ФП рознь. Есть экстремальные вещи вроде чистого Haskell подобного ФП а есть умеренные вроде Clojure.
Во-вторых, в ООП такая же история. Сколько часто нужно нагородить классов, отнаследоваться, попереопределять, открыть закрыть чтобы написать тривиальную вещь на ООП языке.
Это правда. Но почему то все забывают что это привносит кучу проблем, потому что такое моделирование не налазит на реальную действительность: работа с базой превращается в костыль, повсюду маппинги ради маппингов, проблема с инвариантами объектов т.к. домена 18 полей а из интеграции пришло 3, что же делать, и прочее прочее прочее.
Может быть в теории. На практике это не очень работает и почти все пишут опираясь на анемичную модель.
По поводу полиморфизма - забавно. Во первых, не в ООП придумали полиморфизм. Во вторых в ООП используется не самый его продвинутый его вид. Так что в чем эти серьезные преимущества непонятно.
Опять таки, в теории да. На практике, лично на моем опыте, богатает модель просто нежизнеспособна. Оно все хорошо только и только пока нам хватает данных которые есть в объекте для валидаций и вычислений. Как только нам нужно что-то еще, все это превращается в тыкву и костыль. И судя по тому что подавляющее большинство используют анемичную модель, это не только мои выводы.
Тема - чем это удобнее чем одни раз написать функцию и вызывать ее пред тестами, не раскрыта.
Действительно, а зачем вообще какой-то логике придерживаться доказывая свое мнение как это делаете Вы? Мат модел не работает не важно, у нас своя математика, есть опровергающие примеры - нее таких единицы, у нас же в мире нет такого что чем талантливее и умнее человек тем часто он надменнее и высокомернее. Такого же не бывает в мире и не может быть чтобы сотруднику сходило с рук многое и его терпели только потому что он хороший или отличный специалист.
Это не психологическая ловушка, это - демагогия.
Я правильно понимаю что Линус Торвальдс создал больше проблем чем решил, в силу своего отвратительного проблемного характера? Джон Кармак, Стив Джобс, Ричард Столлман, продолжать можно долго. Про высокомерие и проблемность сотен ученых которые построили этот мир мне кажется и говорить не приходиться. Но у Вас логика прямая как палка - явные проблемы перекрывают любую пользу от человека .
А вот если не секрет, если заболеете Вы пойдете к какому врачу, к хамоватому, высокомерному проверенному мега-специалисту или к очень вежливому и приятному бездарю?
У Вас небольшие пробелы с мат моделированием. Если k - это условный показатель пользы от конкретного сотрудника то проблемный сотрудник это k-n, где n - это условный показатель вреда от такого сотрудника. Таким образом, польза k от такого сотрудника может быть как больше так и меньше 0. В то время как польза от бесполезного сотрудника всегда k = 0.
Программист который умеет хорошо писать код но не умеет общаться - проблемный.
Программист который умеет все на свете кроме того как писать код - бесполезный.
Выводы делайте сами. Конечно софт скилы имеют особую важность особенно от лидских позиций и выше. Но не нужно их настолько переоценивать. Есть гениальный программист с отвратительным характером и коммуникациями. Можем ли мы создать для него условия чтобы решить проблемы с коммуникациями и получать огромные выгоды от его хардскилов? Да может. С другой стороны если у нас есть программист(не тимлид) которого все любят и он умеет договариваться со всеми но абсолютно безнадежный в техническом плане. Что мы получим? Человека который будет нравиться всем но по факту делегировать все задачи кому-то другому при этом получая большую зп и премии от начальства.
В идеале может быть. В реальности чаще всего на это ни у кого нет времени.
Мне вот интересно это как? Работает человек с высоким техническим скилом делает задачи без ошибок а его увольняют за ошибки в коммуникации? Я лично про такое не слышал.
Скорей всего, 70% не тянут технически, при этом у них не хватает софт скилов чтобы это компенсировать. Это не доказывает что 30% увольняют из-за нехватки технических навыков а 70% из-за нехватки софтскилов.
В общем в статье вроде бы все правильно написано и идеальный разработчик для бизнеса это и технарь и рубаха парень.
Но все-таки основное занятие работаботчика - решать технические проблемы.И чем больше следуя современной моде, компании меняют приоритет в сторону софтскилов, тем ниже мы наблюдаем компетенции современных команд и качество современного продукта.
Ну, на самом деле нет. Kotlin - это язык который гораздо ближе к C# и Scala чем к Java.
У языка должна была быть главная киллерфича - Kotlin Multiplatform (KMP) один язык для решения большинства проблем: backend/frontend/mobile. KotlinJVM это только одна из частей языка.
Идея хорошая но проблема в том что JB не вывезли такую глобальную задачу. KotlinJS не взлетел и думаю не взлетит. KMM идея оказалась не самой удачной и по моему личному мнению проиграла флаттеру. KotlinNative вообще не понятно кому нужен, кроме как часть проекта KMM. По итогу, из всего этого зоопарка взлетел только Kotlin на Android, потому что там разрабы устали от работы на Java 7 ну и чуть чуть занял backend.
Почему так вышло? Потому что JB не смогли реализовать свои замыслы. Если бы на kotlin можно было писать и back и front и mobile это было бы преимуществом. Так это не взлетело в сухом остатке только KotlinJvm, где да, более удобный чем Java язык и даже более надежный. Но вот это "чуть более" не перевешивает неудобств по внедрению, поддержке, обучению и найму на дополнительный язык. Никому не нужно "чуть лучше".
Не совсем. Kotlin - это смесь Scala + C# с щепоткой Groovy. От Scala действительно много чего досталось, но брали адекватные части языка и не брали сложные и неадекватные. В Kotlin в отличии от Scala почти нет ФП и это осознанное решение разработчиков. Сами разработчики заявляли - полноценной поддержки ФП нет и не будет.
А в чем аргумент вида "как в Гугл"?
Мой мнение, Go взлетел благодаря фиче мега-хантинга. Это наверное самый простой язык для перехода. Когда компании поняли что могут пылесосить разные стеки и сделать из кандидатов гоферов вместо того чтобы искать чисто свой стек - Go пошел на взлет.
Т.е. был язык который дает неплохие характеристики(производительность/память,простота и многопоточка из коробки ) в купе с некромантией найма, вот и рецепт его успеха. Без некромантии скорей всего бы не взлетел, так как экосистемы не было как и разработчиков.
Другой отличный пример Kotlin. При всех плюсах взлетел только на Android и то потому что там всем уже надоело сидеть на 7 джаве. В других местах не очень взлетел так как по сути не привнес ничего кардинально нового и у языка действительно нет никакой киллер фичи. Ну точнее киллер фича была - стать универсальным языком для бэка, фронта, мобилок и т.д. Но JB такое просто не вывезли.
Да пожалуйста. Хоть 2 команды хоть 20 команд.
Есть такая вещь называется доказательная медицина. Это когда лечение выбирается на основании доказанного метода а не того что какой то человек на основе своего опыта и субъективного мнения считает что метод работает. Про инженерное дело я вообще молчу.
То что Вы пришли к каким то идеям это замечательно. Но если человек развивается, то через какое-то время есть определенный шанс что с опытом его мнение измениться. Так очень часто бывает. Более того, многие люди склонны к одержимости идеями и могут оказаться в их плену доказывая свою правоту ни смотря ни на что.
Именно поэтому, если нас интересует рабочая методика а не поклонение идеям, мы должны эти идеи активно критиковать.
Вместо этого что мы видим в области DDD? Бесчисленное количество теоретических статей и заявления об эффективности методики основанные исключительно на вере и субъективном восприятии. На любые просьбы хоть как то обосновать методику, находиться 100 и 1 причина, почему это невозможно сделать. Просто верьте на слово.
Как считаете это нормальный подход?
Браво. Ответ который мы заслужили. Зачем доказывать и показывать идеи, пусть лучше кому интересно идут лесом в FAANG и сами проверяют да и вообще это нельзя показать - это все в закрытых репозиториях, где исключительно профессиональные команды над этим работают, главное просто верить что все это работает. Инженерный подход 10 из 10.
PS мне это один в один напоминает подход школ восточных боевых искусств, которые на словах рассказываются про свою невероятную эффективность но при попытке вызвать на спарринг для практического эксперимента сразу идут в ход рассказы что в школе спарринги запрещены потому что школа настолько смертоносная что бьются они только насмерть и только когда другого выхода нет. Удобно.
Занимательно что с Ваших же слов, DDD это что-то само собой разумеющееся, которое само собой изобретается и все до этого сами доходят. Я позволю себе усомниться и поверить что все вокруг настолько идиоты что нужно написать сотни статей на эту тему и целые книги о том что Документ нужно называть Document в коде и продолжать это делать годами. Сдается мне вопрос тут не только в отделении и именовании.
Я никуда не смотрю, у меня простой вопрос - где примеры и доказательства того что это действительно упрощает разработку. И вроде б у нас деятельность практического - "
Talk is cheap. Show me the code.". Но нет, все сводиться в словесную демагогию.Я рассуждаю проще. Есть проблема и есть решения проблемы.
Решение должно быть настолько простым и понятным насколько это возможно и не должно порождать еще больше вопросов, проблем и сложностей чем изначальная проблема. Думаю это логично, иначе какой смысл данного решения?
Что нужно разработке? Простой, понятный и эффективный механизм, доказавший свою целесообразность и эффективность.
Что лично я вижу. Вал статей про одно и тоже с околонулевой прикладной составляющей из года в год. Кучу теоретики. Отсутствие хоть каких то доказательств эффективности, кроме "нужно просто верить" и "на работе пишу и там триумф но показать не могу".
Что я вижу когда сталкиваюсь с реальными проектами где применяли философию DDD и "чистый код"? Тотальный оверинжиниринг простейших вещей. Абстракции ради абстракций. Высокий уровень привнесенной сложности. Куча костылей, потому что то что фантазировали не налезло на реальный мир.
Может быть мне конкретно не везет а может быть подход не так хорош а популярен из-за того что из него сделали микро-религию.
Да я не против разного резултата. Есть утверждение что - "DDD снижает сложность". Я хочу увидеть доказательства данного утверждения. Потому как часто бывает, снижение сложности на словах выливается в оверинжиниринг и реальное увеличение сложности на практике.
Просто замечательно. Видимо, как говориться, нужно просто верить.
Вы не поверите, но если взять два проекта один в бардаке, второй после любого адекватного рефакторинга, то второй всегда будет в выигрыше. Это не отвечает на вопрос что даст DDD.
В статье говориться:
и каждый раз при прочтении очередной статьи возникает когнитивный диссонанс - а где собственно простой инструмент борьбы со сложностью? Почему пишут такое огромное количество статей, где практически никогда ничего не уходит дальше бесконечного теоретизирования? Почему хоть кто-то из DDDшников не может написать проект, который читатели могут посмотреть и ответить для себя: да оно работает или нет, оно приносит больше сложностей чем решает и нежизнеспособно?
Для борьбы со сложностью людям нужен простой и рабочий инструмент а не сотни теоретических статей и десятки книг, да еще и без подтверждения того что на практике это решить больше сложностей чем принесет.
Мне это дико напоминает ту же историю с чистым функциональным программированием. Вам обещают простой и надежный код, но для этого нужно изучить: монады, моноиды, все виды функторов, теорию категорий и прочее прочее прочее. При этом реальный проекты написанный с чистым функциональным подходом напоминают ад, т.к. заменяют одну сложность на другую. Но ведь смысл не заменять одну сложность другой.
Не очень понятно про что Вы. Если про C# то это некорректно. Высокоуровневая работа с асинхронностью пришла в C# в 2010 году с TPL а уже в 2012 в нем придумали новую концепцию async/await которая повлияла на большинство мейнстримных языков. Так что C# в этом плане пионер.
А вот что удивительно действительно, это то что такой популярный язык как Java затянул до 2023 года просто игнорируя эту проблему.
Спасибо за отличную статью.
Я бы заметил что при всех плюсах данного подхода - вышеупомянутого избавления от цветных функций, мой опыт показывает что обратная сторона - это неудобство работы с параллельными запросами и там где нужно задавать последовательности. Если в C# достаточно просто сделать то в Go это превращается в городьбу из каналов WaitGroups и так далее, раз за разом. Плюс, я до конца не уверен, хорошо это или плохо что я не знаю блокирующий вызов функции или нет. К примеру я вызываю функцию у которой под капотом системный вызов не сетевой природы и это стоит мне нового потока, а я бы хотел знать что функция будет создавать отдельный поток и грузить приложения.
При всем тот что в Java худо бедно выпустили работу с асинхронностью аж в 2023 году по старой доброй традиции сделали это слегка неуклюже на мой взгляд. В том же Go достаточно ключевого слова go в Java это возня с разными видами потоков.
Юмор ситуации в том что после выпуска 100500 фреймворков скорость разработки только упала, вместо с качеством и производительностью приложения а стоимость разработки наоборот взлетела.
Когда архитектор проектирует новый ЖК он видимо делает это с расчетом что из него можно будет сделать в будущем аэродром? А если он просто проектирует ЖК в качестве ЖК, реализуя требования но вводя свое виденья по внешнего вида и конструктивных особенностей, он видимо и не архитектор чтоли?
А молодой человек будет платить за тут избыточность которую заботливый архитектор внес в стоимость? А может быть вообще молодой человек будет жить с семьей не там а здесь только отдыхать а Вы ему построите дом для всей семьи, зачем?
Хотелось бы спросить, а Вы сами то живете во дворце? А если нет то почему? Может быть в мире существуют такие понятия как стоимость, сроки, доступность и возможности? И лучше построить трущобы здесь и сейчас, чтобы люди могли бы жить хоть где-то, чем расселить всех по дворцам через 1000 лет?
Как раз пример отвратительной "архитектуры".