Сами того не заметив, вы случайно притопили за противоположную точку зрения :)Потому что бесполезный сотрудник это меньшее зло, чем проблемный. Ноль предпочтительнее минуса. Это может быть неочевидно, но это так.
У Вас небольшие пробелы с мат моделированием. Если 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 лет?
Да, иначе выгорание. Но вы всегда можете пойти писать на фортране без использования фреймворков и всяких интересных и приятных штук.
Стоит только порадоваться тому что программисты прошлых поколений, не были такими изнеженными и не выгорали без развлечения себя сменой фреймворков а вместо этого написали софт на котором до сих пор держиться весь мир, в том числе на страшном фортране.
Как ни печально, но массового потребителя не волнует качество программ. Это относится не только к ПО, но и к другим сферам жизни.
Глупость полная. Не нужно путать "людям плевать" и "люди не осознают" или "у людей нет выбора".
Первое - квалификация. Оценка качества зависит от умение это качество видеть - факт. Значит ли это что большинству людей плевать на качество софта? Как ни странно - нет. Даже у людей, которые ничего не понимают в этом, дико бомбит когда что-то лагает или не работает. При этом чем выше техническое понимание тем больше бомбит. И тут следующая проблема.
Второе - а кого это волнует? Ну не нравиться тебе проложение - не пользуйся. Уйди к конкурентам - будет им урок. Да? Но что если у конкурентов такое же говно? Что толку от того что тебе что-то не нравится если не из чего выбирать?
Третье - то что в простонародье называется "говноедство". Для того чтобы иметь вкус и осознавать качество, нужно быть воспитанным на хороших образцах. Если человек в жизни не видел как оно должно работать нормально то ему это будет неведомо. И это проблема не столько софта но и: музыки, фильмов, одежды, еды техники. Компании вместо того чтобы делть что-то качественно, давно поняли что проще убедить людей в том что тот кусок куска которые они сделали - это норма.
В нормальном мире - программист пишет программу для пользователя и делает все чтобы пользователю было удобно ей пользоваться. В реальном мире - программист пишет программу для себя любимого, чтобы ему было интересно писать, изучать новые фреймворки и внедрять то с чем ему хочется поиграть и при этом не сильно напрягаться. Давным давно придумана куча отговорок в духе - производительность не важна, проще купить планку оперативки, нам нужны микросервисы потому что когда-нибудь мы станем гуглом и т.д. И эта логика сходиться с логикой компаний. Не нужно это оправдывать тем что пользователям якобы плевать. В нашем мире плевать в первую очередь именно на пользователей.
На самом деле все так, но сделано намеренно для лучшего звучания и как небольшая самоирония в виде отсылки к тем самым игровым "обзорам на" и "гайдам на".
Ну на самом деле есть, просто в контексте решения проблемы возвращаемого значения неопределенного размера. Решил что примеры уже были в первой статье, и не стал растягивать эту. Но если считаете что не хватает, не проблема, добавлю.
То есть претензия так же самая: если вы пишете обзор / гайд то нужно описать полный обзор, а не какие-то куски
В идеале да, но в реальности получаются большие статьи, которые читают не так чтобы много кто.
У Вас небольшие пробелы с мат моделированием. Если 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 лет?
Как раз пример отвратительной "архитектуры".
Стоит только порадоваться тому что программисты прошлых поколений, не были такими изнеженными и не выгорали без развлечения себя сменой фреймворков а вместо этого написали софт на котором до сих пор держиться весь мир, в том числе на страшном фортране.
Глупость полная. Не нужно путать "людям плевать" и "люди не осознают" или "у людей нет выбора".
Первое - квалификация. Оценка качества зависит от умение это качество видеть - факт. Значит ли это что большинству людей плевать на качество софта? Как ни странно - нет. Даже у людей, которые ничего не понимают в этом, дико бомбит когда что-то лагает или не работает. При этом чем выше техническое понимание тем больше бомбит. И тут следующая проблема.
Второе - а кого это волнует? Ну не нравиться тебе проложение - не пользуйся. Уйди к конкурентам - будет им урок. Да? Но что если у конкурентов такое же говно? Что толку от того что тебе что-то не нравится если не из чего выбирать?
Третье - то что в простонародье называется "говноедство". Для того чтобы иметь вкус и осознавать качество, нужно быть воспитанным на хороших образцах. Если человек в жизни
не видел как оно должно работать нормально то ему это будет неведомо. И это проблема не столько софта но и: музыки, фильмов, одежды, еды техники. Компании вместо того чтобы делть что-то качественно, давно поняли что проще убедить людей в том что тот кусок куска которые они сделали - это норма.
В нормальном мире - программист пишет программу для пользователя и делает все чтобы пользователю было удобно ей пользоваться. В реальном мире - программист пишет программу для себя любимого, чтобы ему было интересно писать, изучать новые фреймворки и внедрять то с чем ему хочется поиграть и при этом не сильно напрягаться. Давным давно придумана куча отговорок в духе - производительность не важна, проще купить планку оперативки, нам нужны микросервисы потому что когда-нибудь мы станем гуглом и т.д. И эта логика сходиться с логикой компаний. Не нужно это оправдывать тем что пользователям якобы плевать. В нашем мире плевать в первую очередь именно на пользователей.
На самом деле все так, но сделано намеренно для лучшего звучания и как небольшая самоирония в виде отсылки к тем самым игровым "обзорам на" и "гайдам на".
Ну на самом деле есть, просто в контексте решения проблемы возвращаемого значения неопределенного размера. Решил что примеры уже были в первой статье, и не стал растягивать эту. Но если считаете что не хватает, не проблема, добавлю.
В идеале да, но в реальности получаются большие статьи, которые читают не так чтобы много кто.