Алгебраическая структура это не «факт», это множество и отношения между элементами этого множества. Отношения важны потому, что позволяют, в частности, судить о внутреннем устройстве объектов множества. Например, если мы построим изоморфизм чего-то в конечное поле (скажем Z/7), то у элементов этого «чего-то» можно найти факторизацию (разложение) на простые множители.
Пока я вижу у вас тезисы о том, что есть биекция между функциями определенных сигнатур, а также о том, что нужно уметь абстрагироваться от деталей. Вывод про ООП несостоятелен хотя бы потому, что определения, что такое ООП нет. Вы ищете «гибкости», но не определяете ее строго. В самом деле «потеря желанной гибкости» выражается в уменьшени какой-то метрики или норма вектора «гибкости» уменьшается, может ряды какие-то сходятся медленнее или ещё что-то?
Здорово, что вы поднимаете эти вопросы, но хотелось бы видеть больше строгости в изложении.
Изоморфизм сохраняет алгебраическую структуру, не ясно какую структуру сохраняют ваши примеры. Судя по всему — никакую, потому что в первом же примере сравнивается бинарная операция сложения и унарная операция отображающая int -> func<int,int>.
Как-то слабовато. Предложенные критерии разбиения на user story работают только для типичных crud и ecommerce. Попробуйте применить это для CAD, игр, научного или системного софта.
Как пользователь, я хочу оплатить заказ пластиковой картой
Откуда 30 часов?
А если требование «Как пользователь, я хочу оплатить заказ криптовалютой SuperPuper» SuperPuper версии 0.0.1 вышла вчера, документации нет, но разработчики утверждают что «SuperPupper is the most advanced and stable crypto currency ever. You can integrate SuperPupper with your website in under 5 minutes!» Сколько поставим часов на реализацию, 5 минут?
Однажды, на летних каникулах, залип в JRPG, в которой была куча диалогов и интересная история. Играл и переводил с словарём диалоги пол лета. К концу лета читал простые английские тексты свободно и без словаря. Дальше техническая документация по Delphi шла без проблем и еще больше прокачивала лексику. На 1-2 курсе уже мог свободно переписываться с иностранцами в интернете, нашёл себе таким образом первую работу на Elance. Через несколько лет, уже на upwork, искал заказчиков и прокачал уже разговорный. От свободного чтения, до уверенного говорения, при наличии тех с кем говорить, проходит буквально пара месяцев.
Грамматику никогда не учил отдельно, только то, что в школе давали. Правда английский у нас был с 1 класса. Вся грамматика набралась из чтения. Сейчас иногда заглядываю в учебники, но уже из желания быть неотличимым от native speaker в тексте и речи.
Из того, с чем разбираюсь или использую прямо сейчас:
— Стохастические дифуры — разработка стратегий для market making.
— Тер. вер и статистика — сбор данных о производительности, оценка производительности, оценка и разработка торговых стратегий.
— Много всякого Computer Science — проектирование ПО, разработка и оценка алгоритмов и структур данных,.
— Абстрактная и линейная алгебра — мои собственные исследования в области проектирования ПО.
Матан для этих областей служит базой, сам по себе не используется.
Математика нужна для решения любой реальной проблемы, для изобретения новых вещей. Хотите изобрести быстрый поиск, масштабируемую бд, прибыльную торговую стратегию, оптимальный расчёт кредитоспособности клиента и т.д. — применяете математику и довольно сложную надо сказать, далеко за пределами вузовского курса. Чтобы сделать очередную учетную систему математика не нужна.
Математика это ещё и язык, на котором люди вынуждены общаться, как только речь заходит о вещах, выходящих за пределы чувственного восприятия. Без него остаётся только применять аналогии и надеяться, что вас поймут правильно. Описать и передать сложные идеи так не выйдет. Нужно будет ждать пока кто-то все опишет формулой, затем в обществе установится определенная интерпретация и затем уже вы сможете ссылаться на сложные вещи с помощью привычных слов нормального языка. Процесс этот занимает десятилетия.
Если математика воспринимается как язык и метод исследования мира, то вместе с ней идёт и умение точно сформулировать свою мысль, умение исследовать проблему в мельчайших деталях. Если же смотреть на неё как на пачку теорем, то толку не будет никакого.
Математика программисту не нужна, она нужна человеку-разумному для исследования и решения сложных проблем. В вузах математику преподают очень плохо, также плохо как и программирование. Нормальных преподавателей почти нет, большинство нормальных предпочитают не работать за нищенскую вузовскую зп.
Пример из практики — многопоточный, неблокирующий отсортированный ассоциативный массив был сделан букавально несколько лет назад. До этого подобной структуры данных просто не существовало. Это больше 2000 строк на Scala, сейчас идёт в JDK под именем ConcurrentSkipList. Невозможно разработать такую вещь не доказав сначала ее свойства и корректность. Bubble sort ещё можно на коленке придумать и реализовать корректно, но такую штуку уже не выйдет, она слишком большая и сложная.
Есть набор систем O={O1,...,On}. Есть уже заданный алгоритм А. Алгоритм принимает Ok и дает результат Rk. Так же у вас есть результат R — тот к которому мы стремимся.
Задача — найти такое Ok, которое при выполнении на нем A, будет давать Rk, такое что R принадлежит Rk, и при этом будет иметь наименьшую сложность.
Извините, но это уже похоже на полную кашу в голове. Что такое сложность Rk или Ok? Набор O дан свыше или мы можем его вычислить? Как его вычислить? Если набор дан, то кто гарантирует, что в нем есть Ok, на котором достигается минимум сложности? Если набор О дан, то можем ли мы показать, что он полный, то есть никаких других интересных Ok быть не может?
Вы знаете, что у вас 3 коллеги, они будут читать этот код. Еще вы знаете, что возможно у вас будет редизайн через полгода и вы оцениваете его вероятность в 60%.
Разговоры о редизайне предполагают, что оптимизируется сложность изменения в том числе. В примере с простыми числами под сложностью дополнительно понимается сложность алгоритмическая (один алгоритм быстрее) и сложность для понимания (выбор из массива проще, чем алгоритм).
Это, кхм… Варианты действий с вашим кодом. Я пока не знаю их алгоритмы (А), и моя задача — их найти.
В определении выше A полагался единственным, потому что A: Ok -> Rk. Но если их много, то говорить о том, что Ok отображается в Rk с помощью A уже нельзя. Далее — можете ли вы показать, что у всех людей одинаковый A?
Моя мысль — если мы узнаем алгоритм действий «прочитать код» и «внести изменения в код» — мы сможем ответить на этот вопрос.
Вы можете найти какой-то алгоритм А или даже множество алгоритмов А, Но вы не можете в общем случае знать минимальный ли он/они, оптимальный ли он/они. На самом деле, теорема Райса говорит, что в общем случае вы вообще никаких нетривиальных свойств A как функции (оптимальность, конечность, гладкость, непрерывность и т.д.) по его тексту вычислить не можете.
Предлагаю вам бросить написание статей и начать доказывать теоремы. Вы исследуете очень сложные проблемы, говорить о которых можно только на языке математики.
Заниматься творчеством делая очередную систему учёта невозможно, если только вы не придумали новый подход к учету. Придумать его тяжело, потому что миллион людей уже об этом думали. А раз так, то делая учетную систему вы выполняете функции ремесленника, а не творца. Язык программирования тут ни при чем, просто посмотрите на другие задачи.
Проблема с «другими» задачами в том, что прочитав книгу “Go за 21 день» их не решить. Надо много знать за пределами программирования. Например, знать какой-то бизнес, или разбираться в математике и решать с помощью своих знаний задачи. Знание Go и очередного мега фреймворка никаких задач не решает и если это все, что вы знаете, то бизнес поставит вас решать типовые задачи, не требующие творчества и спец. знаний.
Непонятно сложность чего выше — алгоритма вычисляющего простое число или алгоритма выбирающего простое число из массива?
>А можете подсказать где это в тексте? Я не вижу такого. Я писал про действия, а не про системы…
Тут вы правы, речь везде идет про действия. Не уверен, что это меняет суть рассуждений. Каждая система преобразует вход в выход, а потому ей можно сопоставить единственную функцию/действие. Таким образом, с каждой абстрактной функцией/действием можно сопоставить множество систем, а любые выводы о действиях справедливы и для, скажу осторожно, соответствующих классов эквивалентностей систем.
Оцениваем не сложность объекта O как такового, а сложность достижения заданного результата R, посредством действия с объектом O. Считаем, что результата R можно добиться путем выполнения элементарных действий с объектом O. Определяем сложность R как сумму сложностей элементарных действий с объектом O.
Вы же говорите примерно об этом, верно?
Утверждение — определение минимального набора действий с объектом O для достижения результата R эквивалентно вычислению колмогоровской сложности. То есть является невычислимой функцией.
Объект O и его интерфейс — например JVM и язык программирования Java, результат R — реализация программы согласно требованиям заказчика. Для вычисления сложности нужно найти минимальный набор действий с языком R. Чем не колмогоровская сложность? Добавления исполнителя ничего, принципиально, не меняет.
>Я смотрел на колмогоровскую сложность и на сообщение минимальной длины. Но когда интерпретатором сообщения является мозг, то минимизация «записи» с сохранением количества информации — не работает.
Все работает, достаточно наложить ограничения на рассматриваемые программы. Положим будем писать их на конкретном языке, дополнительно потребуем, чтобы каждый термин в программе был описан в терминах, понятных человеку и т.д. и т.п. Не важно сколько еще ограничений мы наложим, смысл остается один — сложность нельзя складывать.
На пальцах — положим есть модель человеческого мозга, которая для заданной программы выдает число — сложность этой программы, как она будет восприниматься среднестатистическим программистом. Пусть эта модель дала нам оценку программы А — 10 — сложная программа и оценку программы Б — 10, тоже очень сложная программа. Но что если программа Б объясняет многое из программы А и наоборот? Тогда можно ожидать, что оценка сложности объединенной программы будет сильно меньше 10, но не 10 + 10.
Есть такая штука как колмогоровская сложность и, кажется, именно она наиболее четко описывает сложность системы, в контексте разработки ПО. Считать, что любую систему можно разложить на элементарные системы сложности 1 единственным способом не верно. Считать, что сложность элементарных систем можно складывать, тоже не верно.
Поясню на примере. Смотрим на фрактал и находим в нем бесконечное число элементов, но сам фрактал описывается компактной формулой. На практике инженеры-конструкторы для своих задачи такую компактную формулу не всегда могут найти. Знание предметной области равно знанию наиболее часто встречающихся формул/паттернов/подходов которые сложно обнаружить.
Одна система проще другой если обе дают одинаковые выходы при одинаковых входах и система описывается меньшим числом символов. На практике ещё важно, чтобы система была робастна относительно изменения требований. Если нас попросят генерировать другой выход или добавить входных параметров, то не хочется вносить много изменений. Тот кто придумает как это сделать в общем случае поставит точку в вопросе проектирования ПО.
если логика задачи требует повторных попыток?
То они были бы и без микросервиса.
Не были бы. В монолите была бы вызвана функция и все. В микроскопическое надо учитывать, что ваш сервис может рестартовать. В каждом случае прийдется решать отдельно как делать повторные вызовы: сколько ждать, сколько раз повторять, нужно ли вообще что-то делать если это ошибка DNS и т.п.
С чего бы это? Когда тестим монолит тестим сразу все, а если протестировали сервис, то нет гарантий, что он нормально интегрирован с окружением. Тестировать сервис сложнее, хоты бы потому, что окружение сложнее.
Почему же не готовы? В Java, .NET, С и C++ и в других языках готовы, и прямо говорят, «если вы меняете приватные переменные, то идите лесом». В JS сейчас чуть проще, чем в перечисленных языках поменять приватные переменные, но что с того? Авторы говорят обычно даже более сильную вещь — «используете недокументированные методы и функции — идите лесом». В вашем примере "_x" де факто приватная переменная, «де-юре» недокументированная функция. В любом случае юзер идет лесом и это ожидаемо.
Это все попытка выдать желаемое за действительное. Если все хорошо сделано, то пользователю и не нужно лезть в кишки, а если все плохо, то любой значимый рефакторинг сломает контракт. И затем, найдите мне программиста на JS, который не в курсе, что если меняешь/читаешь что-то, что начинается с «_», то можно огрести? Все уже и так все знают, в от идиотов защититься невозможно.
Самые частые проблемы с контрактом выглядят не «переименовало приватную переменную», а как «был метод O(1), стал O(n^2)”, не было исключения, теперь есть, раньше можно было метод дергать до «onload”, а теперь нельзя и т.п. Если сообщество обеспокоено контрактом, то нужно говорить не о private, а о полноценной ala Eifell системе. Наличие hard private автору библиотеки даст ложное спокойствие, а юзеру даст вполне конкретный геморрой. Я не вижу тут реальной выгоды ни для авторов ни для юзеров.
А зачем вообще убиваться по поводу доступности приватных полей извне? В большинстве языков это сделать можно и никто не жалуется. Безопасность на такой сомнительной вещи строить не получится. Так зачем усложнять язык? По мне текущего де-факто стандарта «this._x” более чем достаточно.
Возможность залезть в кишки объекта это большое благо на самом деле. Например чтобы починить баг в библиотеке, бывает в тестах сильно проще проверить приватную переменную чем городить что-то вокруг и т.п. Я не призываю лезть в внутрь всех объектов, но эта фича имеет своё применение.
А инкапсуляция она от private не сильно зависит. У вас либо понятный поток данных и управления в системе или каша. А в каше существенная часть приватного состояния все равно будет косвенно видно в деталях контракта, большом количестве методов, сложном состоянии, о котором надо знать клиентам и т.п.
Основная проблема в том, что на практике реализуется смесь из этих двух сценариев:
а) У вас есть девопс команда, которая общается с k8s и крутит его по запросам разработки и бизнеса. Тогда теряется гибкость, возрастает количество коммуникаций, скорость работы снижается. Теперь кластер надо крутить силами девопс, а это значит ставить таски, принимать работу.
б) Ваша команда разработки должна выучить helm, k8s и docker. А это несколько недель на каждого разработчика.
На моей практике организовать работу нескольких команд, которые в итоге выдают общие библиотеки, с semver, обратной совместимостью и прочим плюшками проще, чем решение инфраструктурных проблем с микросервисами. То есть, я рекомендую с библиотек начинать. Если не получается делать нормальные библиотеки, то о нормальных и стабильных интерфейсах между сервисами можно забыть.
Обожаю эти комментарии в стиле «вы просто не умеете их готовить» :) Раз говорим про роли, то давайте критерий (желательно универсальный), по которому эти роли выделять.
Пока я вижу у вас тезисы о том, что есть биекция между функциями определенных сигнатур, а также о том, что нужно уметь абстрагироваться от деталей. Вывод про ООП несостоятелен хотя бы потому, что определения, что такое ООП нет. Вы ищете «гибкости», но не определяете ее строго. В самом деле «потеря желанной гибкости» выражается в уменьшени какой-то метрики или норма вектора «гибкости» уменьшается, может ряды какие-то сходятся медленнее или ещё что-то?
Здорово, что вы поднимаете эти вопросы, но хотелось бы видеть больше строгости в изложении.
Изоморфизм сохраняет алгебраическую структуру, не ясно какую структуру сохраняют ваши примеры. Судя по всему — никакую, потому что в первом же примере сравнивается бинарная операция сложения и унарная операция отображающая int -> func<int,int>.
Как-то слабовато. Предложенные критерии разбиения на user story работают только для типичных crud и ecommerce. Попробуйте применить это для CAD, игр, научного или системного софта.
Откуда 30 часов?
А если требование «Как пользователь, я хочу оплатить заказ криптовалютой SuperPuper» SuperPuper версии 0.0.1 вышла вчера, документации нет, но разработчики утверждают что «SuperPupper is the most advanced and stable crypto currency ever. You can integrate SuperPupper with your website in under 5 minutes!» Сколько поставим часов на реализацию, 5 минут?
Однажды, на летних каникулах, залип в JRPG, в которой была куча диалогов и интересная история. Играл и переводил с словарём диалоги пол лета. К концу лета читал простые английские тексты свободно и без словаря. Дальше техническая документация по Delphi шла без проблем и еще больше прокачивала лексику. На 1-2 курсе уже мог свободно переписываться с иностранцами в интернете, нашёл себе таким образом первую работу на Elance. Через несколько лет, уже на upwork, искал заказчиков и прокачал уже разговорный. От свободного чтения, до уверенного говорения, при наличии тех с кем говорить, проходит буквально пара месяцев.
Грамматику никогда не учил отдельно, только то, что в школе давали. Правда английский у нас был с 1 класса. Вся грамматика набралась из чтения. Сейчас иногда заглядываю в учебники, но уже из желания быть неотличимым от native speaker в тексте и речи.
— Стохастические дифуры — разработка стратегий для market making.
— Тер. вер и статистика — сбор данных о производительности, оценка производительности, оценка и разработка торговых стратегий.
— Много всякого Computer Science — проектирование ПО, разработка и оценка алгоритмов и структур данных,.
— Абстрактная и линейная алгебра — мои собственные исследования в области проектирования ПО.
Матан для этих областей служит базой, сам по себе не используется.
Математика нужна для решения любой реальной проблемы, для изобретения новых вещей. Хотите изобрести быстрый поиск, масштабируемую бд, прибыльную торговую стратегию, оптимальный расчёт кредитоспособности клиента и т.д. — применяете математику и довольно сложную надо сказать, далеко за пределами вузовского курса. Чтобы сделать очередную учетную систему математика не нужна.
Математика это ещё и язык, на котором люди вынуждены общаться, как только речь заходит о вещах, выходящих за пределы чувственного восприятия. Без него остаётся только применять аналогии и надеяться, что вас поймут правильно. Описать и передать сложные идеи так не выйдет. Нужно будет ждать пока кто-то все опишет формулой, затем в обществе установится определенная интерпретация и затем уже вы сможете ссылаться на сложные вещи с помощью привычных слов нормального языка. Процесс этот занимает десятилетия.
Если математика воспринимается как язык и метод исследования мира, то вместе с ней идёт и умение точно сформулировать свою мысль, умение исследовать проблему в мельчайших деталях. Если же смотреть на неё как на пачку теорем, то толку не будет никакого.
Математика программисту не нужна, она нужна человеку-разумному для исследования и решения сложных проблем. В вузах математику преподают очень плохо, также плохо как и программирование. Нормальных преподавателей почти нет, большинство нормальных предпочитают не работать за нищенскую вузовскую зп.
Пример из практики — многопоточный, неблокирующий отсортированный ассоциативный массив был сделан букавально несколько лет назад. До этого подобной структуры данных просто не существовало. Это больше 2000 строк на Scala, сейчас идёт в JDK под именем ConcurrentSkipList. Невозможно разработать такую вещь не доказав сначала ее свойства и корректность. Bubble sort ещё можно на коленке придумать и реализовать корректно, но такую штуку уже не выйдет, она слишком большая и сложная.
Извините, но это уже похоже на полную кашу в голове. Что такое сложность Rk или Ok? Набор O дан свыше или мы можем его вычислить? Как его вычислить? Если набор дан, то кто гарантирует, что в нем есть Ok, на котором достигается минимум сложности? Если набор О дан, то можем ли мы показать, что он полный, то есть никаких других интересных Ok быть не может?
Разговоры о редизайне предполагают, что оптимизируется сложность изменения в том числе. В примере с простыми числами под сложностью дополнительно понимается сложность алгоритмическая (один алгоритм быстрее) и сложность для понимания (выбор из массива проще, чем алгоритм).
В определении выше A полагался единственным, потому что A: Ok -> Rk. Но если их много, то говорить о том, что Ok отображается в Rk с помощью A уже нельзя. Далее — можете ли вы показать, что у всех людей одинаковый A?
Вы можете найти какой-то алгоритм А или даже множество алгоритмов А, Но вы не можете в общем случае знать минимальный ли он/они, оптимальный ли он/они. На самом деле, теорема Райса говорит, что в общем случае вы вообще никаких нетривиальных свойств A как функции (оптимальность, конечность, гладкость, непрерывность и т.д.) по его тексту вычислить не можете.
Предлагаю вам бросить написание статей и начать доказывать теоремы. Вы исследуете очень сложные проблемы, говорить о которых можно только на языке математики.
Заниматься творчеством делая очередную систему учёта невозможно, если только вы не придумали новый подход к учету. Придумать его тяжело, потому что миллион людей уже об этом думали. А раз так, то делая учетную систему вы выполняете функции ремесленника, а не творца. Язык программирования тут ни при чем, просто посмотрите на другие задачи.
Проблема с «другими» задачами в том, что прочитав книгу “Go за 21 день» их не решить. Надо много знать за пределами программирования. Например, знать какой-то бизнес, или разбираться в математике и решать с помощью своих знаний задачи. Знание Go и очередного мега фреймворка никаких задач не решает и если это все, что вы знаете, то бизнес поставит вас решать типовые задачи, не требующие творчества и спец. знаний.
>А можете подсказать где это в тексте? Я не вижу такого. Я писал про действия, а не про системы…
Тут вы правы, речь везде идет про действия. Не уверен, что это меняет суть рассуждений. Каждая система преобразует вход в выход, а потому ей можно сопоставить единственную функцию/действие. Таким образом, с каждой абстрактной функцией/действием можно сопоставить множество систем, а любые выводы о действиях справедливы и для, скажу осторожно, соответствующих классов эквивалентностей систем.
Вы же говорите примерно об этом, верно?
Утверждение — определение минимального набора действий с объектом O для достижения результата R эквивалентно вычислению колмогоровской сложности. То есть является невычислимой функцией.
Объект O и его интерфейс — например JVM и язык программирования Java, результат R — реализация программы согласно требованиям заказчика. Для вычисления сложности нужно найти минимальный набор действий с языком R. Чем не колмогоровская сложность? Добавления исполнителя ничего, принципиально, не меняет.
Все работает, достаточно наложить ограничения на рассматриваемые программы. Положим будем писать их на конкретном языке, дополнительно потребуем, чтобы каждый термин в программе был описан в терминах, понятных человеку и т.д. и т.п. Не важно сколько еще ограничений мы наложим, смысл остается один — сложность нельзя складывать.
На пальцах — положим есть модель человеческого мозга, которая для заданной программы выдает число — сложность этой программы, как она будет восприниматься среднестатистическим программистом. Пусть эта модель дала нам оценку программы А — 10 — сложная программа и оценку программы Б — 10, тоже очень сложная программа. Но что если программа Б объясняет многое из программы А и наоборот? Тогда можно ожидать, что оценка сложности объединенной программы будет сильно меньше 10, но не 10 + 10.
Есть такая штука как колмогоровская сложность и, кажется, именно она наиболее четко описывает сложность системы, в контексте разработки ПО. Считать, что любую систему можно разложить на элементарные системы сложности 1 единственным способом не верно. Считать, что сложность элементарных систем можно складывать, тоже не верно.
Поясню на примере. Смотрим на фрактал и находим в нем бесконечное число элементов, но сам фрактал описывается компактной формулой. На практике инженеры-конструкторы для своих задачи такую компактную формулу не всегда могут найти. Знание предметной области равно знанию наиболее часто встречающихся формул/паттернов/подходов которые сложно обнаружить.
Одна система проще другой если обе дают одинаковые выходы при одинаковых входах и система описывается меньшим числом символов. На практике ещё важно, чтобы система была робастна относительно изменения требований. Если нас попросят генерировать другой выход или добавить входных параметров, то не хочется вносить много изменений. Тот кто придумает как это сделать в общем случае поставит точку в вопросе проектирования ПО.
Не были бы. В монолите была бы вызвана функция и все. В микроскопическое надо учитывать, что ваш сервис может рестартовать. В каждом случае прийдется решать отдельно как делать повторные вызовы: сколько ждать, сколько раз повторять, нужно ли вообще что-то делать если это ошибка DNS и т.п.
Это все попытка выдать желаемое за действительное. Если все хорошо сделано, то пользователю и не нужно лезть в кишки, а если все плохо, то любой значимый рефакторинг сломает контракт. И затем, найдите мне программиста на JS, который не в курсе, что если меняешь/читаешь что-то, что начинается с «_», то можно огрести? Все уже и так все знают, в от идиотов защититься невозможно.
Самые частые проблемы с контрактом выглядят не «переименовало приватную переменную», а как «был метод O(1), стал O(n^2)”, не было исключения, теперь есть, раньше можно было метод дергать до «onload”, а теперь нельзя и т.п. Если сообщество обеспокоено контрактом, то нужно говорить не о private, а о полноценной ala Eifell системе. Наличие hard private автору библиотеки даст ложное спокойствие, а юзеру даст вполне конкретный геморрой. Я не вижу тут реальной выгоды ни для авторов ни для юзеров.
А зачем вообще убиваться по поводу доступности приватных полей извне? В большинстве языков это сделать можно и никто не жалуется. Безопасность на такой сомнительной вещи строить не получится. Так зачем усложнять язык? По мне текущего де-факто стандарта «this._x” более чем достаточно.
Возможность залезть в кишки объекта это большое благо на самом деле. Например чтобы починить баг в библиотеке, бывает в тестах сильно проще проверить приватную переменную чем городить что-то вокруг и т.п. Я не призываю лезть в внутрь всех объектов, но эта фича имеет своё применение.
А инкапсуляция она от private не сильно зависит. У вас либо понятный поток данных и управления в системе или каша. А в каше существенная часть приватного состояния все равно будет косвенно видно в деталях контракта, большом количестве методов, сложном состоянии, о котором надо знать клиентам и т.п.
а) У вас есть девопс команда, которая общается с k8s и крутит его по запросам разработки и бизнеса. Тогда теряется гибкость, возрастает количество коммуникаций, скорость работы снижается. Теперь кластер надо крутить силами девопс, а это значит ставить таски, принимать работу.
б) Ваша команда разработки должна выучить helm, k8s и docker. А это несколько недель на каждого разработчика.
В итоге k8s это модно, гибко и очень дорого.