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

S>>Нет, так не работает. В функциональных требованиях никто не упоминает вообще ничего про память. В 99% в требованиях к софту вообще нет ничего про память; в оставшемся проценте это часть нефункциональных требований, и формулируется она в стиле "должно запускаться на машине с 16GB RAM, 1GB места на диске".
PJ>Ну вот ты сейчас опять натягиваешь сову на глобус. Функциональные требования могут быть любые. Вообще. Не спрашивая твоего одобрения или твоей оценки их полезности.
Неа. Требования делятся на функциональные (что программа должна делать) и нефункциональные (как она должна это делать). См. например https://analytics.infozone.pro/formation-requirements-and-classification-requirements/
Вы, конечно же, можете называть "рефакторингом" процесс внесения или исправления багов или реализацию фич.
Можете называть требования к потреблению памяти функциональными.

S>>Ни разу в жизни я не видел (и не надеюсь увидеть) оговорок в требованиях к софту насчёт граничных условий: типа "а вот тут, если кончилось место на диске, то приложение должно выдать вот такое-то сообщение".
PJ>Т.е. ты зная как "устроена жизнь" держишь голову в песке? У нас такое сообщение есть и пользователи его регулярно видят. А почему оно тебя так пугает?
Меня совершенно не пугает сообщение. Мне интересно, есть ли у вас документ, в котором оно затребовано — и был ли он до начала разработки, или его написали задним числом, когда пользователи столкнулись с таким поведением.

На всякий случай поясню: я совершенно не против таких документов, совсем наоборот. Просто в большинстве реальных задач есть более-менее обозримое количество "положительных" сценариев, которые нужны пользователям.
И есть на порядок большее количество сценариев, в которых что-то пошло не так. Если выписывать все возможные сценарии падения, то стоимость фазы "подготовка требований" взлетает в небеса, и есть риск так и не взяться за собственно написание кода. Поэтому либо (95%) на это вообще забивается, и софт пишется только для оптимистичного сценария, либо (5%) пишется какая-то общая клауза, типа "в случае неожиданной проблемы, софт должен записать в лог максимум подробностей, показать сообщение об ошибке, и постараться вернуться к стабильному состоянию либо закрыться. Недопустимо портить файлы пользователя, недопустимо продолжение работы в некорректном состоянии".
Всё. В результате мы имеем вполне себе популярные программы от передовиков производства, котрые ухитряются падать, вообще ничего не сообщая пользователю. Винда за них выдаёт окошечко "Приложение не смогло прочитать свой файл данных, и его пришлось пристрелить".

Как бы мы ни относились к этому, де-факто это стандарт качества современного прикладного софта. Прыгать сильно выше него должно быть чем-то оправдано — ну там, спецификой прикладной области (АЭС?), или выбором стратегии "конкуренция по качеству", желательно с внятным пояснением причин, по которым такая стратегия нас не разорит.

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

PJ>Это другой код. Более того, в зависимости от реализации IEnumerable оно параллельным может стать.
Ну, ок, ладно. Вопрос об эквивалентности параллельного исполнения кода и последовательного для меня слишком сложен Не готов обсуждать, есть ли способ поменять семантику при таком рефакторинге.

S>>Надо просто внимательно смотреть, что именно делает этот рефакторинг.
PJ>Ну да, либо имеет целью изменить функциональные требования, либо нет. Больше ничего выдумывать не надо.
Хм. Есть ещё примеры рефакторинга, который намеренно изменяет функциональные требования?

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

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

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

PJ>Ну я вот тебе пытался рассказывать, а ты просто не слушаешь. Может и они пытались. С другой стороны чсв тебе явно жмет, если думаешь, что у всех голова болит как бы не забыть тебе все рассказать, чего ты не знаешь.
Отож. Именно так всё и обстоит — стараются, рассказывают, зазывают на семинары, лабы и воркшопы. Иногда просят написать и научить их, как правильно делать публичные API. Потому что у них этим занимались люди, гораздо менее способные к этому, чем я. Постепенно мы их обучили; и у них был пик способностей года до 2019 примерно, а сейчас снова к архитектуре допустили недоумков.
(Ну вот из недавнего — их modern commerce api в некоторых случаях приводит к потере корзинки: сервер думает, что заказ оформлен, а клиент думает, что произошёл сбой. Т.е. даже безо всяких изменений API является неустойчивым к пропаданию связи.)
В Autodesk ситуация хуже: мало того, что у них сама система, выставленная наружу — ужос-ужос, SAP интегрированый с salesforce, и оба ещё с каким-то siebel, так и API тоже проектировали люди средних способностей.
Но хорошие новости в том, что они с нами разговаривают, и есть шанс их выучить тоже.

PJ>Модуль определяет, грубо говоря, две функции save :: Data -> Path -> Result<> и load :: Version optional -> Path -> Result<>, делая частичное применение для остальных своих потребностей. Кто как и зачем их вызовет вне контроля модуля. Но, про версию он знать все равно должен, это в сигнатуре библиотечной функции, которая делает фактическую загрузку.
О, это круто, без дураков. Надо всё же выбрать время, прочитать Влашина. Я всю жизнь нутром чуял, что ФП способно на большее, чем вычислять факториалы через tail recursion.