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

PJ>Я вообще не понял причем тут этот ответ? От факта существования не-функциональных требований не меняется факт, что функциональные требования могут быть любые. Это ортогональные вещи.
При том, что требования к потреблению памяти и быстродействию обычно относят к нефункциональным.

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

PJ>Без понятия. Продукту более 20 лет, меня там не стояло. Думаю, если в первой версии и не было, то в следующей уже было.

PJ>Я не знаю, что означает фраза "реальная задача." Любая задача где программа захватывает данные должна предполагать, что их куда-то надо писать. От фотокамеры и телефона, до рабочих станций.
Угу.

PJ>Это какой-то метод 80х годов, типа водопад. В 2020 если ситуация не описана, а проблема есть, то ее просто обсуждают и добавляют в требования формальное описание. Взять тот же место на диске. У тебя есть функция записи она что-то возвращает и, возможно, ошибку, то эту ошибку (ну, если писать нормально, а не просто кидать исключения в надежде, что кто-то их где-то поймает) мне надо обработать, хотя бы просто окошко пользователю показать, потому что операция провалилась. А если пользователю что-то показывается, то это неплохо бы перевести. Итд итп. И вот она уже в требованиях.
Это если у нас есть ресурсы на это улучшение. На практике зачастую оказывается дешевле просто написать KB Article на эту тему — потому что окошко это требования, локализация, документация, собсно разработка, тестирование.
Ой, нет, мы не готовы выложить 400 человеко-часов на эту проблему, которая стреляет в 0.00001% случаев.

PJ>Откуда в разговоре взялся прикладной софт?
Потому что мы не пишем системный.
PJ>И почему это должно являться оправданием кривого дизайна и игнорирования ошибок?
Ну кривой рефакторинг же вы почему-то оправдываете, почему бы не быть кривому дизайну? If done poorly, design doesn't reach the intended goals.
PJ>И я не понимаю почему ты решил, что это дорого?
Из опыта и наблюдений.
PJ>Поддерживать некачественную программу дорого.
Смотря что считать некачественной программой. Программу, которая игнорирует ошибки, поддерживать значительно дешевле, чем ту, которая их все аккуратно обрабатывает.
Просто потому, что в аккуратной программе кода больше — больше площадь поверхности зависимостей.
К примеру, вот наша конкретная программа была вынуждена специально обрабатывать ситуацию, когда Microsoft не принимает адрес конечного пользователя. То есть у нас есть общая ветка, типа 4xx — что-то пошло не так, пишем в лог, фейлим операцию. В таких случаях потом приходит поддержка, разбирается что там было, чинит параметры, перезапускает. Но это — дорогостоящая штука; если проблема в адресе, то надо об этом написать пользователю, и дать ему возможность самому исправить ошибку — наш партнёр экономит 70-150 долларов на каждый такой инцидент.

Так вот, теперь ушлые парни из Редмонда в среднем полтора раза в год меняют то код ошибки, то расположение в теле ответа деталей ошибки. И каждый раз нам это стоит усилий — на очередной ресёрч, проверку, изобретение способа обработать и старый и новый форматы (потому что накатывается это изменение не на весь мир сразу, а поэтапно), тестирование, выпуск новой версии.
При этом Редмонд ни в чём не виноват — в их спецификации вообще ничего не сказано ни про коды, ни про структуру тела. Сказано, что если вернулось 4xx, то "тело ответа будет содержать error и может содержать errorCode, а также другие детали, полезные для анализа причин неудачи". Так что формально контракт не меняется.

PJ>Практически ты никогда не знаешь когда она выпуститься, всегда уши вылезут — хвост увязнет. Конечно если в современных условиях не использовать современные технологии, тот же DDD или FP, который дает сильно больше, чем факториалы через рекурсию, то писать придется больше, а качество будет низким. И иногда придется продажу выдавать за подписку. Ну так это просто "стратегия" стрельбы по своим ногам, ССЗБ.
Тут мне сложно судить — я отвечаю только за маленькую изолированную часть огромного продукта. Наша часть выходит предсказуемо, по расписанию, хотя иногда и приходится выдавать продажу за подписку.
Ей пользуются примерно 3.5 миллиона конечных пользователей, плюс ещё O(logN) администраторов, реселлеров, менеджеров и прочего обслуживающего персонала.

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

PJ>А что кто-то проводит рефакторинг с целью получить утечку? Тут значение имеет не результат, а намерения. Если по результату хотели одно, а получили утечку, то это просто "poorly done", но все же рефакторинг.
Ну, ок. Я больше внимания уделяю результату, отсюда и догматизм. Если мы хотели, чтобы программа научилась сохранять файлы в PDF, а по факту она переполняет стек и падает — то это баг, а не poorly done фича.

PJ>А что забавного? Если бы парадом командовал я, то я бы не выставлял факт подписки, чтобы кто-то что-то с этим делал. Я бы выставил конкретный api для конкретного use case. И возможно там нужна была не подписка, а какое-то производное от нее. Типа оплачено. Или еще как. Чем меньше потребитель api знает о потрохах, то лучше спит.
По прежнему возникает вопрос — как обеспечить консистентность totals при выдаче ордеров за месяц через старый API.

PJ>Ты не особо и смотришь, ты просто доказываешь, что у вас все правильно и это жизнь такая. Но это не важно, даже если надо вносить изменения, ну сделали ошибку, то это все равно не должно быть такой уж проблемой, чтобы еще большие костыли прикручивать.
Пока что вы не сказали мне ничего такого, чего я бы не знал. Про версионирование протоколов и про то, как делать их обратно совместимыми на per-call level я знал уже и не помню когда. Не уверен, что год тогда с цифры 2 начинался.
Вопрос, в который упираемся мы — как обеспечивать обратную совместимость с инвариантами, которые не исчерпываются одним DTO и одним вызовом.
Несмотря на то, что в контрактах API такие штуки практически никогда не бывают выражены явно, они существуют и на них полагаются пользователи (это к вопросу знания о потрохах).

PJ>Опять же если у тебя твой софт нормальный, то за полгода можно и легко изменить API, а если нет, то это уж точно не проблема MS, решайте свои технический долги.
Мы опять начинаем мериться кругозором. Что такое "твой софт"? В реальности мы имеем ситуации типа клиент Х — телеком корпорация, заказал пять лет назад разработку интеграции с Microsoft. Люди её выполнили, передали всё клиенту в эксплуатацию и ушли. Люди в Х, которые хотя бы стояли рядом с этим проектом, там давно уже не работают.
Всё что есть — это исходник (неизвестно как документированный), и инструкция "если сломалось А, давите на Б".
Теперь им надо за полгода внести изменения вот в этот вот софт. Может он и нормальный — кто знает? У них три месяца уйдёт только на то, чтобы поработать с экспертами, которые посмотрят в старый софт, в новую спеку, и оценят стоимость этих изменений. Это находится за пределами технических проблем, которые вам кажутся самыми главными.

PJ>Ты хочешь сказать, что все байки про интервью в МС, где они отбирают лучших это все вранье и потом эти высокооплачиваемые "неодоумки" просят со стороны обучить их API делать?
Понятия не имею про то, как устроены интервью в МС. Кое-какие вещи там делают люди, которые на десятичный порядок умнее меня. Некоторых из них я имею честь знать лично.
Но таких людей — единицы, и большинство из них работает ближе к "центру", то есть всякие ядра всяких сервисов. Ну, там, SQL Azure — это реально монстры, которым я бы был готов кофе носить только за право посмотреть, что они обсуждают на внутренних митингах.
"Периферию" — т.е. гуй и API к их сервисам — пишут не пойми кто. В полном смысле "не пойми кто" — т.е. этих людей держат подальше от коммуникаций, так что мы не знаем их фамилий. Зато видим результат — ошибки проектирования, за которые на втором курсе университета студентов отправляют на пересдачу. Видим в продакшне баги, которые были бы отловлены самым примитивным авто-тестированием (например, наши автотесты их ловят).
И да, таки просят. У меня, к сожалению, обрезали архив почты, поэтому нет того письма, где я объяснял новому менеджеру syndication program, что API должен обладать как минимум консистентностью и идемпотентностью.