Как вы реорганизуете большую грязную кодовую базу?

Question

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

Я нарушил все правила, о которых читал за последний год. Есть классы с множественными обязанностями, есть косвенный доступ (я забыл термин - что-то вроде foo.bar.doSomething()), и, как я сказал, это не очень хорошо прокомментировано. Кроме того, это начало игры, так что графика связана с данными, или места, где я пытался отделить графику и данные, я сделал данные public, чтобы графика могла иметь доступ необходимые данные ...

Это огромный беспорядок! С чего мне начать? Как бы вы начали что-то вроде этого?

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

---

Обновление через два дня: Я рисовал UML-подобные диаграммы своих классов и по пути ловил некоторые из "Низко висящих фруктов". Я даже нашел несколько фрагментов кода, которые послужили началом новых функций, но, пытаясь все уменьшить, я смог удалить эти фрагменты и сделать проект более понятным. Я, вероятно, собираюсь провести рефакторинг как можно больше, прежде чем собирать тестовые наборы (но только те вещи, которые на 100% уверены, что они не повлияют на функциональность, конечно!), Так что мне не придется рефакторинг тестовых наборов, так как изменить функциональность. (Как вы думаете, я делаю это правильно или, по вашему мнению, мне было бы легче смириться с этим и сначала написать тесты?)

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

Спасибо всем, кто ответил до сих пор!

---

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

Для этого я делаю четыре вещи, когда необходимо изменить код:

1. Определите, для чего предназначался код
2. Нарисуйте UML и диаграммы действий участвующих классов
3. Найдите подходящий дизайн
4. Определение более четких имен для текущих классов и методов

Answer 1

Я думаю, что вы должны использовать Eclipse в качестве IDE, потому что он имеет много плагинов и бесплатен. Теперь вы должны следовать шаблону MVC и да, должны писать тестовые примеры, используя JUnit. У Eclipse также есть плагин для JUnit, и он предоставляет кодвозможность рефакторинга, чтобы уменьшить ваши трудозатраты. И всегда помните, что написание кода не важно, главное - писать чистый код. Теперь давайте комментарии везде, чтобы не только вы, но и любой другой человек читал код, а затем читалкод он должен чувствовать, что читает эссе.

Answer 2

Возможно, вы захотите взглянуть на книгу Мартина Фаулера Рефакторинг . Это книга, которая популяризировала термин и технику (я думал, когда брал его курс: «Я делал много всего этого, я не знал, что у него есть имя») Цитата по ссылке:

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

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

Вот каталог рефакторингов .

Answer 3

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

Answer 4

Выбрось, построй новый.