Процесс или шаги для рефакторирования класса богов в устаревшем приложении С++?

Это приложение было написано без знания принципов разработки (SOLID) предыдущим разработчиком. Самая важная проблема в приложении заключается в том, что он имеет класс богов с множеством операторов switch. Эта непродуманная структура затрудняет поддержку приложения. Конечно, никакого модульного тестирования вообще нет.

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

BYW, у меня есть книга "Эффективная работа с устаревшим кодом". Поэтому вы можете указать, какую часть книги я должен прочитать для этого: -)

2 ответа

Переключатели являются очевидной целью рефакторинга. Но могут быть и другие. Вы даете нам недолго.

Я часто трачу много времени на массирование кода, переписывая его так, что я могу изменить тип, используемый для комментирования/раскомментации нескольких строк.

Для swich на перечислении может быть полезно определить структуру, содержащую один элемент: значение перечисления, и имеет неявное преобразование в значение перечисления. Используя typedefs или макрос, вы можете убедиться, что ваш новый тип передается вместо enum. Если у этого есть нежелательные побочные эффекты, верните, исправьте реализацию и попробуйте использовать свой новый тип.

Затем переместите код коммутатора в функцию-член нового типа, по одному коммутатору за раз.

Если в этом процессе требуются модульные тесты, это зависит от вас.


Каков хороший процесс для атаки на эту проблему?

"не исправлять, если он не сломался".

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

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

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

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

Имейте в виду, что ваша цель - не совершенствовать код. Ваша цель - обеспечить быстрое и эффективное решение текущей проблемы, используя минимальный объем ресурсов (время/усилия), получая максимальную награду за вашу работу. По моему опыту, отклонение от этого принципа крайне нездорово.

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

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

licensed under cc by-sa 3.0 with attribution.