Refactoring

[_Bers]

Кстати Вы далеко не первый дающий подобные рекомендации

я не давал рекомендаций.

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

Достаточно большой проект (если он действительно большой) - это на самом деле кучка проектов по меньше.

Знать все от и до может быть не возможным в принципе.
Однако, обычно такой потребности и не возникает.

Обычно достаточно понимать и разбираться с теми вещами,
с которыми непосредственно приходится работать.

Вам нужно отдавать себе отчет в том, что именно вы хотите рефакторить.

Возвращаясь к теме. Что хочется/нужно сказано в первом посте

но он не содержит конкретику.

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

[Igors]

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

- число методов класса 216. (Однострочных get/set нет, все пока public). Это оказалось для меня полной неожиданностью, я-то думал там штук 50, ну может 100, а оказывается айсберг намного больше.

- штук 6-7 ф-ций были написаны дважды (в местных namespace)  
- глобальный указатель на синглтон был объявлен (под разными именами) 3 раза
- пока перебирал текст, наметилось еще пара-тройка мест что можно удачно "схлопнуть" (мои расчеты оправдались)

Сколько новых багов появилось в рез-те моих действий - пока не знаю

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

Та действительно! Что именно рефакторить - не знает, не имеет ни цели ни плана, ну вот захотелось ему этим заняться! Все-таки это не так, да и вообще надо лучше думать о людях  

Есть проблема "концептуальных" (ну или "архитектурных") постов. Они может и хороши, но... после неск прочитанных предложений такие посты закрываются навсегда. Причина проста: уж очень бурным потоком излагается специфика проекта, что немедленно вызывает ответную реакцию

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

И мне не хотелось бы повторять эту ошибку. Я подумаю как сделать это "в популярной форме", тогда отпишусь. Не "сию минуту", но и не откладывая в долгий ящик

[Авварон]

Сколько новых багов появилось в рез-те моих действий - пока не знаю

Старайтесь делать атомарные коммиты (изменения). Тогда часть из них будет гарантированно не ломающими (например, переименования или изменение порядка параметров). Потенциально ломающим/меняющим поведение коммитам (изменениям) уделяйте больше внимания, возможно, пишите автотесты на старый код.

[Racheengel]

число методов класса 216

ох ты ж йожыг...

жаль, что всего кода не увидим, чтобы осознать глубину эээ... страданий, так сказать. Но кажется, что ад, батенька, сущий ад... Код то хоть на Qt или не особо? Просто кажется мне, что портирование на С++ дороже обойдется, чем заново наваять...

[Igors]

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

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

Я получил 3-4 новых бага с этими изменениями. Отлаживал в рантайм на 2 машинах, сравнивая значения переменных в старом/новом коде. Тоже не быстро, 2-3 дня ушло.

Просто кажется мне, что портирование на С++ дороже обойдется, чем заново наваять...

Не первый раз привожу эту ссылку, уж очень она мне нравится Решение "все переписать" - первое что приходит в голову, для этого не надо быть архитектором. Вот был "плохой" код, а мы напишем "хороший". Беда в том что нужно знать все детали ф-ционала, а это может потребовать неприемлемых затрат времени/денег. Часто все заканчивается на первом же вопросе заказчика, типа "ну хорошо, а когда новый код будет готов?" - и ответа нет, остается брать десятикратный запас

Сейчас перевожу 2 простых окна, одно просто просмотрщик картинки, другое оно же но плюс расчеты (рабочие, их можно не трогать). Здесь мне удалось выучить все "детали дизайна", ну и очень много старого кода рисования который с успехом может быть замещен на Qt. Но почему-то дело движется совсем не быстро, вот уже вторая неделька пробегает...      

[Bepec]

В такой работе много рутины, аля написания кода. Смотрите, анализируйте, автоматизируйте

PS сам таким маялся, до сих пор штук 10-15 программ под каждую ситуацию в коде лежит.

[Igors]

В такой работе много рутины, аля написания кода. Смотрите, анализируйте, автоматизируйте

PS сам таким маялся, до сих пор штук 10-15 программ под каждую ситуацию в коде лежит.

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

[Bepec]

А я в свою очередь желаю вам читать все темы и при желании отписываться

PS будьте взаимовежливыми и ещё скажите что я неправ

[Racheengel]

Не первый раз привожу эту ссылку, уж очень она мне нравится Улыбающийся Решение "все переписать" - первое что приходит в голову, для этого не надо быть архитектором. Вот был "плохой" код, а мы напишем "хороший". Беда в том что нужно знать все детали ф-ционала, а это может потребовать неприемлемых затрат времени/денег. Часто все заканчивается на первом же вопросе заказчика, типа "ну хорошо, а когда новый код будет готов?" - и ответа нет, остается брать десятикратный запас

Ну а что, Главный Архитектор не прав был, что ли?

Я понимаю, что задача не простая, требует ресурсов и времени. У нас на фирме была такая же проблема - куча старого говнокода, который худо-бедно работал, иногда что-то там допиливалось, все плевались на него (ибо реально ГОВНИЩЕ было), но вот сесть и переписать - сразу же возникали вопросы "а кто это все оплатит? а сколько времени надо? а кто это делать будет?" ну и т.д. В итоге только на обсуждение того, надо переписывать или нет - ушло половина времени, за которое код таки БЫЛ ПЕРЕПИСАН (ну, программеры продавили в конце концов решение). И в итоге это решение окупилось.

[Igors]

Ну а что, Главный Архитектор не прав был, что ли?

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

[Racheengel]

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

[Igors]

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

Сомневался отвечать или нет, Ваш пост ничего нового не вносит. "По-хорошему надо все переписать" - то же самое сказал горе-архитектор Но как Вы представляете себе процесс переписывания? Похерить все старые исходники и хедеры и начинать все с чистого листа? Поверьте, это не катит. А иначе Вы немедленно попадаете в липкие лапы старого кода.

[Авварон]

Сомневался отвечать или нет, Ваш пост ничего нового не вносит. "По-хорошему надо все переписать" - то же самое сказал горе-архитектор Но как Вы представляете себе процесс переписывания? Похерить все старые исходники и хедеры и начинать все с чистого листа? Поверьте, это не катит. А иначе Вы немедленно попадаете в липкие лапы старого кода.

Только закончил переписывание очередного сервиса с нуля:(
Напишите автотесты на старый код, это поможет при написании нового. При полном покрытиии кода (что маловероятно), когда закончите новый код, у вас будет работоспособная программа.

[Igors]

Напишите автотесты на старый код, ..

А что такое "автотесты"? Мельком глянул http://habrahabr.ru/post/238353/ - типичный хабровский треп

[Авварон]

Любые тесты, автоматически тестирующие функционал. Масло масляное:) У нас 2 типа тестов - есть юнит тесты на гугл-тестах/qt-тестах, к-ые тестируют конкретные классы. И тесты, проверяющие работу сервиса по методу черного ящика - что-то на вход дали (сообщение), что-то ожидаем увидеть (другое сообщение). Понятное дело, для гуев второе не подходит, но подходит разделение гуй\негуй и юниттесты негуя.