Здравствуйте, Poopy Joe, Вы писали:
S>>Двоемыслие детектед.
PJ>Это у тебя двоемыслие. Выше ты доказывал, что память это нефункциональное требование, а сейчас, внезапно, их изменении.
Это я пытаюсь использовать ваши же определения, чтобы вас понять.

PJ>У нас, да и никто в здравом уме, не считает лик или еще какие баги функциональными требованиями.
Да ладно? Пять постов выше вы мне доказывали, что отсутствие лика — это самое что ни на есть функциональное требование.
Надоедают мне ваши ёрзания.

PJ>Если в результате рефакторинга они просто пропадут, то это хороший, годный, рефакторинг, если добавятся, то poorly done. Вот и все хитрости.


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

PJ>У нас не веб и вот прямой аналогии не получится. У нас производство и если в результате обновления, или ошибки, или фазы луны, у клиента это встанет, то они могут выставить требование на компенсацию ущерба нам. У нашего подразделения прям вот такого не было, но у соседей, я слышал выставляли требование на 400+к, не знаю чем там там кончилось. И это один клиент только.
Ну вот видите. Это примерно то, чего и следовало ожидать. А вы продолжаете строить из себя девочку и говорить "ой, я не понимаю, как это из-за breaking change может кто-то пострадать финансово", и "вывсёврёти, никаких сотен тысяч не будет". При этом у вас же у самих один клиент может встрять на полмиллиона. Специфика веба — только в том, что одним обновлением можно положить не одного клиента, а сразу десятки и сотни.
Даже если клиент не выставил требования вашей компании — это не повод гадить ему в profit and loss report. И любой сотрудник с правом принятия решений должен это понимать.
А не говорить "да откуда там у них 400к — что они, не могут копеечное изменение на своей стороне внести?". "Они что, идиоты — не могли прочитать инструкцию от API?". "Я же ясно написал в сигнатуре — Option<float>, ну и что, что предылущие 15 лет оно никогда Nothing не возвращало".

PJ>А как это еще понять? Я так понимаю, что у нас копеечные деньги, по вашим меркам, поэтому инженеры борзые, а у вас триллиарды, поэтому цена ошибки высокая, но есть изоляция, т.е. инженеры про деньги ничего не знают, но почему-то все равно осторожные.
Да всё вы понимаете, просто вертитесь, как уж на сковородке.

PJ>А я тебе пытаюсь объяснить, что это принципиально не то же самое. В первом случае ты говоришь это подписка. Если приходит подписка с пустым ид, не неподписка, это невалидный тип. Ты нарушил инвариант. Уж лучше в этом случае изобретать бесконечную подписку.
PJ>Во втором случае это просто данные об ордере. Туда всегда можно добавить тип ордера. Это просто динамические данные, ты ничего никому не обещал — инвариант не нарушен.
Омг. Тот же самый инвариант можно получить, просто сделав атрибут "подписка" nullable. Ровно тот же — никто никому ничего не обещает. И оба варианта имеют в длинной перспективе примерно отрицательную полезность.
Отрицательность берётся из того, что имея в API non-nullable SubscriptionID мы хотя бы понимаем, что замена его на nullable — это breaking change, и что надо соблюдать осторожность. Это наш "нулевой" уровень ценности.
А когда у нас есть nullable subscriptionID, или мета-апи типа GetAllProperties, или ещё какая порнография с целью помешать клиенту увидеть наличие связи между ордером и подпиской в модели, то у нас может возникнуть иллюзия о том, что изменение будет non-breaking. Понимаете?
Это как бумажный забор вдоль пропасти: если его нету, мы хотя бы будем идти там аккуратно. А когда есть бумажная стена, изображающая бетон, то мы рискуем смело опереться на неё и спикировать вниз. Ваше понимание проблемы — на уровне "да ну, откуда там пропасть, в худшем случае — неудобная обочина".

PJ>Я понял твою боль, что ваши клиента на таки мелочи забивают и смотрят на данные. Но тут уж ничего не сделать, это ошибка на их стороне.
Отож. Пусть попадают на 400к. Главное, что мы молодцы — успешно провели рефакторинг, инварианты сохранены. Пусть найдут того, чья эта ошибка, и лишат его премии. На сто лет вперёд.

PJ>Бывает конечно. Когда проще написать заново, чем изменять то, что есть. Вот хоть бразузеры возьми, теме тебе должна быть близкой.
Да-да. Пример Netscape отлично показывает, что бывает с теми, кто решил "написать заново".
Пример Edge — тоже. Что у нас там ещё на плаву осталось? Ткните пальцем в браузер, который выиграл от идеи "написать заново".

PJ>Я не говорил про текстовое описание, я говорил про тип. У тебя опять заготовленный ответ из будущего?
Тогда я не понимаю, что именно вы предлагаете "прочитать" в предыдущей фразе. Давайте так: вы приведёте сигнатуры API в каком-то понятном виде. Можно в виде интерфейса C# — имена, параметры, типы.
Его относительно легко вытащить наружу хоть как SOAP, хоть как JSON/REST, хоть как XML-RPC, поэтому деталями сериализации можно пренебречь.

И мы поймём, достаточно ли сигнатуры для того, чтобы делать глобальные выводы вроде того, что один ордер не может быть вёрнут и GetOrderBatch(1) и GetOrderBatch(2), или что цепочка вызовов таких методов вернёт нам полную коллекцию.

PJ>Я, возможно, не очень, прости, понял ситуацию. Но я понял так: вы являетесь посредником между МС и вашими клиентами. Иначе бы клиенты разбирались напрямую с МС. У вас и сделано по феншую, по крайней мере как его понимаю я. Этот код только между МС и вами. Вы не просто ему не доверяете, для вас это просто входной параметр, который вы мапите уже на свой error code, в своей модели. И вот уже производную своей модели вы отдаете клиенту. В результате три раза за два года клиент получает ошибку "unknown error code from MS", до момента пока вы не исправите маппинг в своей модели, но и все. Никаких изменений клиенту не требуется, как и никаких затрат. Где проблема?
Клиент получает ошибку не три раза за два года, а три раза за два года происходит факап.
Выглядит он примерно так: в полусотне мест в мире заказы начинают падать с ошибкой "происходит непонятная фигня". По статистике мы знаем, что от 2% до 5% заказов валятся именно из-за того, что микрософту не нравится адрес.
Пока наш код отрабатывает успешно, пользователь видит понятное сообщение, исправляет ошибку, и переотправляет заказ.
Когда наш код перестаёт понимать, что происходит, это выглядит так, что "что-то пошло не так". Часть пользователей просто разворачивается и идёт делать заказ в другое место. Часть пользователей обращается в саппорт.
Саппорт долго и мучительно выясняет, что же там сломалось. Напомню: падает не один заказ! Падает каждый 20й заказ, а поток идёт плотный.
Допустим, саппорт конкретного партнёра достаточно быстр, чтобы раскопать причины проблемы и сообщить нам за сутки (это утопия, но чоб не пофантазировать).
Мы, в свою очередь, берём руки в ноги, воспроизводим проблему, убеждаемся, что всё понято верно. Пишем тикет в Микрософт, дескать, "что за фигня происходит". С их саппортом быстрее, чем через неделю, ничего не добьёшься.
Поэтому мы, естественно, параллельно правим наш код. Теперь он умеет парсить и старый и новый форматы — потому что мало ли что, они могут и откатить такое изменение.
Занимает это, оптимистично, ещё сутки. Вот у нас готов хотфикс. Самый-самый отважный партнёр готов накатить хотфикс "вот прямо сейчас", то есть сегодня в стейджинг, и завтра — в продакшн.
Менее отважные сначала проведут тестирование регрессии, а на прод поставят только в выходные.
То есть в течение минимум трёх дней у полусотни партнёров каждый 20й заказ фейлится. Каждый из этих фейлов потребует вмешательства саппорта — а это стоит денег.
Нашими затратами на выпуск хотфикса для такой проблемы можно и пренебречь — они однократны. А вот стоимость ручной обработки всех этих фейлов и развёртывания апдейтов заставляет денюжку капать.
Теперь надо вспомнить о том, что помимо наших партнёров есть ещё и другие — смельчаки, которые работают с этим АПИ напрямую. Вот эта вот работа по выяснению подробностей, экспериментам, переписке с MS, внесению правок в код и тесты для него — у них она не делится на всех, как у наших партнёров, а проводится каждым из них независимо. Поэтому кумулятивный ущерб быстро растёт.

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

Я не жалуюсь на MS — я привожу вам пример того, как делать не надо. В этом примере мы играем на стороне потребителей API.
Когда мы выступаем на стороне поставщиков API, мы стараемся действовать по категорическому императиву Канта — не делать с нашими клиентами того, что нам не нравится в действиях МС.
А вы принимаете это за "боязнь всего нового" и прочие диагнозы по фотографии.

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

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