Geek Answers Handbook

Recommendations for developing code that supports refactoring

As a Java developer in a flexible development cycle, I learned that it is important that I design my classes so that I can easily reorganize them without much pain. I want to know what best practices you have in your daily development / development cycle, which will help you easily refactor.
For example, I know that I have to hide implementation details behind the interface. So this event, if I change the implementation tomorrow, I do not violate the client code that uses these APIs. In the same way, I should use the factory design template, where possible, so that I can control the change of implementation classes from one factory class, and not detect all the places and change them.
Likewise, I would like to know what all the best practices you are following will help me.

+4
source share
6 answers

Use TDD. Jokes aside. Writing tests when you write your classes makes you think about how others will use them. When you do this, you will be better off writing abstractions.

Entire books have been written on this subject:

  • The code is complete.
  • Effective work with outdated code
  • Clean code
  • Refactoring
  • Refactoring for templates
  • Flexible principles, patterns and practices

Each of them touches on this topic in a unique way.

+16
source

You should have a bunch of unit tests that can prove that the code base was not (accidentally) affected every time with the refactor.

+3
source

This may seem like a bit of a cool argument, but I think this is true in my experience:

Refactor it a lot.

Many of the answers here (especially a strong test suite) are great advice and help a lot, so let me make it clear that I am also for these preventative measures.

Firstly, it is always easy to change (when it is small). Then, as a rule, you need to go through several bouts of complex refactoring before you have a breakthrough and get something really flexible.

+2
source

Do not copy and paste (also known as DRY: do not repeat it yourself). When any given functionality is implemented in no more than one place, it is easier to implement this functionality.

+1
source

My answer relates to what is a good result after refactoring.

Methods should be ...

  • short - they should never be larger than a screen full of code.
  • do no more than one:
    • calculate value
    • test and branch
    • Journal
    • throw protection and exclusion
  • there is one exit point - my reasoning ..
    • If you need to go back and do something with the return value, all this happens in one place.
    • Easy to set breakpoint and check return value ...
    • Amounts DRY .
+1
source

I would recommend putting together two books if you are going to do a lot of java.

I would recommend Effective Java and Design Patterns: Elements of reusable object-oriented software .

+1
source

More articles:


All Articles