Лучшие практики для разработки кода, дружественного к рефакторам - PullRequest
4 голосов
/ 13 мая 2009

Будучи Java-разработчиком в цикле гибкой разработки, я понял, что очень важно убедиться, что я спроектировал свои классы таким образом, чтобы я мог легко их реорганизовать без особых проблем. Я хочу знать, каковы лучшие практики, которым вы руководствуетесь в своем ежедневном цикле проектирования / разработки, которые помогают вам легко выполнять рефакторинг.
Например, я знаю, что я должен скрыть детали реализации за интерфейсом. Поэтому, если завтра я изменю реализацию, я не буду беспокоить клиентский код, который использует эти API. Точно так же я должен по возможности использовать «шаблон проектирования фабрики», чтобы изменение классов реализации можно было контролировать из одного класса фабрики, а не выяснять все места и изменять их.
Точно так же я хотел бы знать, какие все лучшие практики, которым вы руководствуетесь, помогут мне.

Ответы [ 6 ]

16 голосов
/ 13 мая 2009

Использовать TDD. Шутки в сторону. Написание тестов во время написания уроков заставляет задуматься о том, как они будут использоваться другими. Когда вы это сделаете, вы будете лучше писать абстракции.

На эту тему написаны целые книги:

  • Код завершен
  • Эффективная работа с устаревшим кодом
  • Чистый код
  • Рефакторинг
  • Рефакторинг к шаблонам
  • Agile Принципы, модели и практики

Каждый из этих способов затрагивает эту тему по-своему.

3 голосов
/ 13 мая 2009

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

2 голосов
/ 13 мая 2009

Это может звучать как круговые рассуждения, но я считаю, что это правда в моем опыте:

Рефакторинг это много.

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

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

1 голос
/ 13 мая 2009

Я бы порекомендовал взять две книги, если вы собираетесь делать много java.

Я бы порекомендовал Эффективные шаблоны проектирования Java и : элементы многоразового объектно-ориентированного программного обеспечения .

1 голос
/ 13 мая 2009

Мой ответ касается того, что является хорошим результатом после рефакторинга.

Методы должны быть ...

  • short - они никогда не должны быть больше экрана, заполненного кодом.
  • сделать максимум одну вещь:
    • вычислить значение
    • тест и ветвь
    • журнал
    • исключение защиты и броска
  • есть одна точка выхода - мои рассуждения ..
    • Если вам позже потребуется вернуться и что-то сделать с возвращаемым значением, все это происходит в одном месте.
    • Легко установить точку останова и проверить возвращаемое значение ...
    • Сумма СУХОЙ .
1 голос
/ 13 мая 2009

Не копируйте и не вставляйте (также известный как СУХОЙ: не повторяйте себя). Если какая-либо конкретная функциональность реализована не более чем в одном месте, то эту функциональность легче переопределить.

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