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

S>Опять: для очень широкого класса приложений это не так. Веб приложения вообще по умолчанию рестартят каждые 15 минут.
Зачем же они тогда перезапускают? Очередной костыль и есть.

S>Тут самое время задаться вопросом: если намерения починить баг не было, но он таки починился — это что же, разработчик не понимал, что он делает?
Ну, допустим, есть мультипоточный спагетти код, в котором уже пару лет не могут поймать какой-то баг, как это часто бывает.
Работать с этим тяжело всегда, независимо от бага. Ну вот разработчик вместо ковыряния в говнокоде просто переписывает его нормально. Баг исчезает. Что разработчик сделал неправильно?

S>Ну, ок, один баг он починил. А сколько добавил?
Ну этого ты никогда не знаешь, даже при самом безобидном изменении. Опять получается, что рефакторинга нет?

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

S>Добро пожаловать в реальный мир, Нео. Я когда впервые читал статью про то, что MS часто вместо респина релиза выкладывает KB, тоже был сильно удивлён.
Ну это-то как раз нормально. Невозможно выпустить релиз вообще без дефектов. Ты это подал как часть нормального процесса. Типа не будет на это внимание обращать, просто KB сделаем. Это совсем не то же самое, что респин релиза.

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

S>Да, конечно. Любой софт должен решать поставленные перед ним задачи. Вот вы действуете в молчаливых предположениях, что можно точно знать все сценарии использования публичного АПИ.
Это не то, что я сказал. Я бы выставлял API для конкретных сценариев. Там нет никаких предположение, по-определению. Уж точно я бы не стал выставлять модель, чтобы делали что хотели.

S>Возможно, для какого-то системного софта это так и есть (неспроста же производители железа дают доступ к своим datasheet вовсе не всем подряд). А для обычного гражданского прикладного софта — вроде того, который нас окружает в повседневной действительности — это недостижимая утопия.
Достижимо, разумеется. Что тут недостижимого?

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

S>А вот если вас соединят вместо сбербанка с ИК-18, то это ай-яй-яй.
Как человек 15 лет проработавший в телекоме ответственно заявляю — ниче не будет, все это байки из склепа.

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

S>Мы говорим про разную аккуратность. Как ни крути, а программа с catch(Exception e) { log.Write(e)} короче, чем программа с 10 сatch на разные типы исключений.
Нет, конечно, не короче. После этого будет еще три экрана спагетти кода, чтобы разрулить ситуацию. Ведь, де-факто, операция тут провалилась и по этому поводу не сделано ничего.

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

S>Кто стоит между недоумками и конечными потребителями, корректируя недоработки детишек из Бельвью и Редмонда.
Ну ща ты договоришь до того, что МС живо только благодаря вам.

S>В рамках рефакторинга — нет. У нас не F#, безумцев, которые в рамках рефакторинга будут менять схему раскладывания задач по потокам, нету.
Ну там мне вас жаль. Если вижу запрос нескольким узлам, который выполнен последовательно, когда может быть параллельным, то я это сразу исправлю. В 99% это две строки изменений. У вас должно быть это планирование за три месяца с привлечением дюжины экспертов.

S>Ну там, простейшая штука — конвертируем trial to paid. С точки зрения пользователя это одно событие "разместить change order, указав новый период подписки и нужное количество лицензий". А в системе это два разных события "period change" и "quantity change". И ядру всё равно, в каком порядке посылать, а микрософту — нет, потому что у триалов изменять количество нельзя.
S>Поэтому когда на стороне ядра системы делается рефакторинг, в результате которого порядок этих событий из (непреднамеренно) детерминированного становится случайным, внезапно отваливаются некоторые привычные сценарии.
Я вижу только пренебрежение инвариантами и зависимость от сайд-эффектов. Рефакториг тут вообще не причем.

S>(На всякий случай поясню: ядро системы — не на дотнете. У нас с ним вообще нет общей кодовой базы; и нет никакого build tool, который бы запустился и сказал "ой, у вас тут несоответствие типов — один из модулей использует ваши события вот таким способом).
Не имеет значения. Бизнес логика твоя, то и инварианты твои. Все что приходит извне заведомо подозрительное и подлежит обработке. Логика в принципе не должна зависеть от сторонних эффектов.

S>В нынешнем состоянии продукта большинство багов — это результат изменения внешней системы. Типа того же Microsoft, который в какую-нибудь из пятниц выкатывает breaking change без предупреждения.
Да ну прям. Вот прям свободный от внутренних багов бэклог? Осётр все больше...

S>Ну да. Но при этом вы почему-то уверены, что мы делаем всё неправильно.
Т.е. ты считаешь, что превращать продажу в подписку это правильно?

S>А им не нужен totals как таковой. Нужна гарантия, что если через систему прошло 11 миллионов долларов, то у нас должны выдаваться ордера на всю эту сумму.
S>Ну ок, мы можем выдать им отдельную операцию GetOrderTotals — толку-то? Ей всё равно придётся выбирать, с чем быть консистетной — с суммой всех ордеров или с суммой ордеров подходящего для GetOrdersV1 типа.
Я не могу сказать что тут ок, а что нок, поскольку я не знаю сценариев. Судя по всему вы и сами не знаете. В этом и суть проблема.
В виде спекуляции: если бы вы выдавали изначально не номер подписки, а просто абстрактный uuid, который привязана к подписке, но не является подпиской. Т.е. клиент не знает подписка это или нет, просто некая транзакция. Так и проблемы бы такой не было. Для покупок бы вставляли другой тип id.

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


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

S>Ок, давайте. Выразите явно в контракте тот факт, что сумма от IEnumerable<Order> GetOrders() совпадает с суммой от IEnumerable<Invoice> GetInvoices().
Не, ты пытаешься не пересмотреть правильность своего решение, а доказать, что вот в вашем API по другому не выйдет. Я не убежден, что изначально API верный.

S>Ещё раз подчеркну: это — совершенно нормальные, типичные для индустрии административные трудности. Очень легко рассуждать с позиции кодера: "да я внесу изменение в наш клиент к этому API за 15 минут".
S>Ну, так в наш код и я внесу, хоть я и менеджер — дальше-то что?
Ну так и внеси, а не запускать процесс на 5 недель.

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