Здравствуйте, Codealot, Вы писали:

_AB>>Выпустил версию, захватил долю рынка, получил финансирование и получил возможность развиваться дальше, работая над техническим долгом.
C>Или не работая.
Или не работая, если это выгоднее. Вопрос баланса, как я уже сказал. В любом случае — это пример того, как наращивание тех. долга (плохой код (с)) может быть выгоднее в долгосрочной перспективе и принести больше денег на протяжении жизненного цикла проекта.

Здравствуйте, _ABC_, Вы писали:

_AB>Или не работая, если это выгоднее. Вопрос баланса, как я уже сказал. В любом случае — это пример того, как наращивание тех. долга (плохой код (с)) может быть выгоднее в долгосрочной перспективе и принести больше денег на протяжении жизненного цикла проекта.

Очевидно, ты никогда не слышал о таком парадоксе, как дилемма узника. Это как раз тот случай, когда все пытаются по глупому оптимизировать свой выигрыш и в результате все оказываются в глубоком проигрыше.

Здравствуйте, _ABC_, Вы писали:

_AB>Да. Я с вашим братом часто общаюсь.

С каким таким нашим братом? Ты не стесняйся, рассказывай.

_AB>Не хочешь — дело твоё, мне абсолютно пофиг.

Явно не пофиг, судя по тому, как часто ты ко мне цепляешься. Опять врешь.

_AB>Не надо своих тараканов перекладывать на других. Тебе это не поможет.

Это просто факт. Я мог бы накидать еще ссылок на статистику по дискриминации, но ты ведь опять скажешь, что это всё божья роса.

_AB>Бремя доказывания лежит на утверждающем (высказывающем). Не слышал? Это же основы логического (рационального) мышления, вообще-то.

См последний абзац. Ты явно ничего не смыслишь в рациональном мышлении

_AB>Кадровики используют эти задачи для определения твоей профессиональной квалификации. Это повсеместная практика и один из стандартов де-факто.

"Все так делают" — очень хреновый аргумент.

_AB>А вот здесь реальное противоречие. Либо закон говорит, что можно, либо формулировка закона этого не позволяет, т.е. закон говорит, что нельзя. То, что ты называешь не нравящиеся тебе лично формулировки "косяком закона" — это твоя сугубо личная проблема.

Одно положение закона делает неработоспособным другие. Для тебя новость, что такое может происходить?

_AB>У меня другая специализация.

Слив засчитан.

_AB>И если ты откроешь мой профиль, то увидишь гораздо больше профессиональных сообщений, положительно оцененных другими. Т.е., я на этом форуме проявил себя куда большим специалистом в своей области, чем ты.

Какой конкретно области? Получении положительных оценок на этом конкретном сайте? Ну да, вполне возможно, что в этой области ты очень сильный профессионал. Который, по странной случайности, не умеет программировать.

_AB>Следовательно, ты выглядишь как полный балабол, а не я.

Non sequitur. Это к вопросу о рациональном мышлении.

_AB>Так ты, извини, пока что далеко не гением себя проявляешь на форуме.

Куда мне до такого крупного специалиста по получению положительных оценок на сайте RSDN.

_AB>Я тебя пока что ни в чем не обвиняю, кроме наличия глупых высказываний и алогичности. Ни первое, ни второе — не преступления, хотя, несомненно, ты совершал и то, и другое.

Врёшь, ты делал это минимум два раза.

1. Пока всё твоё поведение доказывает, что болезни, которые ты себе приписываешь, тебя не касались в принципе
2. Ты пытался избавиться от вопросов, определяющих твою профессиональную квалификацию, прикрываясь инвалидностью

Кстати, ты опять не ответил на прямой вопрос, который я тебе задал. Повторю вопрос: "Пока всё твоё поведение доказывает, что болезни, которые ты себе приписываешь, тебя не касались в принципе" — это каким образом?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Poopy Joe, Вы писали:

PJ>>Ну так они и не общаются как программист и банк, где каждый ищет как заработать на другом.
S>Эмм, очень странно. Хороший менеджер всегда ищет, как заработать. См. выше по ветке: его задача — увеличивать stakeholder value.
За счет программиста?

PJ>>А почему ты не готов на него полагаться? Ты такой умный или он такой тупой? Вот это желание всем лично руками контролировать, потому что могу, выглядит для меня нездоровой практикой. Если ты не доверяешь мнению специалиста, то его надо увольнять. Зачем надо платить инженеру деньги и не слушать?
S>Потому, что в обязанности разработчика не входит детальное знание приоритетов. Точно так же, как программист не должен полагаться на то, что менеджер разбирается в деталях кода.
Вот тут стоп. Приоритеты это то, что надо сделать. Как программист может сделать что-то, чего он не понимает в деталях? Для кого тогда эти приоритеты? Менеджеры друг-другу презентации показывают?

S>В вопросах кода — конечно менеджер должен слушать разработчика. Если тот сказал, что через SSE не ускорить — значит, не ускорить. Если сказал, что потребуется три недели — значит, три недели.
S>А в вопросах того, какую фичу делать сейчас, а какую потом — решает менеджер. Иначе нахрен он вообще нужен? Зачем мы нанимаем менеджера, и не даём ему принимать решения?
Менеджер ставит приоритеты в каком порядке ему нужны фичи, он их так продать может. В каком порядке их делать, и что нужно чтобы их сделать он не знает и знать не обязан, это не его компетенция. Обычно этот порядок совпадает с планом действия, но не всегда. И в этом случае порядок меняется, после обсуждения. Потому что это все командная работа и менеджер не царь, на самодурстве настаивать, а участник команды.

PJ>>Пример начался с того, что представлены планы компании. Как можно их представить и не знать, что там надо делать?
S>Нуу... например, потому, что есть большой разрыв между планом "запускаемся в китае" и детальным планированием релиза.
"Запускаем в Китае" это вообще не план. Если у вас так с разработчиками общаются, то вас только пожалеть можно, вы себе же в ноги стреляете.

PJ>>Это твое личное понимание рефакторинга. Я не могу сказать, что оно неправильное, поскольку правильного, отлитого в граните не существует.
S>Это не только моё понимание рефакторинга. Сходите хотя бы в википедию. Если не верите википедии — посмотрите, что называется рефакторингом в инструментальных средствах — студия, решарпер.
Т.е. если студия позволяет только переименовывать, а раньше так и было, то это весь дозволенный рефакторинг?

S>Цитирую:
S>

S>Рефа́кторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований.

S>Вот именно. Без изменения поведения. А у вас — "Вся логика взаимодействия с этим модулем стала другая, обработка ошибок по другому."

Ты когда цитаты приводишь, то их хотя бы сам внимательно читай. Без изменения поведения и без изменения внешнего поведения имеют принципиально разный смысл. Вот совсем. Ты, если хочешь, можешь понимать как тасование классов. Я, и мои коллеги, и мое начальство и вообще все с кем эта тема обсуждается понимают это так как написано в определении — изменение кода без изменения внешнего поведения.

PJ>>Вот первое о чем говорит DDD, что так делать нельзя. Нельзя строить бизнес-логику на предположениях, да еще и другого домена. Вы изначально раскидали грабли где только можно, а потом это стало проблемой. Вот же странно-то...
S>Непонятно, как можно строить бизнес логику без предположений.

Описывая все в явном виде. Если ты ссылаешься на DDD, который тебе не поможет, то хотя бы ознакомсья с предметом.

S>Да нет, всю эту кунсткамеру пилили как раз разработчики.
Ну, по примерам выше, у меня тоже сложилось впечатление, что "бежать отсюда надо". Вот и результат. Обучайте людей. Описанная ситуация ненормальная совершенно, если даже такое простейшее изменение вызвает проблемы и необходимость костылей.

S>И я не понимаю, что такое "из другого домена"? Домен тут ровно один — управление cloud-сервисами. Что вы называете "доменом"?

DDD (Domain-driven design)
Домен это не абстракция типа "управление cloud-сервисами", это ограниченное решение какой-то задачи. Что у вас там? "управление платежами" допустим. Ваше решение. Сторонний код живет внутри своего домена, его решение ограничено его рамками.
Мне предложить тебе список литературы, или какой именно ты ответ ждешь? Потому как это ну совсем основы.
Можно продолжить обсуждение DDD и как делать по феншую, но, наверно, не в этом топике и не в общем виде.

PJ>>В такой, прости господи, архитектуре, добавления комментария в код может не пройти легко и непринужденно. Ну так не делайте так. Мы уже как-то обсуждали, и выяснилось, что ты не признаешь инвариантов в системе. Ну вот, это результат.
S>Продолжаю непонимать. Вот у нас в системе был инвариант "у ордера всегда есть подписка". Он десятилетиями оставался незыблемым. Теперь он изменился. Каким образом DDD (или вообще какой-то подход к коду) может тут помочь?

Это не инвариант. Инвариант это "у ордера всегда есть подписка" выраженная в виде модели, а не предположения. DDD тут поможет тем, что весь это спагетти код предположений будет разделен на ограниченные контексты, каждый из которых будет иметь свой инвариант и не зависеть ни от каких предположений. Между ними будут границы с контрактами. Если все это еще и написано правильно, по принципам чистой архитектуры, и все побочные эффекты вынесены на границы, а логика только чистые функции, то все сводится к созданию еще одного контракта и контекста с немного измененнной композицией функций. Если модель еще и строго типизированая, что лично я крайне рекомендую, то все сводится к: дополнить модель, пофиксить ошибки компиляции. Вы просто любите страдать.

Здравствуйте, Codealot, Вы писали:

C>Похоже, что у тебя там не хватает частицы "не".
Где именно?

C>Объясняю: рефакторинг, который делается при помощи кнопок Alt-Enter — это самая примитивная и наименее полезная форма рефакторинга из возможных. И если программист думает, что других видов рефакторинга не бывает, то этот программист — тот самый джун, которого тут очень часто упоминают.
Да мне всё равно, при помощи каких кнопок он делается, или какие виды рефакторинга знаю я. Я-то хочу понять о чём вы говорите: это же вы рассказываете, что рефакторинг длинным не бывает, и что никак не мешает остальной деятельности. Но при этом почему-то менеджеры вам как-то ухитряются мешать его делать.

Здравствуйте, Poopy Joe, Вы писали:
PJ>За счет программиста?
Ну да. А за счёт чего, простите? Программисты работают, приносят пользу. Если менеджер смог добиться большего с меньшими затратами — молодец, получи квартальный бонус.
Не смог выполнить задачи — получи взыскание. У менеджера нет другого способа приносить ценность — сам он продукт не создаёт.

PJ>Вот тут стоп. Приоритеты это то, что надо сделать. Как программист может сделать что-то, чего он не понимает в деталях? Для кого тогда эти приоритеты? Менеджеры друг-другу презентации показывают?
Вижу, у вас какой-то другой словарь русского языка, чем у меня.
То, что надо сделать — это задачи. Приоритеты — это относительная важность этих задач.
Задача — "сделать отчёт по продажам в PDF". Детали, важные для программиста — это какие данные должны быть в отчёте, критерии отбора, формулы расчёта и т.п. Шаблон того же PDF — будет ли он фиксированным, или должен настраиваться. Если настраиваться, то кем и в каких пределах.
А вот то, делать ли этот отчёт сначала, а систему конфигурации потом, или же наоборот — это уже приоритеты.

PJ>Менеджер ставит приоритеты в каком порядке ему нужны фичи, он их так продать может. В каком порядке их делать, и что нужно чтобы их сделать он не знает и знать не обязан, это не его компетенция. Обычно этот порядок совпадает с планом действия, но не всегда. И в этом случае порядок меняется, после обсуждения. Потому что это все командная работа и менеджер не царь, на самодурстве настаивать, а участник команды.
Да, под словом "делать" я имел в виду "выдавать заказчику", а не "трудиться над ними". Естественно, нормальный менеджер не лезет вот в это микроуправление — это пусть тим лидеры решают, кто там что ежедневно будет делать.

PJ>"Запускаем в Китае" это вообще не план. Если у вас так с разработчиками общаются, то вас только пожалеть можно, вы себе же в ноги стреляете.
Ну, во-первых, вы же не ожидаете, что я вам тут все 74 слайда презентации топ-менеджмента с "all hands meeting 2019" тут процитирую?
Во-вторых, топ-менеджмент планирует примерно вот в таких вот терминах: есть планы по выручке, обороту, марже и т.п.; они детализированы до уровня регионов и кварталов; есть какие-то соображения о том, как эти планы будут выполняться.
Например — возникла oppotunity на ближнем востоке, мы планируем ей воспользоваться и развернуть там инстанс продукта, который будет совместно использоваться четырьмя странами. Сделка должна быть закрыта во втором квартале, в третьем выполнено само развёртывание и проведён soft-launch, в четвёртом квартале — выход в продакшн. Есть предварительные оценки расходов по статьям инфраструктура/развёртывание/маркетинг/сопутствующие расходы, есть предварительные планы продаж после запуска.
Вот в каких терминах планирует стратегию компании топ-менеджмент. Никто на уровне senior vice-president не заморачивается вещами типа "поддержка RTL в отчётах", которые потребуются в рамках этого запуска.
Это делают люди на три-четыре уровня ниже. Менеджеру департамента уже ставятся задачи в относительно подробном виде — типа "провести интеграцию с бухгалтерским софтом, используемым в каждой из четырёх стран". Известно что, известно когда должно быть готово. В идеальном сферическом мире эти требования появляются заранее, не меняются, и у менеджера всегда довольно ресурсов для того, чтобы всё спланировать с запасом на непредвиденные обстоятельства.
В реальности помимо вот такой плановой разработки постоянно появляются новые требования, старые изменяются, и планы постоянно ротируются.
У нормального программиста хватает своей работы, которой голова забита, чтобы ещё и следить за всей этой чехардой.

Рработа менеджера — как раз балансировать все эти "мы хотим запуститься у арабов в мае" и "мы хотим развернуть новую линейку продуктов в Австралии в апреле" так, чтобы выхлоп был максимален, а ущерб — минимален.

PJ>Т.е. если студия позволяет только переименовывать, а раньше так и было, то это весь дозволенный рефакторинг?
Нет, не весь. Есть ещё решарпер, ИДЕЯ, и много других инструментов. В принципе, достаточно пытливому уму, чтобы из сотни примеров вывести общий принцип.

PJ>Я, и мои коллеги, и мое начальство и вообще все с кем эта тема обсуждается понимают это так как написано в определении — изменение кода без изменения внешнего поведения.
У вас при этом какая-то очень широкая трактовка того, что считается "внешним поведением".
В моём уютном мирке если нажатие на кнопку "сохранить" раньше сохраняло текущий файл, а теперь каждый раз создаёт новую копию — то это изменение внешнего поведения.
Вообще, в целом, любая фича — это изменение внешнего поведения. Просто по определению фичи. Если пользователь фичу не видит, то никакой фичи нет.
Именно поэтому утверждение, что фича может быть результатом рефакторинга, является оксюмороном, независимо от того, какие детали мы вкладываем в слово "рефакторинг".

PJ>Описывая все в явном виде. Если ты ссылаешься на DDD, который тебе не поможет, то хотя бы ознакомсья с предметом.
Ну и в чём противоречие-то? Раньше в бизнес-логике в совершенно явном виде было написано "каждый ордер в обязательном порядке ссылается на подписку".
Теперь это утверждение перестало быть справедливым. По прежнему не понимаю, какой магией вы предлагаете решать такие задачи.

PJ>DDD (Domain-driven design)
PJ>Домен это не абстракция типа "управление cloud-сервисами", это ограниченное решение какой-то задачи. Что у вас там? "управление платежами" допустим.
Управление платежами — это, к счастью, отдельный модуль; его в данном изменении трогать не придётся.
Хотя всё равно есть риск протекания абстракции — например, если мы хотим каждый платёж классифицировать как recurring payment или non-recurring payment, то в зависимости от того, как это реализовано, возникают совершенно разные схемы зависимостей.

PJ>Это не инвариант. Инвариант это "у ордера всегда есть подписка" выраженная в виде модели, а не предположения.
Именно в виде модели это и выражено. А как иначе-то.

PJ>DDD тут поможет тем, что весь это спагетти код предположений будет разделен на ограниченные контексты, каждый из которых будет иметь свой инвариант и не зависеть ни от каких предположений. Между ними будут границы с контрактами. Если все это еще и написано правильно, по принципам чистой архитектуры, и все побочные эффекты вынесены на границы, а логика только чистые функции, то все сводится к созданию еще одного контракта и контекста с немного измененнной композицией функций. Если модель еще и строго типизированая, что лично я крайне рекомендую, то все сводится к: дополнить модель, пофиксить ошибки компиляции. Вы просто любите страдать.
Даже если бы наш код был написан так, как вы предлагаете (делов-то — переписать 1200 человеко-лет работы, тьфу), то "ошибки компиляции" при таком изменении возникнут в 100500 местах.
А некоторые из них — и вовсе в коде, который написан сторонними людьми вне нашей юрисдикции. Дело не в том, что мы любим страдать, а в том, что ломающие изменения дороги в любой архитектуре.

И, возвращаясь к теме беседы, кажный раз бросаться грудью на амбразуру и честно вносить эти изменения может привести к убыткам, а не к прибыли.
Точно так же, как займ в банке — никто не спорит, что лучше жить без кредитов. Тем не менее, кредиты являются частью совершенно нормальной практики — и даже если пренебречь кредитами физлицам (которые могут быть просто проявлением иррационального поведения), вполне себе трезвомыслящие бизнесы запросто берут средства в кредит для того, чтобы решить свои задачи.
Так и техдолг — да, бесконтрольный его рост может привести к банкротству. Но для его временного наращивания могут быть вполне валидные причины.

Здравствуйте, Poopy Joe, Вы писали:

I>>Рефакторинг это не "поведение с тз бизнеса", а вообще наблюдаемое поведение, т.е. гарантируем это автоматическими тестами всех уровней, ручными, проверкой пред-, пост-условий, инвариантов, можно даже хоть логи притянуть сюда.
I>>Раз добавилась фича — значит наблюдаемое поведение изменилась.
I>>Поскольку старое не поломали, значит это инкрементное изменение. Т.е. новая фича не модифицирует старые.

PJ>Правильное слово тут внешнее. Т.е. с точки зрение внешнего наблюдателя, т.е. бизнеса, обычно. Какие там логи внутри вообще никого не волнует. Твое определение бесполезно чуть менее чем полностью.

Это не я, а Фаулер.

>Добавил параметр в функцию, все тест поменял — не рефакторинг.

Именно. Изменение теста указывает на слом.

Здравствуйте, Codealot, Вы писали:

I>>Так делают
I>>1 плохие пиэмы из бывших разработчиков

C>Любые плохие пиэмы.

Нет, не любые. Менеджер, даже пиэм, может быть плохим по самым разным причинам. Например, пить водку вместо работы.

I>>Девелопер обязан уметь изъясняться в единицах business value, а не словами из кода, иначе он просто джун.

C>Интересно у тебя получается. Девелопер обязан знать и свою область, и менеджерскую.

Business value это общая область.

>А заодно и предметную область, очевидно. А манагер, похоже, обязан знать только волшебные заклинания "сделать!!!" и "быстро!!!111"

Очевидно — нет. Есть общая зона ответствености, пересечение. И это не код.

Здравствуйте, Poopy Joe, Вы писали:

PJ>. Ну, тот же критический баг, в релизе. Я могу спросить менеджера любого уровня до топов как вам надо лучше или быстрее и ответ всегда будет "лучше".

Лучшесть это не свойство результата, а степень соответствия цели.
Хорошо все, что приближает цель. Сильнее приближает = лучше.

Отсюда понятно, что лучше или быстрее смысла нет спрашивать, тк это общие слова.

А вот быстро или качественно — тут уже думать надо. Быстро или дешево. Быстро или надежно. Быстро или с гарантиями.

Качество должно соответствовать цели и бюджетам. Цель — демо, тогда и качество как у демо. Цель — прототип, качество — как у прототипа. Цель — продукт, тогда и качество как у продукта, а стало быть выше и демо, и прототипа, тк у продукта качество приносит деньги и отбивает долгосрочные вложения.

Здравствуйте, Sinclair, Вы писали:

PJ>>За счет программиста?
S>Ну да. А за счёт чего, простите?
Хм... Я всегда думал, что за счет клиента. Приносить прибыль за счет сотрудников, ну даже не знаю...

S>Не смог выполнить задачи — получи взыскание. У менеджера нет другого способа приносить ценность — сам он продукт не создаёт.
Есть конечно. Он может сотрудничать с программистами, а не играть против них. Это не игра с нулевой суммой, как в банке где деньги получает либо клиент, либо банк.

PJ>>Вот тут стоп. Приоритеты это то, что надо сделать. Как программист может сделать что-то, чего он не понимает в деталях? Для кого тогда эти приоритеты? Менеджеры друг-другу презентации показывают?
S>Вижу, у вас какой-то другой словарь русского языка, чем у меня.
S>То, что надо сделать — это задачи. Приоритеты — это относительная важность этих задач.
И в том и в другом случае ты употребил слово задачи. Я думаю любому идиоту понятно, что речь о задачах, к чему ты начал докапываться до мелочей мне непонятно. Или я не понял, что ты тут хотел сказать.

S>Задача — "сделать отчёт по продажам в PDF". Детали, важные для программиста — это какие данные должны быть в отчёте, критерии отбора, формулы расчёта и т.п. Шаблон того же PDF — будет ли он фиксированным, или должен настраиваться. Если настраиваться, то кем и в каких пределах.
S>А вот то, делать ли этот отчёт сначала, а систему конфигурации потом, или же наоборот — это уже приоритеты.
Странные у вас какие-то задачи. В acceptance criteria написано, что должно быть в этом отчете. Каком порядке это делаю разработчики вообще не проблема менеджмента. Либо это две разные задачи со своими AC. В этом случае разработчик должен понимать смысл приоритетов, в каком порядке их делать и возможно ли это вообще.

PJ>>"Запускаем в Китае" это вообще не план. Если у вас так с разработчиками общаются, то вас только пожалеть можно, вы себе же в ноги стреляете.
S>Ну, во-первых, вы же не ожидаете, что я вам тут все 74 слайда презентации топ-менеджмента с "all hands meeting 2019" тут процитирую?
Причем тут вообще топ-менеджер? Я говорю про ПМ — продакт менеждер. Топы никогда не ставят задачи разработчикам, как и "all hands meeting" тоже не план. Не знаю зачем ты это сюда приплел, про топов я речи не вел и даже обсуждать это не хочу.

PJ>>Т.е. если студия позволяет только переименовывать, а раньше так и было, то это весь дозволенный рефакторинг?
S>Нет, не весь. Есть ещё решарпер, ИДЕЯ, и много других инструментов. В принципе, достаточно пытливому уму, чтобы из сотни примеров вывести общий принцип.
Пытливому уму достаточно понять, что рефакторинг появился задолго до любых инструментов и никак не зависит от того, что они могут. Совсем.

PJ>>Я, и мои коллеги, и мое начальство и вообще все с кем эта тема обсуждается понимают это так как написано в определении — изменение кода без изменения внешнего поведения.
S>У вас при этом какая-то очень широкая трактовка того, что считается "внешним поведением".
Конечно широкая, потому как оно для решения проблем, а не для использования в молельном доме в виде библии. Новый файл это внутренне состояние в данном случае. Клиенты эти файлы не видят и даже не знают о их существовании. Так что это вопрос трактовки что считать внешним поведением. Вон у Ikemefula изменение сигнатуры метода не рефакторинг, если оно сломает существующий тест. Хотите "рефакторить" только так? Ну флаг вам в руки, не вижу никакой пользы от такого, кроме религиозных плясок.

S>Вообще, в целом, любая фича — это изменение внешнего поведения. Просто по определению фичи. Если пользователь фичу не видит, то никакой фичи нет.
ну назови это багфиксом.

S>Именно поэтому утверждение, что фича может быть результатом рефакторинга, является оксюмороном, независимо от того, какие детали мы вкладываем в слово "рефакторинг".
я такого не говорил, я сказал рефакторинг + фича и что их можно делать одновременно и даже в обратном порядке, а не последовательно.

S>Ну и в чём противоречие-то? Раньше в бизнес-логике в совершенно явном виде было написано "каждый ордер в обязательном порядке ссылается на подписку".
Противоречие в том, что у тебя это размазано в неявном виде неких предположений по вообще всем местам включая сторонний код. В DDD это модель внутри изолированного домена, к которой никто доступа не имеет, кроме как через контракты на внешних слоях. Соответственно, изменение этой модели никак их сломать не может.

S>Теперь это утверждение перестало быть справедливым. По прежнему не понимаю, какой магией вы предлагаете решать такие задачи.
Оно перестало быть справедливым в рамках одной модели. Остальные эти изменения даже видеть не должны, как и саму модель.

S>Хотя всё равно есть риск протекания абстракции — например, если мы хотим каждый платёж классифицировать как recurring payment или non-recurring payment, то в зависимости от того, как это реализовано, возникают совершенно разные схемы зависимостей.
У вас не просто протекание, у вас все размазано (судя по тексту). Вот чтобы оно не протекало DDD и используют.

PJ>>Это не инвариант. Инвариант это "у ордера всегда есть подписка" выраженная в виде модели, а не предположения.
S>Именно в виде модели это и выражено. А как иначе-то.
Ну ты уже определись модель у тебя или предположения. Если есть модель, то никакие предположения не нужны.

S>Даже если бы наш код был написан так, как вы предлагаете (делов-то — переписать 1200 человеко-лет работы, тьфу), то "ошибки компиляции" при таком изменении возникнут в 100500 местах.
Во-первых, работы тут не больше, ее даже меньше. Она просто другая. Во-вторых, ошибки в 100500 местах возникают когда "протекают абстракции" т.е. ты не следуешь дизайну, значит уже не как я предлагаю.

S>А некоторые из них — и вовсе в коде, который написан сторонними людьми вне нашей юрисдикции. Дело не в том, что мы любим страдать, а в том, что ломающие изменения дороги в любой архитектуре.
Ты сейчас мне рассказываешь, что жизнь трудна, потому что ты другой не видел. Ну, если хотите страдать — страдайте. Если у вас девиация вида платежей это ломающее изменение, то мои вам соболезнования.

S>И, возвращаясь к теме беседы, кажный раз бросаться грудью на амбразуру и честно вносить эти изменения может привести к убыткам, а не к прибыли.
Так я с этого и начал. Система доведена до состояния когда любые изменения вносить страшно, потому что сломается непонятно где и непонятно что. Это и есть технический долг, просто другого вида. И если его не уменьшать постоянно, то система вот до такого и доходит.

Здравствуйте, Ikemefula, Вы писали:

I>Это не я, а Фаулер.
Я даже не знал, что он знает русский.
По виду похоже скорее на твою интерпретацию Фаулера, как ты ее понял.
Не говоря уж то, что Фаулер, да и любой другой известный автор, высказывают так же свое мнение, а не абсолютную истину.
Я бы предложил перестать ссылаться на авторитеты и высказывать своем мнение и уж его отстаивать.

Здравствуйте, Poopy Joe, Вы писали:

PJ>И в том и в другом случае ты употребил слово задачи. Я думаю любому идиоту понятно, что речь о задачах, к чему ты начал докапываться до мелочей мне непонятно. Или я не понял, что ты тут хотел сказать.
Вижу, что вы чего-то не понимаете.
PJ>Странные у вас какие-то задачи. В acceptance criteria написано, что должно быть в этом отчете.
Ну ок. Откуда берутся эти acceptance criteria?

PJ>Каком порядке это делаю разработчики вообще не проблема менеджмента. Либо это две разные задачи со своими AC. В этом случае разработчик должен понимать смысл приоритетов, в каком порядке их делать и возможно ли это вообще.
Вот здесь под словом "делать" вы что имеете в виду — написание кода, или таки порядок выдачи?
Менеджер рулит только порядком выдачи — RTO, если это релиз для внутреннего употребления, или RTM, если внешним клиентам.
Именно менеджер принимает решение, что и в каком релизе выходит. Вы, вроде бы, это понимаете, но продолжаете спорить. И выходит так, что у вас почему-то разработчик решает, что в каком порядке выпускается, а если не он — то это какое-то неуважение к разработчикам.

PJ>Причем тут вообще топ-менеджер?
Мы же говорим про планы компании, а не мелкого департамента на пару-тройку десятков человек.
PJ>Я говорю про ПМ — продакт менеждер. Топы никогда не ставят задачи разработчикам, как и "all hands meeting" тоже не план. Не знаю зачем ты это сюда приплел, про топов я речи не вел и даже обсуждать это не хочу.
Отлично, давайте поговорим про продакт менеджеров. Может, ваши продакт менеджеры обсуждают с разработчиками планы на годы вперёд — у нас такое бывает редко.
Обычно планировать хоть что-то дальше полугода не имеет никакого смысла — все тщательно продуманные планы придётся выбросить уже через три месяца, потому что бизнес-реальность меняется слишком быстро.

PJ>Пытливому уму достаточно понять, что рефакторинг появился задолго до любых инструментов и никак не зависит от того, что они могут. Совсем.
Конечно. При этом инструменты пилились ровно в рамках того понимания рефакторинга, который был до них. Поэтому мы не найдём ни в одном инструменте такого рефакторинга, который меняет наблюдаемое поведение кода.

PJ>Конечно широкая, потому как оно для решения проблем, а не для использования в молельном доме в виде библии. Новый файл это внутренне состояние в данном случае. Клиенты эти файлы не видят и даже не знают о их существовании.
Раз они их не видят и не знают, то и фичи никакой нет. Простите, в нашем продукте всё запущено — я в жизни не стану представлять клиентам штуку типа "раньше мы корраптили файлы конфигурации, а теперь перестали" как фичу.
Это в лучшем случае будет отражено как починенный баг — и то, только если его обнаружил кто-то снаружи компании.
А у вас, как я погляжу, супер архитектура — в качестве фичи выдаётся "продукт стал меньше глючить и чаще ломаться". В таком случае я не вижу смысла дальше спорить о терминах.
PJ>ну назови это багфиксом.
PJ>я такого не говорил, я сказал рефакторинг + фича и что их можно делать одновременно и даже в обратном порядке, а не последовательно.
Ну, ок, будем считать, что вы неудачно выразились.

PJ>Противоречие в том, что у тебя это размазано в неявном виде неких предположений по вообще всем местам включая сторонний код.
Почему в неявном-то? В самом явном. Прямо в модели (которая торчит из ядра наружу) написано, что кардинальность этой связи — 1.

В DDD это модель внутри изолированного домена, к которой никто доступа не имеет, кроме как через контракты на внешних слоях. Соответственно, изменение этой модели никак их сломать не может.
Ну, отлично, контракт на внешнем слое такой и был — отдавая ордер, мы обязуемся иметь в нём непустой SubscriptionID.
У этого контракта примерно полторы сотни потребителей.
PJ>Оно перестало быть справедливым в рамках одной модели. Остальные эти изменения даже видеть не должны, как и саму модель.
Я не понимаю, как можно писать полезный код в рамках такого подхода.
Вот у нас нашу систему начинали писать архитектурные пуристы, вроде вас. В итоге мы получили такую чудесную штуку, что операционная часть ничего не знает про деньги, а бизнес-часть ничего не знает про сервисы.
Всё как вы любите
В итоге мы только в 2020 году со скрипом, постепенно, через несколько волн болезненного рефакторинга, получаем вещь, которую клиенты просят с 2005 года — отчёт, где каждый платёж привязан к идентификатору сервиса.
Ну там, банально — продаём лицензии на продукты Microsoft и Autodesk; люди хотят отчёт, где в каждой строчке кроме суммы и количества написано не только "Microsoft" или "Autodesk", а чтобы конкретно — Microsoft 365 Business Premium или Revit 2020 Pro. Полтора десятилетия это оставалось невыполнимым, потому что изнутри OSS нельзя узнать ничего про суммы, а изнутри BSS нельзя ничего узнать про сервисы — изоляция-с.

PJ>Ну ты уже определись модель у тебя или предположения. Если есть модель, то никакие предположения не нужны.
Есть модель, построенная на основе каких-то предположений. Как и любая модель — она берётся не из воздуха, а из анализа предметной области. Расширяя предметную область, мы регулярно натыкаемся на то, что сделанные нами ранее предположения перестают быть справедливыми. Если нам везёт, то от этих частей модели мало что зависит — какой-то изолированный, никому не нужный модуль запросто можно перепилить и никого не сломать.
Иногда изменения очевидные и инкрементальные — ну, умели мы раньше отправлять отчёты по почте в виде .csv и в виде .html, допилили рендер в PDF. Всё отлично, поменялась только та часть, которая касается настроек рассылок. Все остальные модули либо безразличны к формату, либо продолжают отправлять в том формате, в котором отправляли раньше.
А "ядро" модели, которое используется двумя из трёх модулей, как ни крути, а торчит в слишком много мест для того, чтобы его можно было легко и безболезненно менять.

S>>И, возвращаясь к теме беседы, кажный раз бросаться грудью на амбразуру и честно вносить эти изменения может привести к убыткам, а не к прибыли.
PJ>Так я с этого и начал. Система доведена до состояния когда любые изменения вносить страшно, потому что сломается непонятно где и непонятно что.
Почему непонятно-то? Как раз очень даже понятно. Понятно, что какие-то изменения стоят очень дорого. Пример я вам привёл.
PJ>Это и есть технический долг, просто другого вида. И если его не уменьшать постоянно, то система вот до такого и доходит.
Вот реально, хотел бы я посмотреть на ваш код. Пока что больше похоже на красивую сказку. При этом банальная штука "сделать запись конфигов атомарной", которую на первый взгляд можно решить просто добавив 1 строчку кода в то место, где сохраняется файл, требует у вас "рефакторинга", полной замены модуля persistence, полной замены способа, которым другие модули взаимодействуют с этим модулем, и называется "фичей".
Ну, хорошо, коли вас это устраивает.

Здравствуйте, Sinclair, Вы писали:

PJ>>Странные у вас какие-то задачи. В acceptance criteria написано, что должно быть в этом отчете.
S>Ну ок. Откуда берутся эти acceptance criteria?
От product onwer, разумеется.

PJ>>Каком порядке это делаю разработчики вообще не проблема менеджмента. Либо это две разные задачи со своими AC. В этом случае разработчик должен понимать смысл приоритетов, в каком порядке их делать и возможно ли это вообще.
S>Вот здесь под словом "делать" вы что имеете в виду — написание кода, или таки порядок выдачи?
Что значит порядок выдачи? Ты назвал одну задачу "отчет в pdf" как ее можно выдать, если половина не сделана?

S>Именно менеджер принимает решение, что и в каком релизе выходит.
Решает ага. Я только не понял в каком месте я с этим спорил?

PJ>>Причем тут вообще топ-менеджер?
S>Мы же говорим про планы компании, а не мелкого департамента на пару-тройку десятков человек.
Ну, блин, планы компании с точки зрения проблем конкретной команды. Я полагал это очевидно из контекста. Планы перекраски фасада их надо полагать не интересуют. Совершенно не обязательно сводить дискуссию к глупостям.

S>Отлично, давайте поговорим про продакт менеджеров. Может, ваши продакт менеджеры обсуждают с разработчиками планы на годы вперёд — у нас такое бывает редко.
А кто говорил про ГОДЫ вперед? Достаточно и года.

S>Обычно планировать хоть что-то дальше полугода не имеет никакого смысла — все тщательно продуманные планы придётся выбросить уже через три месяца, потому что бизнес-реальность меняется слишком быстро.
Может не стоит натягивать свою сову на общий глобус?

S>Конечно. При этом инструменты пилились ровно в рамках того понимания рефакторинга, который был до них. Поэтому мы не найдём ни в одном инструменте такого рефакторинга, который меняет наблюдаемое поведение кода.
Ну как же не найду-то? Добавить параметр в метод есть уже примерно везде. А это уже влияет на тесты и меняет поведение.

PJ>>Конечно широкая, потому как оно для решения проблем, а не для использования в молельном доме в виде библии. Новый файл это внутренне состояние в данном случае. Клиенты эти файлы не видят и даже не знают о их существовании.
S>Раз они их не видят и не знают, то и фичи никакой нет. Простите, в нашем продукте всё запущено — я в жизни не стану представлять клиентам штуку типа "раньше мы корраптили файлы конфигурации, а теперь перестали" как фичу.
Ну да, если к компу приставить упс, то раньше он выключался при пропадании питания, а теперь перестал — багфикс, че. И нет, это никто не продает как фичу, фичи могут быть и внутренними. Скажем в данном случае это позволяет имея историю изменений калибровки, отслеживать деградацию лампы. Что тоже нафиг не надо клиентам, но полезно нашим инженерам.

PJ>>Противоречие в том, что у тебя это размазано в неявном виде неких предположений по вообще всем местам включая сторонний код.
S>Почему в неявном-то? В самом явном. Прямо в модели (которая торчит из ядра наружу) написано, что кардинальность этой связи — 1.
Потому что неявно подразумевается ее неизменность, что очевидно не так. Не говоря уж о том, что просто нельзя выставлять наружу.

S>Ну, отлично, контракт на внешнем слое такой и был — отдавая ордер, мы обязуемся иметь в нём непустой SubscriptionID.
S>У этого контракта примерно полторы сотни потребителей.
И? Пусть они на нем и живут. Появиться второй контракт для отдельной покупки. Он даже придет в тот же порт, но уже в другое место, к другому обработчику, который знает что с этим делать. Полагаю, следующий рояль в кустах это странно использование этой подписки всеми, вместо дериватива операции оплаты.

PJ>>Оно перестало быть справедливым в рамках одной модели. Остальные эти изменения даже видеть не должны, как и саму модель.
S>Я не понимаю, как можно писать полезный код в рамках такого подхода.
Чем я тут могу помочь? Слушать или слышать ты особенно не хочешь. Попробуй почитать книжки по DDD, например.

S>Вот у нас нашу систему начинали писать архитектурные пуристы, вроде вас. В итоге мы получили такую чудесную штуку, что операционная часть ничего не знает про деньги, а бизнес-часть ничего не знает про сервисы.
S>Всё как вы любите
Это я сильно сомневаюсь. Ну может там бизнес часть чего и не знала, я сомневаюсь на счет всего остального.

S>В итоге мы только в 2020 году со скрипом, постепенно, через несколько волн болезненного рефакторинга, получаем вещь, которую клиенты просят с 2005 года — отчёт, где каждый платёж привязан к идентификатору сервиса.
S>Ну там, банально — продаём лицензии на продукты Microsoft и Autodesk; люди хотят отчёт, где в каждой строчке кроме суммы и количества написано не только "Microsoft" или "Autodesk", а чтобы конкретно — Microsoft 365 Business Premium или Revit 2020 Pro. Полтора десятилетия это оставалось невыполнимым, потому что изнутри OSS нельзя узнать ничего про суммы, а изнутри BSS нельзя ничего узнать про сервисы — изоляция-с.
Ну это какая-то чушь, уж извини. Изоляция означает, что нет паразитной зависимости, а не то, что информацию нельзя передавать.

PJ>>Ну ты уже определись модель у тебя или предположения. Если есть модель, то никакие предположения не нужны.
S>Есть модель, построенная на основе каких-то предположений. Как и любая модель — она берётся не из воздуха, а из анализа предметной области. Расширяя предметную область, мы регулярно натыкаемся на то, что сделанные нами ранее предположения перестают быть справедливыми.
Так весь смысл DDD заключается именно в этом. Как иметь модель предметной области, менять ее и при этом не страдать.

S>Почему непонятно-то? Как раз очень даже понятно. Понятно, что какие-то изменения стоят очень дорого. Пример я вам привёл.
Такие изменения стоят очень дорого в система где разработчики любят ходить по граблям. К счастью, это не универсальный закон и всей этой боли можно избежать.
Есть проблема в том, что технический долг может накапливаться медленно и незаметно и наступит момент когда станет дорого, хотя старались делать как лучше. Это понятно. Ну в этом случае приходится делать больший рефакторинг, опять возвращая процесс в нормальное русло. Как-то так.

S>Вот реально, хотел бы я посмотреть на ваш код. Пока что больше похоже на красивую сказку. При этом банальная штука "сделать запись конфигов атомарной", которую на первый взгляд можно решить просто добавив 1 строчку кода в то место, где сохраняется файл, требует у вас "рефакторинга", полной замены модуля persistence, полной замены способа, которым другие модули взаимодействуют с этим модулем, и называется "фичей".
А как сделать если есть разные модули которые пишут в свои файлы, ничего друг про друга не знают (и не должны), но при этот если уж откатываем один, то откатывать надо все? Одной строчкой обойдешься?

S>Ну, хорошо, коли вас это устраивает.
Нас-то как раз все устраивает. Можно добавлять что-то в модель, убирать из модели без боли и регрессий.

Здравствуйте, Poopy Joe, Вы писали:
PJ>От product onwer, разумеется.
Кто такой product owner? Ну, вот на понятном всем примере — кто такой product owner у visual studio?
PJ>Что значит порядок выдачи? Ты назвал одну задачу "отчет в pdf" как ее можно выдать, если половина не сделана?
Почему не сделана? Сделана. И вторая половина сделана. А вот что важнее — отчёт в PDF или интеграция с SAP R3 — решает не программист.

PJ>Решает ага. Я только не понял в каком месте я с этим спорил?
Да всю ветку.

PJ>А кто говорил про ГОДЫ вперед? Достаточно и года.
Слишком много. Вот сейчас мы знаем, что в феврале 2021 у Microsoft выйдет New commerce platform. Точнее, на неё переведут license-based services.
Казалось бы — три квартала всего осталось, надо бечь детально планировать.
По факту: в чём именно состоит этот перевод — никто пока не знает. В том числе и в Microsoft. Они пока обдумывают идеи того, как это будет выражено в API.
Ну, и какая там будет модель по ту сторону API, тоже пока никто не знает.
А значит и смысла ничего планировать нет. Может оказаться, что мы это поддержим за 4 часа работы разработчика, 30 часов регрессии, и 80 часов работы продакт менеджера — по написанию презентаций про то, как мы круто всё поддерживаем.
А может, окажется что они в очередной раз перепилили всё поперёк прежнего, и наше отражение их модели придётся переделывать на 70%.
А может, они перенесут сроки ещё на год — первоначально они собирались всё это в продакшн в феврале 2020.

PJ>Может не стоит натягивать свою сову на общий глобус?
Того же и вам желаю. Делать выводы о том, что у кого-то что-то неправильно потому, что вы имеете роскошь жить в квазистатическом окружении — смело.

PJ>Ну как же не найду-то? Добавить параметр в метод есть уже примерно везде. А это уже влияет на тесты и меняет поведение.
Это у вас какой-то негодный инструмент. В моём инструменте добавление параметра в метод добавит его не только в метод (это я и сам могу без инструмента), а подобавляет его везде, в том числе и в тестах.

PJ>Ну да, если к компу приставить упс, то раньше он выключался при пропадании питания, а теперь перестал — багфикс, че. И нет, это никто не продает как фичу, фичи могут быть и внутренними. Скажем в данном случае это позволяет имея историю изменений калибровки, отслеживать деградацию лампы. Что тоже нафиг не надо клиентам, но полезно нашим инженерам.
Это совершенно нормально — пользователями системы являются вовсе не только клиенты. Но мы опять приходим к тому, что вы ведёте про вполне себе наблюдаемое изменение вашими инженерами изменение внешнего поведения. А стало быть это — обычное, нормальное изменение.
Да, вы даже наверное могли пилить сам код по версионному сохранению вообще в отрыве от остального приложения; а рефакторингом, нужным для интеграции, заняться в конце.

PJ>Потому что неявно подразумевается ее неизменность, что очевидно не так. Не говоря уж о том, что просто нельзя выставлять наружу.
А где вы видели модели, в которых бы кардинальность связей подразумевалась изменяемой?
Ну, и непонятно, что значит "нельзя выставлять наружу". Я себе не представляю такую систему. Что у вас, каждая-прекаждая ссылка — nullable? В жизни не поверю.

Даже если и так, то это ничему не поможет. Ну, напишем мы в документации на API, что атрибут "подписка" является необязательным.
Люди-то интегрируются не с документацией, а с живой системой. Если они видят, что по факту subscription всегда есть, то они пишут код, который на это рассчитывает.
Сделав атрибут необязательным, мы обманем сами себя. Нам будет казаться, что можно его не задавать, а по факту — такой релиз вызовет массовые отказы кода у клиентов.

PJ>И? Пусть они на нем и живут. Появиться второй контракт для отдельной покупки. Он даже придет в тот же порт, но уже в другое место, к другому обработчику, который знает что с этим делать. Полагаю, следующий рояль в кустах это странно использование этой подписки всеми, вместо дериватива операции оплаты.
При чём тут оплата? Оплата связана с ордером. Второй контракт — это отличная идея.
Вот, был, скажем, контракт "GetAllOrdersForTimePeriod()", который возвращал наши "старые" ордера. Его использовали клиенты для того, чтобы создавать дубликаты ордеров у себя в отчётных системах.
Все работает годами, а потом мы выпускаем новый параллельный контракт, GetAllModernOrdersForTimePeriod(). Типа новые-то ордера мы не можем отдавать через старый — они инварианту не удовлетворяют.
И чем это лучше? У клиента-то обороты стали расходиться — ну, или ему надо перепиливать ту часть своей интеграции, которая отвечает за копирование ордеров.
То есть те же яйца, вид сбоку. Одна радость — наши тесты зелёные. "С моей стороны пули вылетели".
И вот таких мест в нормальной, реальной системе — многие десятки. "другой обработчик" не сконденсируется магическим образом из вакуума, его кто-то должен написать.
Точнее, столько таких "других обработчиков", сколько было "старых" обработчиков.

PJ>Это я сильно сомневаюсь. Ну может там бизнес часть чего и не знала, я сомневаюсь на счет всего остального.

PJ>Ну это какая-то чушь, уж извини. Изоляция означает, что нет паразитной зависимости, а не то, что информацию нельзя передавать.
Не, это реальность.

PJ>Так весь смысл DDD заключается именно в этом. Как иметь модель предметной области, менять ее и при этом не страдать.


PJ>А как сделать если есть разные модули которые пишут в свои файлы, ничего друг про друга не знают (и не должны), но при этот если уж откатываем один, то откатывать надо все? Одной строчкой обойдешься?
Для начала надо попытаться разобраться, зачем откатывать все — ведь они же друг про друга ничего не знают, значит понятие "несогласованность" возникнуть никак не может.
Если получается так, что они себя ведут некорректно, если у одного конфигурация версии 1, а у другого — 2, то значит нет никакой независимости, и вы со своей DDD себя обманываете, вводя иллюзию изоляции.
Дальше, когда мы поняли, что модули на самом деле взаимосвязаны, можно делать рефакторинг — например, дублирующийся код по чтению и записи файлов конфигурации выносим в общий для всех модуль. Если он, по непонятной причине, таки оказался размазан. Рефакторинг хорош тем, что мы гарантированно ничего не делаем хуже: это цепочка инвариантных преобразований кода.

Если нет — то даже рефакторить не нужно: меняем только ту часть, которая работает непосредственно с файлами. Вставляем один дополнительный уровень каталога между нынешним местом хранения и именем файла.
В начале операции "сохранить конфигурацию" каталог получает временное имя; если всё кончилось успешно — переименовываем его в номер версии. Если нет — фиг с ним, останется недописанный каталог с кривым именем.
На старте, при чтении конфигурации, мы выбираем каталог с максимальным номером — в нём живёт гарантированно консистентная конфигурация. Всё.
Всей работы, не считая рефакторинга — на пару часов вместе с написанием тестов и перерывом на кофе.
Наверняка всё гораздо сложнее, потому чт оесть особенности, которые вы опустили. Но со стороны чужие проблемы выглядят именно так.

Здравствуйте, Sinclair, Вы писали:

S>Кто такой product owner? Ну, вот на понятном всем примере — кто такой product owner у visual studio?
https://www.scrum.org/resources/what-is-a-product-owner

PJ>>Что значит порядок выдачи? Ты назвал одну задачу "отчет в pdf" как ее можно выдать, если половина не сделана?
S>Почему не сделана? Сделана. И вторая половина сделана. А вот что важнее — отчёт в PDF или интеграция с SAP R3 — решает не программист.
Что такое вторая половина? Есть задача, есть AC. Какие такие половины, оно либо сделано либо нет.

PJ>>Решает ага. Я только не понял в каком месте я с этим спорил?
S>Да всю ветку.
Ты что-то не так понял или не слушал.

PJ>>А кто говорил про ГОДЫ вперед? Достаточно и года.
S>Слишком много. Вот сейчас мы знаем, что в феврале 2021 у Microsoft выйдет New commerce platform. Точнее, на неё переведут license-based services.
Для вас может много, для нас нормально.

PJ>>Может не стоит натягивать свою сову на общий глобус?
S>Того же и вам желаю. Делать выводы о том, что у кого-то что-то неправильно потому, что вы имеете роскошь жить в квазистатическом окружении — смело.
Квазистатическое окружение тут не причем. У вас неправильно потому, что проблемы там, где их быть не должно.

PJ>>Ну как же не найду-то? Добавить параметр в метод есть уже примерно везде. А это уже влияет на тесты и меняет поведение.
S>Это у вас какой-то негодный инструмент. В моём инструменте добавление параметра в метод добавит его не только в метод (это я и сам могу без инструмента), а подобавляет его везде, в том числе и в тестах.
Вот это точно негодный тул, так как по-определению тест должен упасть, пока ты его не исправишь. Или твой тул еще и тест дописывает?

PJ>>Ну да, если к компу приставить упс, то раньше он выключался при пропадании питания, а теперь перестал — багфикс, че. И нет, это никто не продает как фичу, фичи могут быть и внутренними. Скажем в данном случае это позволяет имея историю изменений калибровки, отслеживать деградацию лампы. Что тоже нафиг не надо клиентам, но полезно нашим инженерам.
S>Это совершенно нормально — пользователями системы являются вовсе не только клиенты. Но мы опять приходим к тому, что вы ведёте про вполне себе наблюдаемое изменение вашими инженерами изменение внешнего поведения. А стало быть это — обычное, нормальное изменение.
Это уже отдельная фича, про нее речи не было, просто как дополнительный пример привел.

S>Да, вы даже наверное могли пилить сам код по версионному сохранению вообще в отрыве от остального приложения; а рефакторингом, нужным для интеграции, заняться в конце.
Я равно это и написал. Вот только эта версионность без рефакторинга смысла не имеет. Я не могу их разделить, если уж каких-то совсем странных вещей не делать, религиозной чистоты ради.

PJ>>Потому что неявно подразумевается ее неизменность, что очевидно не так. Не говоря уж о том, что просто нельзя выставлять наружу.
S>А где вы видели модели, в которых бы кардинальность связей подразумевалась изменяемой?
S>Ну, и непонятно, что значит "нельзя выставлять наружу". Я себе не представляю такую систему. Что у вас, каждая-прекаждая ссылка — nullable? В жизни не поверю.
Ну что ты, у меня вообще nullable нет. F# Нельзя выставлять наружу означает, что нельзя выставлять наружу. Наружу выставляется производная от модели — dto объект. Все в книжках есть, кстати.

S>Даже если и так, то это ничему не поможет. Ну, напишем мы в документации на API, что атрибут "подписка" является необязательным.
Конечно является, это часть контракта. Если тебе нужна подписка, то подписка там быть должна. То, что ты сейчас предлагаешь это опять неявное соглашение и предположения. Я тебе говорю, что в одном api не обязательно смешивать мух с котлетами. Подписки отдельно, покупки отдельно. Инвариант один — модель, где либо подписка, либо покупка, а вот производные разные. Либо даже просто новый контракт, но где явно указано, что либо подписка, либо покупка, с разными dto внутри. grpc так позволяет, например, легко делать.

PJ>>И? Пусть они на нем и живут. Появиться второй контракт для отдельной покупки. Он даже придет в тот же порт, но уже в другое место, к другому обработчику, который знает что с этим делать. Полагаю, следующий рояль в кустах это странно использование этой подписки всеми, вместо дериватива операции оплаты.
S>При чём тут оплата? Оплата связана с ордером. Второй контракт — это отличная идея.
Подписка или покупка это оплата, разве нет? Я только гадать могу о твоей задаче, ты ее не расписал.

S>Вот, был, скажем, контракт "GetAllOrdersForTimePeriod()", который возвращал наши "старые" ордера. Его использовали клиенты для того, чтобы создавать дубликаты ордеров у себя в отчётных системах.
S>Все работает годами, а потом мы выпускаем новый параллельный контракт, GetAllModernOrdersForTimePeriod(). Типа новые-то ордера мы не можем отдавать через старый — они инварианту не удовлетворяют.
S>И чем это лучше? У клиента-то обороты стали расходиться — ну, или ему надо перепиливать ту часть своей интеграции, которая отвечает за копирование ордеров.
Опять не могу комментировать, поскольку я не знаю, что там содержится и что клиенту от них надо. Если клиенту важно знать про покупки, то ему надо переписывать, чтобы получить релевантную информацию. Если клиенту это несущественно, то клиенту надо было слать не ордера, а опять же их производные, где возможно и нет разницы между покупкой и подпиской.

PJ>>Ну это какая-то чушь, уж извини. Изоляция означает, что нет паразитной зависимости, а не то, что информацию нельзя передавать.
S>Не, это реальность.
В чем тут реальность? Как это сделать описано в DDD. Реальность в том, что ты не будешь их читать?

PJ>>А как сделать если есть разные модули которые пишут в свои файлы, ничего друг про друга не знают (и не должны), но при этот если уж откатываем один, то откатывать надо все? Одной строчкой обойдешься?
S>Для начала надо попытаться разобраться, зачем откатывать все — ведь они же друг про друга ничего не знают, значит понятие "несогласованность" возникнуть никак не может.
То, что они ничего друг про друга не знают, не означает, что система не зависит от их согласованности. Есть допустим 4 камеры, которые формируют картинку. Камеры независимы. Т.е. если одну убрать, то картинка будет из трех, это не проблема. Проблема в том, что баланс белого должен быть у всех одинаковый. Если инженер провел рекалибровку и один из файлов сдох, то откатывать надо все, иначе изображение будет некорректным. Пока версионности не было, не было и такой проблемы, было одно состояния в одной версии файла у каждого устройства.

Здравствуйте, Poopy Joe, Вы писали:

PJ>>>Ну это какая-то чушь, уж извини. Изоляция означает, что нет паразитной зависимости, а не то, что информацию нельзя передавать.
S>>Не, это реальность.
PJ>В чем тут реальность? Как это сделать описано в DDD. Реальность в том, что ты не будешь их читать?

Невежливо, конечно, мне встревать в чужой разговор, но поскольку комраду Sinclair гордость не позволит
ответить на этот вопрос утвердительно, то я дерзну ответить за него.
С большим интересом бы посмотрел на список книг. При условии, что это не топ-тен с амазона/озона,
а именно те книги, которые вы прочитали, и из которых сложилось ваше понимание DDD.

Здравствуйте, SergASh, Вы писали:

SAS>Невежливо, конечно, мне встревать в чужой разговор, но поскольку комраду Sinclair гордость не позволит
SAS>ответить на этот вопрос утвердительно, то я дерзну ответить за него.
SAS>С большим интересом бы посмотрел на список книг. При условии, что это не топ-тен с амазона/озона,
SAS>а именно те книги, которые вы прочитали, и из которых сложилось ваше понимание DDD.
Вот с этой начинай, не ошибешься. https://pragprog.com/book/swdddf/domain-modeling-made-functional
Посмотрел на амазоне, в топ входит, тут уж сам смотри.

Здравствуйте, Poopy Joe, Вы писали:

PJ>>>Что значит порядок выдачи? Ты назвал одну задачу "отчет в pdf" как ее можно выдать, если половина не сделана?
S>>Почему не сделана? Сделана. И вторая половина сделана. А вот что важнее — отчёт в PDF или интеграция с SAP R3 — решает не программист.
PJ>Что такое вторая половина? Есть задача, есть AC. Какие такие половины, оно либо сделано либо нет.
Ну вот и я не понимаю, о чём вы говорите, когда пишете, что половина не сделана.

PJ>Квазистатическое окружение тут не причем. У вас неправильно потому, что проблемы там, где их быть не должно.


PJ>Вот это точно негодный тул, так как по-определению тест должен упасть, пока ты его не исправишь. Или твой тул еще и тест дописывает?
Ясно. Вижу, что рефакторинг вы видели только по телевизору. Ознакомьтесь, с тем, как работают реальные, а не воображаемые инструменты: https://www.jetbrains.com/help/resharper/Refactorings__Introduce_Parameter.html
Добавление параметра поправит все call sites, включая, естественно, тесты. А иначе нахрена такой рефакторинг нужен?

PJ>Это уже отдельная фича, про нее речи не было, просто как дополнительный пример привел.


S>>Ну, и непонятно, что значит "нельзя выставлять наружу". Я себе не представляю такую систему. Что у вас, каждая-прекаждая ссылка — nullable? В жизни не поверю.
PJ>Ну что ты, у меня вообще nullable нет. F# Нельзя выставлять наружу означает, что нельзя выставлять наружу. Наружу выставляется производная от модели — dto объект. Все в книжках есть, кстати.
(facepalm). Ну ок, пусть будет DTO объект. У нас, к примеру, всё выставлено наружу как JSON. И у этого JSON есть модель — schema. Она, естественно, соответствует той модели, которая внутри. И в этой схеме сказано, что подписка — обязательный атрибут.

PJ>Конечно является, это часть контракта. Если тебе нужна подписка, то подписка там быть должна. То, что ты сейчас предлагаешь это опять неявное соглашение и предположения. Я тебе говорю, что в одном api не обязательно смешивать мух с котлетами. Подписки отдельно, покупки отдельно. Инвариант один — модель, где либо подписка, либо покупка, а вот производные разные. Либо даже просто новый контракт, но где явно указано, что либо подписка, либо покупка, с разными dto внутри. grpc так позволяет, например, легко делать.
Да при чём тут grpc? Вы говорите про самый низкий уровень, неинтересные детали. Речь о том, что от изобретения нового контракта никакая магия не сделает всех клиентов старого контракта совместимыми с новым.
И вы никаким образом не сохраните инварианты старого контракта — банальный GetBalance, который вроде бы не изменился по сигнатуре, теперь не может возвращать сумму, которая совпадает с суммой всех ордеров.

PJ>Подписка или покупка это оплата, разве нет? Я только гадать могу о твоей задаче, ты ее не расписал.
Оплата — это передача денег. Ордер — это заказ. Если, допустим, пользователь Poopy Joe что-то заказал на 100 долларов, то его баланс уменьшился на 100 долларов.
Если пользователь заплатил 200 долларов, то его баланс увеличился на 200 долларов. Это вещи, мало связанные между собой.
Есть понятные любому менеджеру инварианты: баланс Джо равен сумме всех его платежей минус сумма всех заказов (пренебрегаем коррекциями).
Введение нового типа заказа означает, что либо мы ломаем сигнатуру методов по получению заказов, либо у нас ломается инвариант баланса.
Естественно, сломать сигнатуру методов — более хороший способ: таким образом мы получаем fail fast, и несовместимые клиенты падают сразу. А не продолжают молча рассинхронизовывать данные, приводя к утечке денег.

PJ>Опять не могу комментировать, поскольку я не знаю, что там содержится и что клиенту от них надо. Если клиенту важно знать про покупки, то ему надо переписывать, чтобы получить релевантную информацию.
Да, именно об этом и речь — надо переписывать.

PJ>В чем тут реальность? Как это сделать описано в DDD. Реальность в том, что ты не будешь их читать?
В том, что чудес не бывает, и если мы меняем модель, то это дорого стоит. Поэтому иногда приходится пожертвовать красотой модели, и втиснуть новую функциональность в неудобные рамки. Иногда даже жертвовать какими-то из требований.
И только потом, когда мы выясним, является ли это нововведение полезным, и насколько, мы будем осознанно принимать решения о возврате технического долга.

PJ>То, что они ничего друг про друга не знают, не означает, что система не зависит от их согласованности. Есть допустим 4 камеры, которые формируют картинку. Камеры независимы. Т.е. если одну убрать, то картинка будет из трех, это не проблема. Проблема в том, что баланс белого должен быть у всех одинаковый. Если инженер провел рекалибровку и один из файлов сдох, то откатывать надо все, иначе изображение будет некорректным. Пока версионности не было, не было и такой проблемы, было одно состояния в одной версии файла у каждого устройства.
Ну, не было так не было. Хотя как я понял, версионность как раз была решением, а не проблемой. Впрочем, я уже понял, что мы с вами не договоримся — вы называете багфикс фичей, дополнение рефакторингом, а решение — проблемой. Ну, ваше право, чо. Не удивляйтесь только, что все остальные вас не понимают

Здравствуйте, Codealot, Вы писали:

_AB>>Да. Я с вашим братом часто общаюсь.
C>С каким таким нашим братом? Ты не стесняйся, рассказывай.
Глупым демагогом.

_AB>>Не хочешь — дело твоё, мне абсолютно пофиг.
C>Явно не пофиг, судя по тому, как часто ты ко мне цепляешься. Опять врешь.
Я не к тебе цепляюсь, а к той глупости, что ты распространяешь. Да, есть у меня такое — не терплю глупость других. Своей хватает.

C>"Все так делают" — очень хреновый аргумент.
Это нормальный аргумент для суда. Сложившаяся практика, все дела.

C>Одно положение закона делает неработоспособным другие. Для тебя новость, что такое может происходить?
Одно положение закона уточняет другие пункты. Так будет точнее. Насколько я помню, там просто было весьма точное определение, которое ты хотел бы толковать намного шире, чем предусмотрено законом.

_AB>>У меня другая специализация.
C>Слив засчитан.
Детский сад, штаны на лямках...

C>Какой конкретно области? Получении положительных оценок на этом конкретном сайте?

Открой, да посмотри. Или, как все гордые программисты, считающие, что они — пупы земли и соль народа, не умеешь работать с информацией?

C>Non sequitur. Это к вопросу о рациональном мышлении.
То, что ты нагуглил два латинских слова, не означает, что ты что-то доказал и уж тем более, что ты опроверг мои высказывания, не связанные с этим предложением...

У тебя нет постов, подтверждающих твою квалификацию, твои определения расходятся с общепринятыми, твои рассказы о том, что все твои начальники тупые, один ты умный — это всё поведение балабола, а не профессионала средней или высокой квалификации, уж извини.

C>Врёшь, ты делал это минимум два раза.
C>

C>1. Пока всё твоё поведение доказывает, что болезни, которые ты себе приписываешь, тебя не касались в принципе
C>2. Ты пытался избавиться от вопросов, определяющих твою профессиональную квалификацию, прикрываясь инвалидностью

У тебя всё очень плохо с мышлением, знаниями и чувством языка.

Первый пункт — мои сомнения в твоих болезнях. Удачи доказать в суде, что слова "пока всё твоё поведение доказывает" являются не мнением с изрядной долей сомнения, а обвинением. Ни один лингвист тебе такого заключения не даст.

Второй пункт вообще не касается того факта, является ли твоя инвалидность реальной или мнимой. Тут есть мнение, что ты пытаешься избавиться от вопросов, определяющих твою квалификацию, прикрываясь инвалидностью. А реальная она, или мнимая в этом случае — к делу это вообще не относится.

C>Кстати, ты опять не ответил на прямой вопрос, который я тебе задал.
Я не обещал, что буду отвечать на все твои вопросы.

C>Повторю вопрос: "Пока всё твоё поведение доказывает, что болезни, которые ты себе приписываешь, тебя не касались в принципе" — это каким образом?
Твои слова куда более присущи самовлюбленному нарциссу, при том, что ты сам утверждаешь, что болезни, которые ты себе приписываешь, абсолютно несовместимы с таким поведением. Я решил тебе поверить в этом утверждении. Зря?

Здравствуйте, Ikemefula, Вы писали:

I>Нет, не любые. Менеджер, даже пиэм, может быть плохим по самым разным причинам. Например, пить водку вместо работы.

Ни одного такого не встречал. А любителей микроменеджмента — очень много, с самым разным бэкграундом.

I>Очевидно — нет. Есть общая зона ответствености, пересечение. И это не код.

А что, уже научились создавать программы без написания кода? В нашей индустрии, нет кода — нет никакого business value. Точка.