Рефакторинг - можно?

У нас периодически можно. Формально никто не запрещает(пока...)

вроде тоже не запрещают, кто тебе такое сказал?

На форумах периодически проскакивает. Вот сейчас
http://catty-ua.livejournal.com/68401.html?thread=1559857#t1559857
здесь промелькнуло.

Я с таким запретом не сталкивался. Видимо зависит от масштабов поддерживаемого проекта и уровня разработчиков. Такой запрет нам говорит, как бы, "Смотрите, дети, ничего здесь не сломайте!". :)

А мне спецзадание дали - рефакторинг кода провести.

Потому что в лапше из if-ов в одном файле никто уже не мог разбираться.

А теперь - 6 классов с четкой иерархией.

Чаще всего из-за отсутствия юниттестов, ибо без них никакой рефакторинг большого кода невозможен в принципе.

я думаю потому что рефакторинг, с точки зрения руководителей, не добавляет фич, зато отнимет кучу времени(если проект большой) и добавит глюков. Вот они и думают что раз работает то лучше не трогать(мое имхо).

> Вот сейчас http://catty-ua.livejournal.com/68401.html?thread=1559857#t1559857 здесь промелькнуло.

> * рефакторинг запрещён. Можно только фиксить баги

может быть, у них с ресурсами затык, и выбирают что поприоритетнее, посрочнее? А юнит-тестов нету нифига, и не трогают чтобы ненароком чего не сломать?

Видел пример наоборот, про какую-то финансово-торговую систему на Эйфеле. Писалось сначала на С++, потом программеры обучились в ISE и купили Эйфель (он в принципе в тот же С++ транслируется). Потихоньку начали переписывать С++ код на Эйфель с DbC, и юнит-тестами. Сначала просто, чтобы "понимать, как оно работает". Потом написали что-то вроде doxygen, чтобы из DbC инвариантов/пред/постусловий генерить документацию. Потом оказалось, что С++ кода осталось совсем мало, и он непонятно как работает. А с аннотированным DbC кодом с юнит-тестами наоборот, народ чаще работает, потому что ясно, как оно работает. В итоге получился нормальное решение почти всё на Эйфеле и чуть-чуть древнего ядра на С++.

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

У KDE вот прошел не слабый такой рефакторинг ...

что поделаешь, жастфофаны и пионэры..
..Ъ ынтерпрайс гуру не пользуются рефакторингом!!!111

> Уже не первый раз слышу о том, что во многих конторах запрещают рефакторить код.

И правильно делают. Не надо рефакторить, пока не приспичит.

> Это следствие отсутствия юниттестов и боязни привнесения новых багов?

Ты наивно думаешь что юниттесты покрывают все возможные ситуации?

> Уже не первый раз слышу о том, что во многих конторах запрещают рефакторить код

Просто поразительно. Наверное это такие ужасные конторы что сил хватает только на исправление багов?

Скажу по собственному опыту... был как-то случай... надо было добавлять новую фичу в одну из подсистем проекта... когда я увидел код, который мне надо было "доробатывать", я пришёл в ужас... немного отойдя, посоветовавшись с товарисчем, решили мы что надо немного "зарефакторить"... в конце дня был рабочий код, выглядящий во много раз понятнее, и уже с новой фичей... шведские коллеги (проект аутсорсовый) немного прифигели, когда посмотрели изменения, сказали что всё круто, и так действительно лучше, но советовали впреть так не болавать, и типа пусь остаётся как есть, и такие "глобальные" изменения производить только в крайнем случае... так что вот и ещё одна причина - аутсорс, в этом случае сторона, которая трансферит проект, не особо хочет чтобы там что-то кординально меняли... но это конечно верно только лишь в случае maintenance, если же идёт разработка в полный рост, то тут товарисчи на стороне молча смотрят, а ты кодишь... и тут желательно думать сразу, пока проект не перешёл в maintenance, а то потом уже не дадут поменять :)))

Вообщем как-то так...

Обычно понимание задачи меняется со временем, и архитектура/дизайн/алгоритмы тоже претерпевают изменения с каждой новой итерацией. Нельзя взять и сразу написать правильный код, не зная еще всей задачи. Мне кажется, что рефакторинг - это нечто само собой разумеющееся. Так что, для меня посыл тоже звучит дико.

> И правильно делают. Не надо рефакторить, пока не приспичит.

Если следовать такому принципу - может случиться момент, что переписать быстрее. В этом отношении я поддерживаю agile.

> Ты наивно думаешь что юниттесты покрывают все возможные ситуации?

Нет, этого и не нужно. Если проводить рефакторинг аккуратно и, по возможности, с применением автоматизированных средств, вероятность ошибки (в статически-типизируемых языках) очень низка. А более-менее вменяемое покрытие юниттестами сводит эту вероятность практически к нулевой.

я даже отчасти согласен: дай эстетам похозяйничать в коде - уйдет куча времени.

ну а если надо - то безусловно нужно рефакторить.

>> И правильно делают. Не надо рефакторить, пока не приспичит.

> Если следовать такому принципу - может случиться момент, что переписать быстрее. В этом отношении я поддерживаю agile.

Да. И именно в этот момент и надо рефакторить. А не тогда, когда кому-то захочется порефакторить just for fun.

>> Ты наивно думаешь что юниттесты покрывают все возможные ситуации?

> Нет, этого и не нужно. Если проводить рефакторинг аккуратно и, по возможности, с применением автоматизированных средств, вероятность ошибки (в статически-типизируемых языках) очень низка. А более-менее вменяемое покрытие юниттестами сводит эту вероятность практически к нулевой.

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

>Наверное это такие ужасные конторы что сил хватает только на исправление багов?

Им просто пилу точить некогда, им пилить надо.

Подозреваю, это также бывает при чрезмерно детальном планировании. Когда расписано время каждой строчки кода. И тогда невозможно объяснить, что, оказывается, можно что-то ускорить, добавляя лишний пункт длительностью с десяток других. "Да что тут думать, кодить надо" (c).

Ну и, само собой, из-за неграмотности руководства либо из-за технической кривости уже созданной системы.

PS. насчёт ошибок в ходе рефакторинга - я очень часто сталкиваюсь с тем, что рефакторинг удаётся сделать только с небольшими, но не совсем понятными, изменениями в семантике. Так вот, очень часто, если на это всё же закрыть глаза и грубо (нетождественно) изменить код в архитектурно желаемую сторону, то в качестве "побочного эффекта" исчезает пара-тройка багов. ...А если всё делать "корректно", то сначала надо рефакторить с сохранением багов, потом эти баги торжественно находить и исправлять, а потом снова упрощать код....

//капчу угадал только с 6-го раза

> Обычно понимание задачи меняется со временем, и архитектура/дизайн/алгоритмы тоже претерпевают изменения с каждой новой итерацией.

Это следствие ошибок проектирования. 99% программ на свете не такие основательные чтобы менять их алгоритмы, а в 1% алгоритмы не меняются, а заменяются целиком.

> Нельзя взять и сразу написать правильный код, не зная еще всей задачи.

Вообще писать что-либо, пока весь состав до последнего быдлокодера не осилил понять задачу, _нельзя_.

>> Нельзя взять и сразу написать правильный код, не зная еще всей задачи.

>Вообще писать что-либо, пока весь состав до последнего быдлокодера не осилил понять задачу, _нельзя_.

Толсто.

> Вообще писать что-либо, пока весь состав до последнего быдлокодера не осилил понять задачу, _нельзя_.

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