хотите раскрою секрет? просто все адепты микросервисов слепо считают антипаттерн "связи многие ко многим" автоматически приравненным к монолиту.
впрочем это не мешает им следующим шагом рассуждать о том, "как плохо делать распределенный/микросервисный монолит", в котором микросервисы организованы так, что сбой/изменение одного модуля, приводит к сбою / необходимости обновления всей системы.
вот не складывается у них, не складывается, что не в микросервисах дело, не в способе сборки и упаковки компонент системы...
тупят, как Алиса Яндексовская в той истории про "самую длинную реку в мире".
даже в 1с поддерживается альтернативное английское написание ключевых слов.
если это учебный язык для школьников - то им нужен не js с его альтернативно-одаренной псевдо параллельностью, которую и взрослым то не объяснить нормально. и кучей других приколов на тему " '1'+1 ' и " '1'-1 "
если переводить, то переводить Паскаль или Бейсик. а так - это мертворожденная идея, которая не прижилась ни разу на протяжении более чем 40 лет. начиная с советских лого-подобных черепашек.
человеку, который не знает английского - в it делать нечего. абсолютно и совсем. и даже в 1С - без английского и внешних языков ты будешь узконаправленный ограниченным кодером.
это, конечно, если эта статья не стёб и провокация.
не существует монолита и микросервисов. как "архитектур".
есть компонентно-ориентированная архитектура и антипаттерн "связи все ко всем" .
непонимание компонентно-ориентированной архитектуры порождает "микросервисный монолит", в котором вроде всё разнесено на сотни хостов, всё по книгам, но что-то поменять сыкотно, потому, что не знаешь где какая проблема вылезет. потому что связи между элементами системы запутаны и трудно прослеживаемы.
а понимание компонентно-ориентированной архитектуры позволяет оставаясь даже в концепции "монолитной сборки и дистрибуции" достигать всех "преимуществ приписываемых якобы-только микросервисам" - распределенные независимые команды, отказоустойчивость, незаметное развертывание новых фич и пр.
а мы используем eclipse. потому что мультипроектный комбайн. независимые компоненты можно собирать из исходников и править при необходимости, тут и сейчас, вместе с основным проектом, без всяких там мавенов и прочего. и несколько проектов в одной ванночке. крайне удобно проводить рефакторинг, буквально в полуавтоматическом режиме оно меняет и в компоненте, и в трёх проектах от неё зависящих. и не важно что все они потом собираются в независимые jar/war , хранятся в разных репозиториях (включая "часть в svn часть в git").
8-Р
а если серьезно, нетбинс ещё живы? ) пока тут люди спорят за эклипс против идеи, они решили выступить третьей стороной?)) у меня в сознании это примерно на уровне "vsc тоже умеет компилить джаву", но никто кроме студентов это не делает.
киньте в меня, пожалуйста, ссылку какой на более-менее внятный обзор возможностей, включая мультипроектность?
пысы: ещё бы поддержку мавена, свн, ломбока, апач велосити, и до кучи спринга (для тех кто с курсов и не умеет никуда больше), ямл (и пусть те кто придумал использовать невидимые символы не как разделители пропехнутся)....
Зачем платить команде из десяти разработчиков если их можно было бы заменить двумя "вайб кодерами"?
Дада. Вайбкодеры — новые «индусы». #йапиарюсь ;) и развитие сиуации, судя по всему, будет аналогичное. За той разницей, что "индусский код" не уничтожил локальные команды, а эти архаровцы (эффективные менеджеры), не смыслящие в отрасти, могут.
Раньше суперкомпьютер проигрывал в шахматы человеческому чемпиону, потому что у человека было то, что у компьютера не могло быть по определению - интуиция. Человек чувствует, что вот этот ход сейчас лучший, но объяснить почему так - в данный момент не может и делает лучший ход интуитивно.
Но постепенно суперкомпьютер становился все производительнее и производительнее, и в какой-то момент просто стал просчитывать ВСЕ ходы на недоступную человеческому мозгу глубину. И человек проиграл.
Вы используете дешевые спекуляции, и, кажется мне, вы рассчитываете на читателя-неофита, не знакомого с "проблемой алгоритмизации Го" )) игра такая, древне-китайская. "Хит продаж последних 5 тысяч лет".
Суть проблемы в том, что игра Го - до сих пор не алгоритмизирована. Нет алгоритма который бы помог вам рассчитать какой делать ход дальше в Го - нет. Шахматы, для сравнения, алгоритмизировали ещё около 60-х годов прошлого века, и дальше был вопрос только наращивания вычислительных мощностей. Шахматные компьютеры были ещё в СССР. С го-же ситуация кардинально другая. Есть нейросети, которые выигрывают, но они выигрывают не алгоритмами.
Во первых, в Го комбинаторика такая, что до сих пор ни один "кластер" не может это просчитать на всю глубину. Число комбинаций на доске 19*19 сравнимо с числом атомов во вселенной. В шахматах-же, на этом фоне - комбинаторика очень маленькая.
Во вторых, в Го нет "ценности хода". В отличии от шахмат, где слон равен трем пешкам (условно) и ситуация на доске очень легко оценивается численными методами.
В Го очень часто невозможно "оценить количественно" ценность конкретного хода. Ценность имеет "конструкция", комбинация камней на доске, "форма" из трех-четырех камней. Причем относительную - потому что важна ситуация на доске. И получится у тебя выстроить комбинацию или нет - ещё вопрос - противник то тоже строит "конструкции". То что ты строил, перестает работать и становится бесполезным (в плане достижения цели партии), потому что противник сделал "не то" и влияние окружающих камней теперь другое. И сработал или нет конкретный ход - окончательно станет понятно только в конце партии. Отсюда - перебирай ты варианты, не перебирай - ценность этого хода ты не выяснишь - она вполне себе статистически будет одинаковая - в половине исходов ты проиграл (это не говоря о проблеме перебора всех вариантов).
Но натренированная на всем массиве игр и самостоятельных играх ИИ (та же альфаГо кажется) сегодня выигрывает в Го. Выигрывает не перебором или интуицией, а статистически настроенными весами в связах "нейронов". Она генерирует наиболее вероятные ходы из тех партий, которые похожи на текущую ситуацию и были выиграны. Вероятные ходы - на основании "впитывания" миллионов партий - накопленных за последние несколько тысячи лет людьми - в Японии есть институт Го который хранит партии сыгранные задолго до вашего рождения, причем там "хорошие парти" - сыгранные профессиональными игроками; это я отсылаю к проблеме поиска обучающей выборки для ИИ) и миллионов партий, сыгранных самим с собой (в пересчете на одна партия - один час, он наиграл сам с собой несколько тысяч лет)
И, повторюсь, альфа-го и ему подобные выигрывают у человека,... но есть нюанс. В основной своей массе выигрывают. Кроме тех случаев, когда люди (про-игроки высоких данов) умудряются изобретать новые комбинации или эксплуатировать некоторую повторяемость/механистичность действий программы (которую они, как профессионалы в своей области, там, по отзывам некоторых, видят).
Я это вам рассказываю, чтобы другие читающие вас, не поддавались на описанный вами как основание нарратив )) Он ошибочен (во первых, не перебором сильна ИИ, во вторых - она сильна только пока "находится на области обучения").
Отсюда - и выводы, которые вы строите на основании введения - вероятно ошибочны.
Я с частью ваших слов, как с оценками будущего, даже согласен - мидла нейросети не достигнут при текущих технологиях и имеющихся массивах кода. Но доказательная цепочка вами предложенная - ошибочна.
ага. именно ))) вы описываете задачи скриптования в скомпиленном приложении. не суть важно какой именно язык - важно чтобы скриптовый (и желательно с динамической типизацией, ибо тупо проще).
в джаве вон типовой механизм под это безобразие есть.
Java Scripting API - и не важно на каком языке вы хотите описать алгоритм, который надо поменять в рантайме - груви, питон, джаваскрипт, руби, луа, и пр. но далеко не все натыкались на идею такого рода архитектурных конструкций - когда у тебя есть жестко скомпиленное ядро и объекты системы, а ты заданных обработчиках и точках расширения вставляешь скриптование, которое использует апи этих объектов.
потому, что вы никогда, ни в жизнь не предугадать то, как это будет и какая будет логика и алгоритм расчета цены.
вспоминайте тарифы МТС эпохи начала 2000х. минута от 5и копеек. стоя на складе в полночь полнолуния, если ты скуф до 30. типа такого.
под типизацию и конфигурирование могут попасть только типовые акции. а всякие однократные женщинам до 25 с 3я детьми - скидка при покупке от 5и электробритв, причем скидка на 4-ю и 5-ю электробритвы, но не более 10-и, причем на 4ю бритву скидка 3% а на 5-ю -20%. причем только при оплате наличными всей суммы....
вы минуту назад даже подумать не могли что такая акция может быть. ага.
гипотеза: черновик статьи редактор скормил "Алисе" и попросил переписать.
у меня так однажды наш рп сделал с моей постановкой. я когда почитал этот прекрасный хорошо читаемый текст едва-ли не выматерился : в техническом тексте это гпт-поделие в некоторых местах поменяло объект и субъект действия.
вот и тут похоже на автоматизированный перевод и ии-адаптацию ))
скажите, вот вы пишете что зависимость от центральных библиотек декларирующие общие структуры - это типа зло. мол при изменении одной структуры - например вы упомянули заказ - требуется пересобирать всё использующие её компоненты. так?
ок. вот вы избавились от зависимости от центральной библиотеки. но структуры-то того же Order по прежнему должны быть совместимы и быть синхронизированы, чтобы не потерять данные той-же накладной где-то посередине. так?
и вот наступает день X, когда торговые менеджеры придумали очередную акцию, и требуется изменить структуру заказа (например у строчки заказа появляется доп. признак - размер кешбека скажем за данную позицию) и правила обработки накладной, скажем меняется приоритетность доставки от этого кешбека (идиотизм, но кто их торгашей вообще когда понимал зачем они что делают. в общем не важно зачем это так).
и вот вам надо поменять все dto-шки этого Order во всех сервисах которые его обрабатывают. причем сделать это надо строго ко к дню праздника Y (торговые акции они такие. и скажите спасибо что это не требования изменяющегося законодательства, тогда вообще жёстко).
и теперь вопрос: во сколько возрастают трудозатраты команд и вероятность ошибок, если команды не могут получить готовый артефакт ? каждая из команд, теперь должна не просто перекомпилить и деплойнуть свои сервисы (что в случае минорных изменений вообще можно сделать едва-ли не в автоматическом режиме), а самим ещё понять - что, и в какой структуре поменять. если отдать это им на откуп - половина поменяет не там, вторая опечается, третья тип поставит не тот, потом дебаг, созвоны, всё бегают тестируют, пишут багрепорты.... серьёзно?
у меня стойкое впечатление, что вы, в погоне за идеализированной идеей, усугубляете объективное число проблем.
несомненно, не всё в системе должно быть централизованно. но какие-то вещи обязаны быть централизованно управляемы и желательно именно техническими методами. иначе система перестает быть единой системой.
вы выбрали не самый удачный бизнес-пример, и на нем как раз ваша попытка донести, может быть и здравую (кто знает?) мысль ломается.
ну, или я "ничонепонял-нетакпонял" ? но тогда см комментарий выше о косноязычием статьи.
т.е. они думают, что кровавый ынтерпрайз в закрытых исходниках чем-то лучше школьноподелок на гитхобе? ахх-ха-ха-ха... чую запах великого облома XD)))
кроваво-ынтерпоайзнутый код он в закрытых исходниках вовсе не потому что он какой-то там хороший. он "конкретный" - решающий конкретные задачи, и потому он ценен "для бизнеса".
методика разработки. точнее вам нужна методология, которая позволяет построить свою методику, свой подход на каждом проекте. в зависимости от его тяжести, объема, сложности, и опыта и состава команды.
если хотите совет, то найдите RUP 6. Rational Unified Process v6. именно 6й версии, последней, которую выпустила компания Rational перед тем как её купила IBM.
в 7й версии эффективные манагеры голубого гиганта испоганили всё, и например из "лучших практик разработки", понятных и четко обоснованных, сделали непотребство вида "принципы бизнес ориентированной разработки", направленные видимо на повышение продаж, и с техническим качеством вообще никак не связанные. говорю как "сертифицированный специалист по RUP v7". я тогда немного затянул с подготовкой, и не успел сдать сертификацию на 6ю версию. то что я увидел в 7й меня "немного удивило".
ну и вот. методология. масштабируемый процесс, шведский стол элементов, из которых вы , понимая принципы, строите подходящий процесс разработки , на каждом конкретном проекте.
именно так, как надо тут и сейчас: от записанных на коленке FTR до тяжёлых спецификаций.
ещё хорошо поможет переход от постановки требований в формате долженствования ("система должна делать делать такую то функцию, после нажатия, и выводить....") к повествовательному стилю юзкейзов ("прецедентов использования") пользователь нажимает кнопку, система выводит это, и запускает фоновую функцию...").
к трассируемости и понятности контекста и сути - сильно поможет принцип "usecase driven development" . всё вокруг прецедентов.
концепция постепенно развивающихся и детализируются артефактов поможет делать и понимать ровно то, что что надо сейчас. не перегружаться написанием документации, а детализировать прецеденты там и когда надо. у нас был проект 2.5 года, (2 последовательных госконтракта), и у нас часть прецедентов до самого конца так и остались в форме "бриф-дескрипшена". потому что всем и так всё было понятно. а 4 или 5 прецедентов, из трёх десятков, и были прописаны подробнейшим образом, по шагам, с приложением алгоритмов обработки записей в бд).
понимание "компонентно ориентированной разработки" поможет не участвовать в холиваре микросервисы против монолита, а правильно выделять в микросервисы то что само выделяется и оставлять в маленьких монолитных сборках то, что не требуется пока выделять, или что эффективнее работает в межпроцессном взаимодействии и общей памяти. ( и никакой распиаренный DDD вам не потребуется, имхо, хотя и изучите его для кругозора. "всё говорят", "в нем что то есть", но и про инжектирование зависимостей так тоже говорили, как о какой-то "высшей сакральности", а я смотрю на это как на ещё одну обычную фабрику классов и подстановку реализации в рантайме. в общем ничего ни сакрального, ни достойного кипяткопИсания нет - простое частное решение, если конечно, вы понимаете компонентно-ориентированной подход и фабрику классов. )
ещё почитайте для общего развития "проектно ориентированное управление" Дж.Родни Тернера.
тоже плохо представляю, где вы её сейчас возьмёте, но это единственная книга по управлению проектами которую я нашел, где где внятно описано "управление по вехам" и "планирование набегающей волной". поможет понять взгляд теории управления проектами на интерационную разработку. и эта книга, имхо, как мифический человекомесяц Брукса - нестареющая классика. ну разве что её не переиздают.
за сим, доброго вам дня и хороших поисков. как найдёте решение, скажите. самим не на всех проектах удается выстроить всё как надо ) до сих пор, да. но теория сильно помогает. как говорится чем смог, тем помог. ))
указанная методика, имхо, не учитывает технический аспект.
архитектурные задачи, требующиеся для стабильной работы системы, обеспечения требуемых характеристик системы , безопасность, обеспечение инфраструктуры работы ("где джавадоки, вашу мать?! почему нет юниттестов? почему не прогнали интеграционные тесты? как так нету их ?!!!! что значит у нас апи не позволяет получить токен без участия человека??"(с)) -... короче вот такое и не только - должно идти в первом приоритете.
как бы пользователь не хотел что то очень важного, без обеспечения технических задач, погоня только за пользовательскими фичами - это как правило медленное погружение в технический ад, значительное замедление разработки, накопление снежного кома технического долга.
т.е. у нас должны быть не 4 колонки, а матрица 16 ячеек))) пересечение mscw по пользовательскому приоритету, и по техническому - с точки зрения влияния на архитектуру и технической критичности.
т.е. вспоминайте RUP - есть пользовательский приоритет, есть технический. архитектор+аналитик вместе приоретизируют задачи на итерацию потому что их взгляды противоположенны - один отстаивает потребности системы, второй - желания пользователей.
не важно как считать, rice, ice, mocsow - да хоть экспертами оцениваете по шкале критично, важно не важно - это только способы получить веса приоритета.
важно помнить, что в разработке ПО есть 2 этих взгляда. 2 разных приоритета. а вы балансирует между ними в ходе работ итерации.
1) так такой товар рассматривается как бракованный или нет?
2) если это "бракованный" товар, то какие последствия для потребителя несет покупка "заведомо бракованного" товара. т.е. например - не последует ли за признанием "бракованности" отказ от гарантий. т.е. не получится ли ситуация, когда гарантия на iPhone - "2 недели на замену"?
3) речь идет о несоблюдении РП №2240-р и №2241-р от 9 августа 2025 года. Какие последствия понесет, и кто, за несоблюдение Распоряжения Правительства ? У меня сомнения, что такая бумажка спасет продавца и/или поставщика от последствий.
хотите раскрою секрет? просто все адепты микросервисов слепо считают антипаттерн "связи многие ко многим" автоматически приравненным к монолиту.
впрочем это не мешает им следующим шагом рассуждать о том, "как плохо делать распределенный/микросервисный монолит", в котором микросервисы организованы так, что сбой/изменение одного модуля, приводит к сбою / необходимости обновления всей системы.
вот не складывается у них, не складывается, что не в микросервисах дело, не в способе сборки и упаковки компонент системы...
тупят, как Алиса Яндексовская в той истории про "самую длинную реку в мире".
а любил бы аффтор angular или vue - это была бы не реклама реакта, а реклама ангуляра или вуе )))
даже в 1с поддерживается альтернативное английское написание ключевых слов.
если это учебный язык для школьников - то им нужен не js с его альтернативно-одаренной псевдо параллельностью, которую и взрослым то не объяснить нормально. и кучей других приколов на тему " '1'+1 ' и " '1'-1 "
если переводить, то переводить Паскаль или Бейсик. а так - это мертворожденная идея, которая не прижилась ни разу на протяжении более чем 40 лет. начиная с советских лого-подобных черепашек.
человеку, который не знает английского - в it делать нечего. абсолютно и совсем. и даже в 1С - без английского и внешних языков ты будешь узконаправленный ограниченным кодером.
это, конечно, если эта статья не стёб и провокация.
подброшу аффтору пару мыслишек :
не существует монолита и микросервисов. как "архитектур".
есть компонентно-ориентированная архитектура и антипаттерн "связи все ко всем" .
непонимание компонентно-ориентированной архитектуры порождает "микросервисный монолит", в котором вроде всё разнесено на сотни хостов, всё по книгам, но что-то поменять сыкотно, потому, что не знаешь где какая проблема вылезет. потому что связи между элементами системы запутаны и трудно прослеживаемы.
а понимание компонентно-ориентированной архитектуры позволяет оставаясь даже в концепции "монолитной сборки и дистрибуции" достигать всех "преимуществ приписываемых якобы-только микросервисам" - распределенные независимые команды, отказоустойчивость, незаметное развертывание новых фич и пр.
а мы используем eclipse. потому что мультипроектный комбайн. независимые компоненты можно собирать из исходников и править при необходимости, тут и сейчас, вместе с основным проектом, без всяких там мавенов и прочего. и несколько проектов в одной ванночке. крайне удобно проводить рефакторинг, буквально в полуавтоматическом режиме оно меняет и в компоненте, и в трёх проектах от неё зависящих. и не важно что все они потом собираются в независимые jar/war , хранятся в разных репозиториях (включая "часть в svn часть в git").
8-Р
а если серьезно, нетбинс ещё живы? ) пока тут люди спорят за эклипс против идеи, они решили выступить третьей стороной?)) у меня в сознании это примерно на уровне "vsc тоже умеет компилить джаву", но никто кроме студентов это не делает.
киньте в меня, пожалуйста, ссылку какой на более-менее внятный обзор возможностей, включая мультипроектность?
пысы: ещё бы поддержку мавена, свн, ломбока, апач велосити, и до кучи спринга (для тех кто с курсов и не умеет никуда больше), ямл (и пусть те кто придумал использовать невидимые символы не как разделители пропехнутся)....
есть таковые плагины?
Дада. Вайбкодеры — новые «индусы». #йапиарюсь ;)
и развитие сиуации, судя по всему, будет аналогичное.
За той разницей, что "индусский код" не уничтожил локальные команды, а эти архаровцы (эффективные менеджеры), не смыслящие в отрасти, могут.
Вы используете дешевые спекуляции, и, кажется мне, вы рассчитываете на читателя-неофита, не знакомого с "проблемой алгоритмизации Го" )) игра такая, древне-китайская.
"Хит продаж последних 5 тысяч лет".
Суть проблемы в том, что игра Го - до сих пор не алгоритмизирована. Нет алгоритма который бы помог вам рассчитать какой делать ход дальше в Го - нет. Шахматы, для сравнения, алгоритмизировали ещё около 60-х годов прошлого века, и дальше был вопрос только наращивания вычислительных мощностей. Шахматные компьютеры были ещё в СССР. С го-же ситуация кардинально другая. Есть нейросети, которые выигрывают, но они выигрывают не алгоритмами.
Во первых, в Го комбинаторика такая, что до сих пор ни один "кластер" не может это просчитать на всю глубину. Число комбинаций на доске 19*19 сравнимо с числом атомов во вселенной. В шахматах-же, на этом фоне - комбинаторика очень маленькая.
Во вторых, в Го нет "ценности хода". В отличии от шахмат, где слон равен трем пешкам (условно) и ситуация на доске очень легко оценивается численными методами.
В Го очень часто невозможно "оценить количественно" ценность конкретного хода. Ценность имеет "конструкция", комбинация камней на доске, "форма" из трех-четырех камней. Причем относительную - потому что важна ситуация на доске. И получится у тебя выстроить комбинацию или нет - ещё вопрос - противник то тоже строит "конструкции". То что ты строил, перестает работать и становится бесполезным (в плане достижения цели партии), потому что противник сделал "не то" и влияние окружающих камней теперь другое. И сработал или нет конкретный ход - окончательно станет понятно только в конце партии. Отсюда - перебирай ты варианты, не перебирай - ценность этого хода ты не выяснишь - она вполне себе статистически будет одинаковая - в половине исходов ты проиграл (это не говоря о проблеме перебора всех вариантов).
Но натренированная на всем массиве игр и самостоятельных играх ИИ (та же альфаГо кажется) сегодня выигрывает в Го. Выигрывает не перебором или интуицией, а статистически настроенными весами в связах "нейронов". Она генерирует наиболее вероятные ходы из тех партий, которые похожи на текущую ситуацию и были выиграны. Вероятные ходы - на основании "впитывания" миллионов партий - накопленных за последние несколько тысячи лет людьми - в Японии есть институт Го который хранит партии сыгранные задолго до вашего рождения, причем там "хорошие парти" - сыгранные профессиональными игроками; это я отсылаю к проблеме поиска обучающей выборки для ИИ) и миллионов партий, сыгранных самим с собой (в пересчете на одна партия - один час, он наиграл сам с собой несколько тысяч лет)
И, повторюсь, альфа-го и ему подобные выигрывают у человека,... но есть нюанс.
В основной своей массе выигрывают. Кроме тех случаев, когда люди (про-игроки высоких данов) умудряются изобретать новые комбинации или эксплуатировать некоторую повторяемость/механистичность действий программы (которую они, как профессионалы в своей области, там, по отзывам некоторых, видят).
Я это вам рассказываю, чтобы другие читающие вас, не поддавались на описанный вами как основание нарратив )) Он ошибочен (во первых, не перебором сильна ИИ, во вторых - она сильна только пока "находится на области обучения").
Отсюда - и выводы, которые вы строите на основании введения - вероятно ошибочны.
Я с частью ваших слов, как с оценками будущего, даже согласен - мидла нейросети не достигнут при текущих технологиях и имеющихся массивах кода. Но доказательная цепочка вами предложенная - ошибочна.
ага. именно ))) вы описываете задачи скриптования в скомпиленном приложении.
не суть важно какой именно язык - важно чтобы скриптовый (и желательно с динамической типизацией, ибо тупо проще).
в джаве вон типовой механизм под это безобразие есть.
Java Scripting API - и не важно на каком языке вы хотите описать алгоритм, который надо поменять в рантайме - груви, питон, джаваскрипт, руби, луа, и пр.
но далеко не все натыкались на идею такого рода архитектурных конструкций - когда у тебя есть жестко скомпиленное ядро и объекты системы, а ты заданных обработчиках и точках расширения вставляешь скриптование, которое использует апи этих объектов.
(цитаты не из книги или статьи, но по поводу)
потому, что вы никогда, ни в жизнь не предугадать то, как это будет и какая будет логика и алгоритм расчета цены.
вспоминайте тарифы МТС эпохи начала 2000х. минута от 5и копеек. стоя на складе в полночь полнолуния, если ты скуф до 30. типа такого.
под типизацию и конфигурирование могут попасть только типовые акции. а всякие однократные женщинам до 25 с 3я детьми - скидка при покупке от 5и электробритв, причем скидка на 4-ю и 5-ю электробритвы, но не более 10-и, причем на 4ю бритву скидка 3% а на 5-ю -20%. причем только при оплате наличными всей суммы....
вы минуту назад даже подумать не могли что такая акция может быть. ага.
гипотеза: черновик статьи редактор скормил "Алисе" и попросил переписать.
у меня так однажды наш рп сделал с моей постановкой. я когда почитал этот прекрасный хорошо читаемый текст едва-ли не выматерился : в техническом тексте это гпт-поделие в некоторых местах поменяло объект и субъект действия.
вот и тут похоже на автоматизированный перевод и ии-адаптацию ))
скажите, вот вы пишете что зависимость от центральных библиотек декларирующие общие структуры - это типа зло. мол при изменении одной структуры - например вы упомянули заказ - требуется пересобирать всё использующие её компоненты. так?
ок. вот вы избавились от зависимости от центральной библиотеки. но структуры-то того же Order по прежнему должны быть совместимы и быть синхронизированы, чтобы не потерять данные той-же накладной где-то посередине. так?
и вот наступает день X, когда торговые менеджеры придумали очередную акцию, и требуется изменить структуру заказа (например у строчки заказа появляется доп. признак - размер кешбека скажем за данную позицию) и правила обработки накладной, скажем меняется приоритетность доставки от этого кешбека (идиотизм, но кто их торгашей вообще когда понимал зачем они что делают. в общем не важно зачем это так).
и вот вам надо поменять все dto-шки этого Order во всех сервисах которые его обрабатывают. причем сделать это надо строго ко к дню праздника Y (торговые акции они такие. и скажите спасибо что это не требования изменяющегося законодательства, тогда вообще жёстко).
и теперь вопрос: во сколько возрастают трудозатраты команд и вероятность ошибок, если команды не могут получить готовый артефакт ? каждая из команд, теперь должна не просто перекомпилить и деплойнуть свои сервисы (что в случае минорных изменений вообще можно сделать едва-ли не в автоматическом режиме), а самим ещё понять - что, и в какой структуре поменять. если отдать это им на откуп - половина поменяет не там, вторая опечается, третья тип поставит не тот, потом дебаг, созвоны, всё бегают тестируют, пишут багрепорты.... серьёзно?
у меня стойкое впечатление, что вы, в погоне за идеализированной идеей, усугубляете объективное число проблем.
несомненно, не всё в системе должно быть централизованно. но какие-то вещи обязаны быть централизованно управляемы и желательно именно техническими методами. иначе система перестает быть единой системой.
вы выбрали не самый удачный бизнес-пример, и на нем как раз ваша попытка донести, может быть и здравую (кто знает?) мысль ломается.
ну, или я "ничонепонял-нетакпонял" ? но тогда см комментарий выше о косноязычием статьи.
т.е. они думают, что кровавый ынтерпрайз в закрытых исходниках чем-то лучше школьноподелок на гитхобе? ахх-ха-ха-ха... чую запах великого облома XD)))
кроваво-ынтерпоайзнутый код он в закрытых исходниках вовсе не потому что он какой-то там хороший. он "конкретный" - решающий конкретные задачи, и потому он ценен "для бизнеса".
а по качеству он такой-же в основной своей массе.
мне одному кажется, что "лучше бы они не убивали unreal tournament", чем теперь пытаться всех привлекать мини-проектами ? )))
и вот, вы, от сохи, добрались, наконец, до сути.
методика разработки. точнее вам нужна методология, которая позволяет построить свою методику, свой подход на каждом проекте. в зависимости от его тяжести, объема, сложности, и опыта и состава команды.
если хотите совет, то найдите RUP 6. Rational Unified Process v6. именно 6й версии, последней, которую выпустила компания Rational перед тем как её купила IBM.
в 7й версии эффективные манагеры голубого гиганта испоганили всё, и например из "лучших практик разработки", понятных и четко обоснованных, сделали непотребство вида "принципы бизнес ориентированной разработки", направленные видимо на повышение продаж, и с техническим качеством вообще никак не связанные. говорю как "сертифицированный специалист по RUP v7". я тогда немного затянул с подготовкой, и не успел сдать сертификацию на 6ю версию. то что я увидел в 7й меня "немного удивило".
ну и вот. методология. масштабируемый процесс, шведский стол элементов, из которых вы , понимая принципы, строите подходящий процесс разработки , на каждом конкретном проекте.
именно так, как надо тут и сейчас: от записанных на коленке FTR до тяжёлых спецификаций.
ещё хорошо поможет переход от постановки требований в формате долженствования ("система должна делать делать такую то функцию, после нажатия, и выводить....") к повествовательному стилю юзкейзов ("прецедентов использования") пользователь нажимает кнопку, система выводит это, и запускает фоновую функцию...").
к трассируемости и понятности контекста и сути - сильно поможет принцип "usecase driven development" . всё вокруг прецедентов.
концепция постепенно развивающихся и детализируются артефактов поможет делать и понимать ровно то, что что надо сейчас. не перегружаться написанием документации, а детализировать прецеденты там и когда надо. у нас был проект 2.5 года, (2 последовательных госконтракта), и у нас часть прецедентов до самого конца так и остались в форме "бриф-дескрипшена". потому что всем и так всё было понятно. а 4 или 5 прецедентов, из трёх десятков, и были прописаны подробнейшим образом, по шагам, с приложением алгоритмов обработки записей в бд).
понимание "компонентно ориентированной разработки" поможет не участвовать в холиваре микросервисы против монолита, а правильно выделять в микросервисы то что само выделяется и оставлять в маленьких монолитных сборках то, что не требуется пока выделять, или что эффективнее работает в межпроцессном взаимодействии и общей памяти. ( и никакой распиаренный DDD вам не потребуется, имхо, хотя и изучите его для кругозора. "всё говорят", "в нем что то есть", но и про инжектирование зависимостей так тоже говорили, как о какой-то "высшей сакральности", а я смотрю на это как на ещё одну обычную фабрику классов и подстановку реализации в рантайме. в общем ничего ни сакрального, ни достойного кипяткопИсания нет - простое частное решение, если конечно, вы понимаете компонентно-ориентированной подход и фабрику классов. )
ещё почитайте для общего развития "проектно ориентированное управление" Дж.Родни Тернера.
тоже плохо представляю, где вы её сейчас возьмёте, но это единственная книга по управлению проектами которую я нашел, где где внятно описано "управление по вехам" и "планирование набегающей волной". поможет понять взгляд теории управления проектами на интерационную разработку. и эта книга, имхо, как мифический человекомесяц Брукса - нестареющая классика. ну разве что её не переиздают.
за сим, доброго вам дня и хороших поисков. как найдёте решение, скажите. самим не на всех проектах удается выстроить всё как надо ) до сих пор, да. но теория сильно помогает. как говорится чем смог, тем помог. ))
указанная методика, имхо, не учитывает технический аспект.
архитектурные задачи, требующиеся для стабильной работы системы, обеспечения требуемых характеристик системы , безопасность, обеспечение инфраструктуры работы ("где джавадоки, вашу мать?! почему нет юниттестов? почему не прогнали интеграционные тесты? как так нету их ?!!!! что значит у нас апи не позволяет получить токен без участия человека??"(с)) -... короче вот такое и не только - должно идти в первом приоритете.
как бы пользователь не хотел что то очень важного, без обеспечения технических задач, погоня только за пользовательскими фичами - это как правило медленное погружение в технический ад, значительное замедление разработки, накопление снежного кома технического долга.
т.е. у нас должны быть не 4 колонки, а матрица 16 ячеек))) пересечение mscw по пользовательскому приоритету, и по техническому - с точки зрения влияния на архитектуру и технической критичности.
т.е. вспоминайте RUP - есть пользовательский приоритет, есть технический. архитектор+аналитик вместе приоретизируют задачи на итерацию потому что их взгляды противоположенны - один отстаивает потребности системы, второй - желания пользователей.
не важно как считать, rice, ice, mocsow - да хоть экспертами оцениваете по шкале критично, важно не важно - это только способы получить веса приоритета.
важно помнить, что в разработке ПО есть 2 этих взгляда. 2 разных приоритета. а вы балансирует между ними в ходе работ итерации.
есть несколько вопросов, кто мог бы прояснить?
1) так такой товар рассматривается как бракованный или нет?
2) если это "бракованный" товар, то какие последствия для потребителя несет покупка "заведомо бракованного" товара. т.е. например - не последует ли за признанием "бракованности" отказ от гарантий. т.е. не получится ли ситуация, когда гарантия на iPhone - "2 недели на замену"?
3) речь идет о несоблюдении РП №2240-р и №2241-р от 9 августа 2025 года. Какие последствия понесет, и кто, за несоблюдение Распоряжения Правительства ? У меня сомнения, что такая бумажка спасет продавца и/или поставщика от последствий.
заранее спасибо.
"индусский код" - это не расизм. это явление, мем и термин. увы)
прекрасно. а где они, эти докеры?
в статье нет ни урлов, ни доступов - кроме неработающей на территории России ссылки на ютуб. добавите?
я бы предложил 2 вещи для начала продвижения:
1. ролик выдожить на официально доступные ресурсы.
2. идеально бы поднять сервер, где можно пощупать игру. простая виртуалка сейчас стоит пару чашек кода. обычно это подъемные деньги.
ну, или дистрибутивы для поднятия своего сервера и запуска клиента.
и не бросать игру. без автора, хотя бы дающего комментарии по коду - не взлетит.
ну и на всякий случай: документация и комментарии в коде. если этого нет - имхо, считайте что и нет кода в общем доступе.