Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>Я поражаюсь твоему особенному чтению. Сделай одолжение, пальцем там покажи или еще как выдели — где ты тут нашел вопрос? 
S>Вопрос у вас подразумевается — как же быть с тем, что любой рефакторинг хоть что-то, да меняет — быстродействие, размер кода, расположение в памяти кода и аргументов.
S>И эти изменения можно наблюдать, и всё равно мы называем это рефакторингом. Неужели же это даёт нам возможность вообще всю разработку называть рефакторингом?
Надо же, ты явно разговариваешь сам с собой. Нашел вопрос там где его не было, сам его выдумал, сам опроверг.
Неа, я лишь указал не противоречие в ваших трактовках определений. Вы, с Ikemefula, сначала назначили себя гласом истины, а потом запутались в собственных ногах.
"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
Тут нет ссылок ни на какие исключения, ни на какие соглашения. Откуда ваш пытливый ум их высосал я хз. Но, мне не надо всю разработку называть рефакторингом, мне достаточно назвать ваши трактовки неверными и все сразу сходится, без всяких аналогий и прочей ерунды.
PJ>>Сейчас уже только важные... Т.е. изменения скорости или памяти это неважные?
S>С точки зрения традиционного рефакторинга — неважные. Это, конечно же, не означает их принципиальной ненаблюдаемости.
А можно цитату подтвержающую этот вывод пытливых умов? А то так получается добавил в ходе рефакторинга утечку памяти и нормуль — неважно. Не надо даже до контроллеров ходить.
S>О чём нам намекают все эти сходства?
На то, что твоя трактовка трудов дедушки Фаулера нелепая. Не благодари.
S>Компилятор делает из понятного неэффективного кода непонятный эффективный; программист (или решарпер) делает из эффективного непонятного кода более понятный, иногда — ценой эффективности.
S>Вопросы эквивалентности программ — не самые простые, и в деталях подходы к ним могут отличаться. Тем не менее, есть определённый консенсус в плане того, что считается рефакторингом.
S>Дедушка Фаулер считал, что рефакторинг — это изменение структуры того же самого кода. Отсюда и название — рефакторинг, т.е. "пере-разложение на множители". То есть типа 4*3 и 3*4 — одно и то же, как и 6*2, и 2*2*3, а вот 5*7 — это уже что-то другое.
Еще один голос дедушки.
Да он вообще даже не изобретал его
Берем вики.
Although refactoring code has been done informally for decades, William Griswold's 1991 Ph.D. dissertation[22] is one of the first major academic works on refactoring functional and procedural programs, followed by William Opdyke's 1992 dissertation[23] on the refactoring of object-oriented programs
Оттуда же.
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>>Ну разве что в вашем уютном мирке.
S>И в уютных мирках миллионов других программистов.
Что у вас за мания величия? Ну вот кто тебя давал право говорить за миллионы?
S>>>Вынос метода сравнения элементов при сортировке в параметр — является рефакторингом.
PJ>>И когда решарпер добавит фичу в рефакторинг, вот это будет срыв шаблона.
S>Какую фичу? Замену способа сортировки? Ну-ну.
На например замена for на linq.
В твоем определении это ну никак не может быть рефакторингом.
S>
Зато у нас не ломаются файлы конфигурации. Каждому своё.
Рад за вас, но как ты сам выше заметил не у нас одних.
S>Если мы сделаем так, как вы предполагаете, то релиз поддержки нового вида продуктов мы отложим на полгода — это в лучшем случае, если с нашей стороны не возникнут непредвиденные задержки. И если мы сразу заложимся на то, что опросить больше 80% клиентов нам не удастся.
Вообще-то мой поинт был в том, что это и есть технический долг, и вот его и надо решать, чтобы таких ситуаций не возникало. Делать вам я ничего не предлагал. Для предложений у меня нет ни достаточных данных, ни желания, ни твоей просьбы, для начала.
S>Ну, я надеюсь у вас сохранение конфигурации не в каждом модуле сделано по-своему, верно?
Разумеется по разному. Разные устройства, разные типы информации, разные авторы. На кой фиг пытаться выдумывать общность там где ее нет? Одному надо пару строк в тексте, другому мегабайт в бинарном виде. Ты это все будешь делать одинаково?
S>Наверное есть какой-то общий код, который каждый из модулей вызывает для сохранения конфигурации, не так ли?
Есть конечно. Библиотечный.
S>У вас этот общий код уже умел определять, что побит один (или несколько) файлов, и заставлять всех откатываться к дефолтной настройке. Значит, теперь он будет уметь вместо "отката к дефолту" делать "открыть предыдушую версию".
Я себе скоро лицо отобью с твоим пытливым умом. Как ты думаешь, почему видна откатывает на контрольную точку все файлы, а не просто каждый файл на предыдущую версию, которые она тоже умеет? Все еще не понял? Ну читай дальше.
Откат к дефолтной настройке тривиальный. Модулю не надо ничего знать о соседях. У всех они свои. Достаточно вернуть ошибку и сбросится. Получив ошибку все остальные получат команду на сброс тоже. Тут нельзя промахнуться. Есть либо согласованные файлы на диске, либо согласованное начальное состояние. В случае когда у всех есть история нужен еще один уровень абстракции, потому что размер истории может быть разным. Надо знать куда откатываться, чтобы не нарушить согласованность. Соотвественно, каждый модуль дожен не просто записать и вернуть результат, а вернуть еще и верисии и хеш файлов, для снапшота, а так же уметь загружать запрошенную версию, а не что попало. И это рефакторинг, потому что функционально в модулях ничего не изменилось. Вызывают другую функцию и все, ну и сигнатура другая.
S>Я по-прежнему затрудняюсь себе представить архитектуру, в которой такое изменение может вызывать какие-то сложности.
Я ни слова не говорил про сложности. Откуда ты это взял? Я сказал, что рефакторинг может быть совмещен с разработкой и привел пример.
