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

S>Это я пытаюсь использовать ваши же определения, чтобы вас понять.
Угу, я вижу...

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

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

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

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

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

S>Да-да. Пример Netscape отлично показывает, что бывает с теми, кто решил "написать заново".
S>Пример Edge — тоже. Что у нас там ещё на плаву осталось? Ткните пальцем в браузер, который выиграл от идеи "написать заново".
Т.е. не начни МС edge, так бы все и пользовались IE? Никто не гарантирует усхпеха, гарантия только на то, что старье сдохло и править его бесполезно.
Я могу ткнуть пальцем в себя, как раз в такой ситауации. Частично благодаря ситуации выше, новый продукт перезапустили с нуля, спросив что вам мешает делать быстро и чего не хватает и дав на все зеленый свет и волю инженерам, а не "параноидальным" менеджерам. Так и F# там появился. И спустя несколько лет всем (причастным внутри) очевидно, что у нас самый легко развиваемый продукт, на точность сроков и качество в котором можно положиться. И сейчас те же топы, которые тогда ссали на ляжки, очень радуются своему решению.

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

class BatchOrderResponse 
{
 List<Order> orders;
 BatchOrdersSignature batchSignature;
 ExpectedAllBatchesSignature totalSignature;
 Counter counter; // если надо. итд...
}

class API
{
 GetOrderBatch(...)
 GetAllOrders()
 ValidateSignature(List<BatchSignature>, totalSignature)
}

S>что один ордер не может быть вёрнут и GetOrderBatch(1) и GetOrderBatch(2),
Гарантировать это сервер должен. Ответом это только проверить можно.

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

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