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

S>При том, что требования к потреблению памяти и быстродействию обычно относят к нефункциональным.
Если память утекла, то ни одна из функций работать не будет.

S>В моём уютном мирке такое явление означает, что рефакторинг проводили неаккуратно. Целью не ставилось изменение функциональных требований, значит цель не достигнута.
Озвучь еще раз, в явном виде, если в результате рефакторинга исчез баг, то это рефакторинг неаккуратненький и цель не достигнута?!

S>Это если у нас есть ресурсы на это улучшение. На практике зачастую оказывается дешевле просто написать KB Article на эту тему — потому что окошко это требования, локализация, документация, собсно разработка, тестирование.
S>Ой, нет, мы не готовы выложить 400 человеко-часов на эту проблему, которая стреляет в 0.00001% случаев.
Что-то сильно не так со... всем и вся. Если проще написать KB Article, чем исправить ошибку.

PJ>>Откуда в разговоре взялся прикладной софт?
S>Потому что мы не пишем системный.
Раз за вас, только что это меняет? Типа прикладной софт можно и нужно криво писать?

PJ>>И почему это должно являться оправданием кривого дизайна и игнорирования ошибок?
S>Ну кривой рефакторинг же вы почему-то оправдываете, почему бы не быть кривому дизайну? If done poorly, design doesn't reach the intended goals.
Я не оправдываю кривой рефакторинг, а я говорю о том, что кривой рефакторинг все еще называется рефакторинг. И ты, не смотря на свой догматизм, называешь его так же, как и кривой дизайн.

PJ>>И я не понимаю почему ты решил, что это дорого?
S>Из опыта и наблюдений.

- А я тебе говорил — место проклятое!!! А то всё "руки из жопы, руки из жопы"

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

S>Просто потому, что в аккуратной программе кода больше — больше площадь поверхности зависимостей.
Неа. В аккуратной программе кода меньше. Хотя бы потому, что он лучше структурирован и меньше дублирования, и уж точно меньше зависимостей.
Сколько раз переписывал c# на f#, в результате размер кода всегда примерно в три раза меньше, при более высоком качестве.

S>К примеру, вот наша конкретная программа была вынуждена специально обрабатывать ситуацию, когда Microsoft не принимает адрес конечного пользователя. То есть у нас есть общая ветка, типа 4xx — что-то пошло не так, пишем в лог, фейлим операцию. В таких случаях потом приходит поддержка, разбирается что там было, чинит параметры, перезапускает. Но это — дорогостоящая штука; если проблема в адресе, то надо об этом написать пользователю, и дать ему возможность самому исправить ошибку — наш партнёр экономит 70-150 долларов на каждый такой инцидент.
Я может чего не понял, но че-то не впечатлился масштабом проблемы заменить один код, на другой три раза за два года.

S>Ей пользуются примерно 3.5 миллиона конечных пользователей, плюс ещё O(logN) администраторов, реселлеров, менеджеров и прочего обслуживающего персонала.
Ну ты просто посмотри на это с точки зрения MS, они тоже могу сообщить о количестве "пользователей, администраторов, реселлеров, менеджеров и прочего обслуживающего персонала." А ты про них говоришь "недоумки".

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

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

S>По прежнему возникает вопрос — как обеспечить консистентность totals при выдаче ордеров за месяц через старый API.
Хождение по кругу. Не зная задачи в деталях, я не могу сказать точно, что вам надо было делать и что надо делать сейчас. И я не пытаюсь решать ваши проблемы.
Мы обсуждали технический долг. Мой поинт был в том, что технический долг возникает не в момент когда покупку объявляешь подпиской, а в момент когда ты вместо выдавания totals или еще какой производной от ордеров, выдаешь сами ордера чтобы клиент с ними что-то делал. Потому что так проще и надо меньше делать. В момент, когда это стало важно, вместо уменьшения долга вы его еще больше увеличиваете. Следующий костыль будет еще больше кривым. Цепочка подобных изменений всегда ведет к том, что продукт начинает гнить и разлагаться. И, в конечном итоге, его проще выкинуть и написать заново.

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

S>Несмотря на то, что в контрактах API такие штуки практически никогда не бывают выражены явно, они существуют и на них полагаются пользователи (это к вопросу знания о потрохах).
Ну так может стоит начать их выражать явно? Глядишь в следующий раз грабли уже не ударят по лбу.

S>Теперь им надо за полгода внести изменения вот в этот вот софт. Может он и нормальный — кто знает? У них три месяца уйдёт только на то, чтобы поработать с экспертами, которые посмотрят в старый софт, в новую спеку, и оценят стоимость этих изменений. Это находится за пределами технических проблем, которые вам кажутся самыми главными.
Вот я примерно про такое и говорю. Гниение и разложение. А все потому, что технические проблемы не казались главными или важными. Три месяца, чтобы понять что делать... :faceplam: Ты же сам говорил, что вы настолько даже не планируете?!

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

S>При том, что требования к потреблению памяти и быстродействию обычно относят к нефункциональным.
Если память утекла, то ни одна из функций работать не будет.

S>В моём уютном мирке такое явление означает, что рефакторинг проводили неаккуратно. Целью не ставилось изменение функциональных требований, значит цель не достигнута.
Озвучь еще раз, в явном виде, если в результате рефакторинга исчез баг, то это рефакторинг неаккуратненький и цель не достигнута?!

S>Это если у нас есть ресурсы на это улучшение. На практике зачастую оказывается дешевле просто написать KB Article на эту тему — потому что окошко это требования, локализация, документация, собсно разработка, тестирование.
S>Ой, нет, мы не готовы выложить 400 человеко-часов на эту проблему, которая стреляет в 0.00001% случаев.
Что-то сильно не так со... всем и вся. Если проще написать KB Article, чем исправить ошибку.

PJ>>Откуда в разговоре взялся прикладной софт?
S>Потому что мы не пишем системный.
Раз за вас, только что это меняет? Типа прикладной софт можно и нужно криво писать?

PJ>>И почему это должно являться оправданием кривого дизайна и игнорирования ошибок?
S>Ну кривой рефакторинг же вы почему-то оправдываете, почему бы не быть кривому дизайну? If done poorly, design doesn't reach the intended goals.
Я не оправдываю кривой рефакторинг, а я говорю о том, что кривой рефакторинг все еще называется рефакторинг. И ты, не смотря на свой догматизм, называешь его так же, как и кривой дизайн.

PJ>>И я не понимаю почему ты решил, что это дорого?
S>Из опыта и наблюдений.

- А я тебе говорил — место проклятое!!! А то всё "руки из жопы, руки из жопы"

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

S>Просто потому, что в аккуратной программе кода больше — больше площадь поверхности зависимостей.
Неа. В аккуратной программе кода меньше. Хотя бы потому, что он лучше структурирован и меньше дублирования, и уж точно меньше зависимостей.
Сколько раз переписывал c# на f#, в результате размер кода всегда примерно в три раза меньше, при более высоком качестве.

S>К примеру, вот наша конкретная программа была вынуждена специально обрабатывать ситуацию, когда Microsoft не принимает адрес конечного пользователя. То есть у нас есть общая ветка, типа 4xx — что-то пошло не так, пишем в лог, фейлим операцию. В таких случаях потом приходит поддержка, разбирается что там было, чинит параметры, перезапускает. Но это — дорогостоящая штука; если проблема в адресе, то надо об этом написать пользователю, и дать ему возможность самому исправить ошибку — наш партнёр экономит 70-150 долларов на каждый такой инцидент.
Я может чего не понял, но че-то не впечатлился масштабом проблемы заменить один код, на другой три раза за два года.

S>Ей пользуются примерно 3.5 миллиона конечных пользователей, плюс ещё O(logN) администраторов, реселлеров, менеджеров и прочего обслуживающего персонала.
Ну ты просто посмотри на это с точки зрения MS, они тоже могу сообщить о количестве "пользователей, администраторов, реселлеров, менеджеров и прочего обслуживающего персонала." А ты про них говоришь "недоумки".

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

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

S>По прежнему возникает вопрос — как обеспечить консистентность totals при выдаче ордеров за месяц через старый API.
Хождение по кругу. Не зная задачи в деталях, я не могу сказать точно, что вам надо было делать и что надо делать сейчас. И я не пытаюсь решать ваши проблемы.
Мы обсуждали технический долг. Мой поинт был в том, что технический долг возникает не в момент когда покупку объявляешь подпиской, а в момент когда ты вместо выдавания totals или еще какой производной от ордеров, выдаешь сами ордера чтобы клиент с ними что-то делал. Потому что так проще и надо меньше делать. В момент, когда это стало важно, вместо уменьшения долга вы его еще больше увеличиваете. Следующий костыль будет еще больше кривым. Цепочка подобных изменений всегда ведет к том, что продукт начинает гнить и разлагаться. И, в конечном итоге, его проще выкинуть и написать заново.

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

S>Несмотря на то, что в контрактах API такие штуки практически никогда не бывают выражены явно, они существуют и на них полагаются пользователи (это к вопросу знания о потрохах).
Ну так может стоит начать их выражать явно? Глядишь в следующий раз грабли уже не ударят по лбу.

S>Теперь им надо за полгода внести изменения вот в этот вот софт. Может он и нормальный — кто знает? У них три месяца уйдёт только на то, чтобы поработать с экспертами, которые посмотрят в старый софт, в новую спеку, и оценят стоимость этих изменений. Это находится за пределами технических проблем, которые вам кажутся самыми главными.
Вот я примерно про такое и говорю. Гниение и разложение. А все потому, что технические проблемы не казались главными или важными. Три месяца, чтобы понять что делать... Ты же сам говорил, что вы настолько даже не планируете?!