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

S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>А можно цитату подтвержающую этот вывод пытливых умов? А то так получается добавил в ходе рефакторинга утечку памяти и нормуль — неважно. Не надо даже до контроллеров ходить.
S>Т.к. рефакторинг производит эквивалентные преобразования, то добавить утечку он никак не может. За это его и ценят.
Может конечно. Вот прям на вики и написано.

If done poorly it may fail the requirement that external functionality not be changed, introduce new bugs, or both.

Т.е. рефакторинг это не набор заклинаний гарантирующих тебе некую "эквивалентность". Это просто переписывание кода, с чем чтобы он делал то же самое, но по другому.

S>Нету. Вижу, что мы с Ikemfula больше упираем на preserves the behaviour of the software, а вы настаиваете на более слабых требованиях.
Я-то как раз ни на чем не настаиваю. Если вы хотите понимать его по своему, то флаг вам в руки. А вот вы, с какого-то перепугу, настаиваете на том, что ваши трактовки единственно верные.

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

S>Почему? Может. Технически, замена for на linq — это серия Extract method. Тот же самый код, структурированный по-другому.
Нет, это не тот же самый код. Можешь декомпилятором разобрать. Более того, емнип, если функция возвращает IEnumerable, то она внезапно может стать ленивой, в то время как c for нет. Если строго следовать вашей трактовке, то это не рефакторинг, если не начать вытаскивать из кустов "дополнительные соглашения", которые Фаулер явно имел ввиду, но забыл описать.

S>Здесь технического долга нет ровно до того момента, как мы стали втискивать новый тип продукта в нашу модель. По крайней мере, я его не вижу, и не вижу никакого способа, как бы мы могли этот долг устранить "заранее", до того, как возникла новая задача. Если вы считаете, что есть какой-то магический способ заранее узнать, что делает неопределённый круг лиц с публичным API — велком, расскажите.
Не, в этот момент технический долг дал о себе знать. Существовал он с момента, когда вы начали что-то делать на предположениях и выставлять наружу модель, даже не имея представления зачем и кому она нужна. Я потратил много времени пытаясь сказать, что вы могли бы сделать. Есть множество практик как подобного избегать, то же DDD например. Если множество компаний которые выставляют наружу публичные API и не страдают. Но, поскольку вы официально лучшие, что вам до этих пейзан?!

S>Не одинаково, но единообразно. А то через полгода окажется, что один автор держит конфигурацию в реестре, другой — в AppData, третий срёт в Program Files рядом с екзешником, а четвёртый — в Documents and Settings.
Ну, нет, разумеется. Куда писать они не решают. Откуда такой странный вопрос?