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

I>>Опаньки! Тогда ценность твоего высказывания про удлиннение конкретной фичи равна нулю.

ARK>Нет. Равна нулю ценность твоего утверждения, что рефакторинг сокращает время разработки.

Не понятно, где логика. Ценность моего утверждению равна нулю в том случае, если выполняются два условия
1. рефакторинг удлинняет любую фичу
2. рефакторинг удлинняет все фичи вместе взятые

А теперь читаем вместе твои аргументы:

Я написал — "может". Естественно, никаких гарантий этого не существует.

Итого — всего лишь твоё мнение, а гарантий 1 и 2 по твоим же словам не существует. Итого — в сухом остатке одно твое мнение.

I>>А ты — нечитатель. Неопределенность и есть причина того, что внятных оценок никто дать не может.
ARK>Возможно. И рефакторинг никаких неопределенностей не устраняет, однако добавляет новые

Прикинь, решил ты фото детей повесить в рамку на стену. Взял дрель-перфоратор, что бы просверлить отверстие под дюбель и ненароком просверлил себ кисть. Тебя это не остановило, ты решил дюбель забитьв стену, но раздробил молотком кисть. А когда закручивал крюк, случайно напоролся глазом на отверку.

Картина понятна ? Надо ли объяснять, что подобный исход никак не говорит о том, что инструменты ничем не помогаеют ?

В перевод на руский — рефакторинг помогает в том случае, когда применяется по назначению — для исправления проблем с кодом.
А это значит, что сначала нужно идентифицировать проблему, убедиться, что есть решение, и далее это решени сформулировать.
Без этого никакой рефакторинг не поможет.

Более того любые изменения кода без этих шагов плодят хаос и увеличивают эту неопределенность.

I>>Разумеется. Если над кодом работает команда, то результат должен устраивать всех. Почему рефакторинг должен выделяться ?
I>>А ну как ты переписал код, а Вася его выбросил и написал свой. Чем это лучше твоего примера ?

ARK>Ничем не лучше. И рефакторинг точно так же не гарантирует того, что над этим кодом никто больше не будет работать.

Ну ка, подробнее, что за чудо такое, когда ты выбрасываешь проблемный код, а он у тебя продолжает мозолить глаз и требовать внимания ?

Пример — у нас был небольшой компонент, на пять сотен килобайт. Изменения в нем делались от минуты до месяца и даже полугода. Эстимейты были соответствующие и пять лет никто его не трогал.
После того, как завершился рефакторинг, люди даже забыли, что с этой частью были какие то проблемы. Изменения — исчезли пять наследников, объем кода компонента ужался вдвое, появились внятные связи, повыкидывали кучу вспомогательных доеров, хелперов и полу-компонентов-помогаторов. Скажем, преобразования координат были в сотне мест кастомным кодом(это не шутка), стали в одном месте матричным способом. И это безо всякого переписывания, исключительно средствами автоматического рефакторинга.
На рефакторинг компонента ушел год. Это много. Зато следующие два с половиной года продукт развивался именно за счет этого компонента, т.к. удалось ввести оптимизации и увеличить объемы данных примерно в 10 раз, скорость отрисовки от 2 до 1000 раз, а кучка трудно-выполнимых ручных работ стала выполняться через форм эдитор.
И вот это все делалось исключительно через рефакторинг, кроме финальной интеграции, были причины.

То есть — девелоперы перестали иметь дело с проблемным кодом. То есть, с проблемным кодом больше никто не работает.

Кстати говоря, вот товарищи, которые начали писать заново, читай — переписывать, никуда не пришли, через какое то время выбросили свою поделку и все труды, перешли на 3rd party, но в итоге им это мало чего дало — выглядеть стало красивше, но ни объемов, ни фич, а прикручивание всего лишь контекстного меню превратилось в дикую содомию

Вот это все про рефакторинг, а тебя послушать, так какое то божественное чудо воскрешения мертвого кода — ты его удаляешь, а наутро он снова на месте.

ARK>>>Тем не менее, в общем случае один и тот же кусок кода может правиться много раз.
I>>Именно — и фактор неопределенности играет ровно столько же раз.

ARK>Я тут говорил про рефакторинг, если что.

С твоих слов после рефакторинга проблемы почему то не уходят. Ты рефакторинг похоже путаешь не только с переписыванием, но и с улучшайзингом.
Для меня это какая то дичь — сели решать проблему, идентифицировали, поставили диагноз, подобрали лечение, лечение прошло успешно, но код каким был, таким и остался.
Каким образом такое возможно ? Старый код сам себя коммитит в мастер ?

I>>Поэтому и надо разделять рефакторинг — изменения с определенными гарантиями, и переписывание, где нет никаких гарантий.

ARK>На практике это одно и то же. Гарантий ты никаких не получишь ни в том, ни в том случае. Можешь разве что разделить _намерения_. Но сам процесс особых различий не несет.

Рефакторинг это только такие изменения, которые дают гарантии и максимальный контроль. Например, если я переименовываю переменную, то я получаю гарантии от
1 ИДЕ — переименована ровно одна переменная и сведения о отсутствии конфликтов
2 тесты — зеленые, значит все хорошо
3 ревью — такое маленькое изменение легко отследить при помощи обычного дифа.

А если ты перепилил всё тело функции и вроде бы результат тот же, то это не рефакторинг, потому как а хер его знает, какие ты внёс сайд эффекты, достаточно ли дня них тестов, нет ли трудновоспроизводимых багов и тд. Анализировать надо все изменения целиком.

I>>Может. А если изначально отказаться от гарантий, то гарантировано получаешь хаос
ARK>Ну, это просто манипуляция терминами.

Это факты. У меня ощущение, что ты путаешь общее и частное, потому как отсутствие контроля и его наличие нзываешь одним и тем же словом.

С таким же успехом ты можешь себя назвать, ну, скажем, млекопитающим. Другой пример — дерево есть частный случай графа. То есть — граф, а стало быть все то же и так же, как в графе.
Надо ли объяснять, что у деревая есть свойства, которые отсутствуют в произвольном графе, и мы его используем именно ради этих свойств?

I>> У вас похоже ни IDE, ни инструментов, ни тестов, ни тестировщиков не изобрели. Так что ли ?

ARK>Ну я понял, ты просто называешь переписывание кода без изменения поведения — рефакторингом. Это твое право, но по сути это все равно переписывание. Но ты переписыванием называешь только один частный случай.

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

I>>Это именно обоснование. Или ты думал я тебе научный труд принесу ?

ARK>Это набор голословных утверждений, не подкрепленных ничем.

Этот набор успешно предложил и обосновал Фаулер двадцать лет назад и с тех пор это трансформировалось в целую методологию.
Судя по твоим словам, ты наверняка этого не знал

I>>Ты говоришь, что у Оракла плохой код. Из этого никак не следует, что рефакторинг не применялся , неприменим и тд.
ARK>Почему же, плохой код и отсутствие рефакторинга — это сильная корреляция.

Ну и детский сад. Корреляция и причина это разные вещи!!! Переписывание и рефакторинг могут дать и часто дают один и тот же результат и это вобщем то норма.
Например, ты написал цикл, где само тело цикла скопировано сто раз. Теперь надо решить эту проблему и устранить дублирование, поскольку есть следующая фича которая затрагивает этот цикл.
В дагном примере корректное переписывание, и правильный рефакторинг дадут в итоге цикл без дублирования и код будет идентичным.

Разница только в том, какая у тебя степень уверености — в рефакторинге, если ты ничего не сломал на каждом шагу, то ты ничего не сломал вообще, уверенность высокая. В переписывании — а хер его знает, т.к. проанализировать надо надо будет одни куском.
Шашлык небось на кусочки режешь и проглатываешь. Или ты из тех, кто жарено мясо глотает килограммами не жуя ?

I>>Да хоть по году на мелкий баг, тебе то что с того ? Рефакторинг нужен в том случае если это становится проблемой. Захочешь, скажем, фичи вводить намного быстрее. Каким таким способом ?

ARK>Не знаю, видят ли они какие-то проблемы. Я вижу, что экономическая эффективность рефакторинга под сомнением.

Из твоего примера про Оракл этого не следует. Ты путаешь корреляцию и причинно-следственную связь, впечатляет.

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

I>>Опаньки! Тогда ценность твоего высказывания про удлиннение конкретной фичи равна нулю.

ARK>Нет. Равна нулю ценность твоего утверждения, что рефакторинг сокращает время разработки.

Не понятно, где логика. Ценность моего утверждению равна нулю в том случае, если выполняются два условия
1. рефакторинг удлинняет любую фичу
2. рефакторинг удлинняет все фичи вместе взятые

А теперь читаем вместе твои аргументы:

Я написал — "может". Естественно, никаких гарантий этого не существует.

Итого — всего лишь твоё мнение, а гарантий 1 и 2 по твоим же словам не существует. Итого — в сухом остатке одно твое мнение.

I>>А ты — нечитатель. Неопределенность и есть причина того, что внятных оценок никто дать не может.
ARK>Возможно. И рефакторинг никаких неопределенностей не устраняет, однако добавляет новые

Прикинь, решил ты фото детей повесить в рамку на стену. Взял дрель-перфоратор, что бы просверлить отверстие под дюбель и ненароком просверлил себ кисть. Тебя это не остановило, ты решил дюбель забитьв стену, но раздробил молотком кисть. А когда закручивал крюк, случайно напоролся глазом на отверку.

Картина понятна ? Надо ли объяснять, что подобный исход никак не говорит о том, что инструменты ничем не помогаеют ?

В перевод на руский — рефакторинг помогает в том случае, когда применяется по назначению — для исправления проблем с кодом.
А это значит, что сначала нужно идентифицировать проблему, убедиться, что есть решение, и далее это решени сформулировать.
Без этого никакой рефакторинг не поможет.

Более того любые изменения кода без этих шагов плодят хаос и увеличивают эту неопределенность.

I>>Разумеется. Если над кодом работает команда, то результат должен устраивать всех. Почему рефакторинг должен выделяться ?
I>>А ну как ты переписал код, а Вася его выбросил и написал свой. Чем это лучше твоего примера ?

ARK>Ничем не лучше. И рефакторинг точно так же не гарантирует того, что над этим кодом никто больше не будет работать.

Ну ка, подробнее, что за чудо такое, когда ты выбрасываешь проблемный код, а он у тебя продолжает мозолить глаз и требовать внимания ?

Пример — у нас был небольшой компонент, на пять сотен килобайт. Изменения в нем делались от минуты до месяца и даже полугода. Эстимейты были соответствующие и пять лет никто его не трогал.
После того, как завершился рефакторинг, люди даже забыли, что с этой частью были какие то проблемы. Изменения — исчезли пять наследников, объем кода компонента ужался вдвое, появились внятные связи, повыкидывали кучу вспомогательных доеров, хелперов и полу-компонентов-помогаторов. Скажем, преобразования координат были в сотне мест кастомным кодом(это не шутка), стали в одном месте матричным способом. И это безо всякого переписывания, исключительно средствами автоматического рефакторинга.
На рефакторинг компонента ушел год. Это много. Зато следующие два с половиной года продукт развивался именно за счет этого компонента, т.к. удалось ввести оптимизации и увеличить объемы данных примерно в 10 раз, скорость отрисовки от 2 до 1000 раз, а кучка трудно-выполнимых ручных работ стала выполняться через форм эдитор.
И вот это все делалось исключительно через рефакторинг, кроме финальной интеграции, были причины.

То есть — девелоперы перестали иметь дело с проблемным кодом. То есть, с проблемным кодом больше никто не работает.

Кстати говоря, вот товарищи, которые начали писать заново, читай — переписывать, никуда не пришли, через какое то время выбросили свою поделку и все труды, перешли на 3rd party, но в итоге им это мало чего дало — выглядеть стало красивше, но ни объемов, ни фич, а прикручивание всего лишь контекстного меню превратилось в дикую содомию

Вот это все про рефакторинг, а тебя послушать, так какое то божественное чудо воскрешения мертвого кода — ты его удаляешь, а наутро он снова на месте.

ARK>>>Тем не менее, в общем случае один и тот же кусок кода может правиться много раз.
I>>Именно — и фактор неопределенности играет ровно столько же раз.

ARK>Я тут говорил про рефакторинг, если что.

С твоих слов после рефакторинга проблемы почему то не уходят. Ты рефакторинг похоже путаешь не только с переписыванием, но и с улучшайзингом.
Для меня это какая то дичь — сели решать проблему, идентифицировали, поставили диагноз, подобрали лечение, лечение прошло успешно, но код каким был, таким и остался.
Каким образом такое возможно ? Старый код сам себя коммитит в мастер ?

I>>Поэтому и надо разделять рефакторинг — изменения с определенными гарантиями, и переписывание, где нет никаких гарантий.

ARK>На практике это одно и то же. Гарантий ты никаких не получишь ни в том, ни в том случае. Можешь разве что разделить _намерения_. Но сам процесс особых различий не несет.

Рефакторинг это только такие изменения, которые дают гарантии и максимальный контроль. Например, если я переименовываю переменную, то я получаю гарантии от
1 ИДЕ — переименована ровно одна переменная и сведения о отсутствии конфликтов
2 тесты — зеленые, значит все хорошо
3 ревью — такое маленькое изменение легко отследить при помощи обычного дифа.

А если ты перепилил всё тело функции и вроде бы результат тот же, то это не рефакторинг, потому как а хер его знает, какие ты внёс сайд эффекты, достаточно ли дня них тестов, нет ли трудновоспроизводимых багов и тд. Анализировать надо все изменения целиком.

I>>Может. А если изначально отказаться от гарантий, то гарантировано получаешь хаос
ARK>Ну, это просто манипуляция терминами.

Это факты. У меня ощущение, что ты путаешь общее и частное, потому как отсутствие контроля и его наличие нзываешь одним и тем же словом.

С таким же успехом ты можешь себя назвать, ну, скажем, млекопитающим. Другой пример — дерево есть частный случай графа. То есть — граф, а стало быть все то же и так же, как в графе.
Надо ли объяснять, что у деревая есть свойства, которые отсутствуют в произвольном графе, и мы его используем именно ради этих свойств?

I>> У вас похоже ни IDE, ни инструментов, ни тестов, ни тестировщиков не изобрели. Так что ли ?

ARK>Ну я понял, ты просто называешь переписывание кода без изменения поведения — рефакторингом. Это твое право, но по сути это все равно переписывание. Но ты переписыванием называешь только один частный случай.

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

I>>Это именно обоснование. Или ты думал я тебе научный труд принесу ?

ARK>Это набор голословных утверждений, не подкрепленных ничем.

Этот набор успешно предложил и обосновал Фаулер двадцать лет назад и с тех пор это трансформировалось в целую методологию.
Судя по твоим словам, ты наверняка этого не знал

I>>Ты говоришь, что у Оракла плохой код. Из этого никак не следует, что рефакторинг не применялся , неприменим и тд.
ARK>Почему же, плохой код и отсутствие рефакторинга — это сильная корреляция.

Ну и детский сад. Корреляция и причина это разные вещи!!! Переписывание и рефакторинг могут дать и часто дают один и тот же результат и это вобщем то норма.
Например, ты написал цикл, где само тело цикла скопировано сто раз. Теперь надо решить эту проблему и устранить дублирование, поскольку есть следующая фича которая затрагивает этот цикл.
В дагном примере корректное переписывание, и правильный рефакторинг дадут в итоге цикл без дублирования и код будет идентичным.

Разница только в том, какая у тебя степень уверености — в рефакторинге, если ты ничего не сломал на каждом шагу, то ты ничего не сломал вообще, уверенность высокая. В переписывании — а хер его знает, т.к. проанализировать надо надо будет одни куском.
Шашлык небось на кусочки режешь и проглатываешь. Или ты из тех, кто жарено мясо глотает килограммами не жуя ?

I>>Да хоть по году на мелкий баг, тебе то что с того ? Рефакторинг нужен в том случае если это становится проблемой. Захочешь, скажем, фичи вводить намного быстрее. Каким таким способом ?

ARK>Не знаю, видят ли они какие-то проблемы. Я вижу, что экономическая эффективность рефакторинга под сомнением.

Из твоего примера про Оракл этого не следует. Ты путаешь корреляцию и причинно-следственную связь, впечатляет.

Из твоего примера ничего не ясно, может код был качественным, понятным, но чуваки не знали про рефакторинг и просто упоролись, пытаясь все переписать.
А может он был в сто раз хуже, но рефакторингом они подтянули его к нынешнему состоянию.

Вобщем вариантов масса, а у тебя какой то невнятный аргумент про корреляцию