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

PJ>На то, что твоя трактовка трудов дедушки Фаулера нелепая. Не благодари.
Не буду

PJ>Оттуда же.
PJ>

PJ>Typically, refactoring applies a series of standardised basic micro-refactorings, each of which is (usually) a tiny change in a computer program's source code that either preserves the behaviour of the software, or at least does not modify its conformance to functional requirements.

PJ>Есть трудности с пониманием?
Нету. Вижу, что мы с Ikemfula больше упираем на preserves the behaviour of the software, а вы настаиваете на более слабых требованиях.
При этом по вашему же варианта определения утечка памяти для рефакторинга — норм, ведь она не затрагивает функциональные требования.

PJ>Что у вас за мания величия? Ну вот кто тебя давал право говорить за миллионы?


S>>Какую фичу? Замену способа сортировки? Ну-ну.
PJ>На например замена for на linq. В твоем определении это ну никак не может быть рефакторингом.
Почему? Может. Технически, замена for на linq — это серия Extract method. Тот же самый код, структурированный по-другому.
Вот такая замена является рефакторингом:

foreach(var name in names) if (name=="Joe") yield return name

return names.Where((name)=>name=="Joe")

Точно так же, как и такая:

return from name in names where name=="Joe" select name

А вот такая — нет:

return namesIndex.Contains("Joe") ? namesIndex["Joe"]: Enumerable.Empty<string>()

PJ>Вообще-то мой поинт был в том, что это и есть технический долг, и вот его и надо решать, чтобы таких ситуаций не возникало. Делать вам я ничего не предлагал. Для предложений у меня нет ни достаточных данных, ни желания, ни твоей просьбы, для начала.
Здесь технического долга нет ровно до того момента, как мы стали втискивать новый тип продукта в нашу модель. По крайней мере, я его не вижу, и не вижу никакого способа, как бы мы могли этот долг устранить "заранее", до того, как возникла новая задача. Если вы считаете, что есть какой-то магический способ заранее узнать, что делает неопределённый круг лиц с публичным API — велком, расскажите.

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

PJ>Есть конечно. Библиотечный.
Ну вот и отлично.

PJ> Я себе скоро лицо отобью с твоим пытливым умом. Как ты думаешь, почему видна откатывает на контрольную точку все файлы, а не просто каждый файл на предыдущую версию, которые она тоже умеет? Все еще не понял? Ну читай дальше.
Очевидно — по той же причине.

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

Ну ок, теперь в целом понятно.