Здравствуйте, Poopy Joe, Вы писали:
PJ>Я поражаюсь твоему особенному чтению. Сделай одолжение, пальцем там покажи или еще как выдели — где ты тут нашел вопрос?
Вопрос у вас подразумевается — как же быть с тем, что любой рефакторинг хоть что-то, да меняет — быстродействие, размер кода, расположение в памяти кода и аргументов.
И эти изменения можно наблюдать, и всё равно мы называем это рефакторингом. Неужели же это даёт нам возможность вообще всю разработку называть рефакторингом?
Пытливый ум мог бы ещё провести некоторые аналогии с оптимизацией — там же тоже компилятор вносит изменения в код, и их можно обнаружить.
Например, вот вы там собирались написать тест, который проверяет расположение аргументов вызова в памяти — прекрасный пример. Приличный компилятор инлайнит вызов, и ваш тест в результате измерения выдаёт "борщ".
Безо всякого, кстати, рефакторинга. И вообще раз от раза этот тест будет выдавать то одно, то другое — потому что современный комплятор языков высокого уровня достаточно вольно обращается с техническими деталями уровня расположения аргументов в памяти.
PJ>Сейчас уже только важные... Т.е. изменения скорости или памяти это неважные?
С точки зрения традиционного рефакторинга — неважные. Это, конечно же, не означает их принципиальной ненаблюдаемости.
Простейший пример — делаем extract method, вынося кусочек кода в отдельную функцию. И ваш код начинает падать — потому что вы работаете на микросхеме с ограниченной глубиной стека, и эти лишние байты всё ломают.
Ну сорри — дедушка Фаулер придумывал свою методику не для вас. В таких условиях рефакторинг не даёт нужных гарантий — как и оптимизации компилятора.
Ок, рефакторинг introduce parameter может катастрофически повлиять на быстродействие — потому что раньше оптимизатор видел константу, выбрасывал целый блок кода, и менял всю арифметику. А теперь он вынужден честно выполнять сравнения, прибавлять нули и умножать на единицы. А может и не повлиять — потому что оптимизатор заинлайнил вызов, увидел ту же константу, убедился, что a+=0 можно заменит на nop, и выкинул весь цикл по массиву.
О чём нам намекают все эти сходства? И оптимизирующий компилятор, и решарпер, и программист при ручном рефакторинге занимаются примерно одним: преобразованием программы с сохранением
эквивалентности.
Компилятор делает из понятного неэффективного кода непонятный эффективный; программист (или решарпер) делает из эффективного непонятного кода более понятный, иногда — ценой эффективности.
Вопросы эквивалентности программ — не самые простые, и
в деталях подходы к ним могут отличаться. Тем не менее, есть определённый консенсус в плане того, что считается рефакторингом.
Дедушка Фаулер считал, что рефакторинг — это изменение структуры
того же самого кода. Отсюда и название — рефакторинг, т.е. "пере-разложение на множители". То есть типа 4*3 и 3*4 — одно и то же, как и 6*2, и 2*2*3, а вот 5*7 — это уже что-то другое.
PJ>Ну разве что в вашем уютном мирке.
И в уютных мирках миллионов других программистов.
S>>Вынос метода сравнения элементов при сортировке в параметр — является рефакторингом.
PJ>И когда решарпер добавит фичу в рефакторинг, вот это будет срыв шаблона.
Какую фичу? Замену способа сортировки? Ну-ну.
PJ>Нет, спасибо.
Зато у нас не ломаются файлы конфигурации. Каждому своё.
PJ>Ну тут ты хотя бы употребил предположение и проверка. Т.е. в теории ты знаешь, что просто предположений недостаточно и их надо проверять, после чего они уже не предположения, а факты.
PJ>Осталось переложить это знание на практику. Узнать например нафига клиентам подписка и что с этим можно сделать, а не просто предполагать...
Я — целиком и полностью "за". Именно так мы и будем делать, когда пойдём ломать модель. У нас есть эмпирическая оценка, сколько стоит вот это "Узнать например нафига клиентам подписка". Она по стоимости чуть больше, чем затраты на внесение изменений в код ядра и наших собственных модулей, а по срокам — дольше в разы.
Если мы сделаем так, как вы предполагаете, то релиз поддержки нового вида продуктов мы отложим на полгода — это в лучшем случае, если с нашей стороны не возникнут непредвиденные задержки. И если мы сразу заложимся на то, что опросить больше 80% клиентов нам не удастся.
PJ>Не, ты на пальцах показал, что вы боитесь сломать контракт, даже если это правильно, потому что все на соплях и немедленно развалится, причем вы даже не знаете где и в каком виде...
PJ>ну да "Берём последнюю версию, если она консистентна — всё хорошо. Если хотя бы в одном файле плохо — откатываемся на предыдущую версию." вот так вы можете. Уровень джуниора и есть. Взять предположение и зафигачить решение. На какую предыдущую версию модуль будет откатываться, если он знает только про свои версии?
Ну, я надеюсь у вас сохранение конфигурации не
в каждом модуле сделано по-своему, верно? Наверное есть какой-то общий код, который каждый из модулей вызывает для сохранения конфигурации, не так ли?
У вас этот общий код уже умел определять, что побит один (или несколько) файлов, и заставлять
всех откатываться к дефолтной настройке. Значит, теперь он будет уметь вместо "отката к дефолту" делать "открыть предыдушую версию". Я по-прежнему затрудняюсь себе представить архитектуру, в которой такое изменение может вызывать какие-то сложности.