This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
We have 4+ years old mature, in production application. The problem that I am facing right now is, most of the time when we need to implement some functionality we end up duplicating a method, HQL (Hibenate), business validation rules that already exists somewhere in the codebase. I think we end up doing it because code(method/HQL etc) is not properly indexed/documented and it is hard to find that method/HQL to be reused. Sometimes the reason is also that developer did not think in a broad way while writing a method to include all possibility and because of that it is not possible to reuse the same method and we end up duplicating almost similar but new method (Developer does not want to modify existing (better to say legacy) method thinking it might break some existing functionality).
If you also have ran into this type of issues, how do you handle them?
If documentation is the way to go, how do you document the codebase such a way that it is easy to find existing functionalities? Same problem with managing HQLs too?
The reason I have approached this is to refactor the code as you go along. Don't copy -refactor. When you find code that you can copy, think of how you would modularize it so you can call the same module from both places. Then create the module, and change both places.
Yes, you might be breaking legacy code. That's where unit tests come in. You need a good base of unit tests before you can do this refactoring. What is that you say? Don't have unit tests? Build unit tests, then test the legacy code with the unit tests, then refactor, then retest refactored code
It's going to be very difficult at first. Fixing legacy code is a lot like straightening out Christmas lights. It seems impossible at first, until you start doing it. Then when you start doing it, you realize it's more difficult than you thought, but as you keep doing it, it becomes easier and easier until you have a small jumble at your feet and you are like "tat was easier than I thought"
Joined: Sep 12, 2008
How do you keep track of methods among 10+ developers? I got your point about refactoring, but for that you should be aware about the fact that "that" method already exists somewhere in code.Then you can suggest to reuse or refactor them.
Saurabh Pillai wrote:How do you keep track of methods among 10+ developers? I got your point about refactoring, but for that you should be aware about the fact that "that" method already exists somewhere in code.Then you can suggest to reuse or refactor them.
They are organized in classes and packages. That organization helps you find the relevant ones. That assumes developers have placed methods in logical places. If not, you 'll need to read code and do some searching or asking around.
You need to have a high level idea of how the system will look like when it's completely refactored. You need to map out your modules at a high level, and designate a package for each module. For example, you might say my modules are UI, services and DAO. Create 3 packages for each of the modules. This way you will have a convention to follow before hand, and everyone won't do their own thing
Secondly, you need to have code reviews among yourselves. I agree with Jeanne that things should go in their logical place, but the problem is the term "logical place" is too subjective. What might be logical to you might not be logical to other. It might not event be logical to yourself in 3 months. It's good to have someone else look at what you did and see if it makes sense to them too. Generally speaking, if 2 people say "yeah that makes sense", chances are it will make sense to someone else. They might come up with an idea for an improvement
Lastly, don't strive for perfection. Strive for constant improvement. Refactoring is an iterative process. It's never complete. You can always keep refactoring. You will even find ways to refactor your refactored code. If you have a deadline and refactoring the code makes you miss the deadline, reduce the scope of refactoring so you can meet your goal, and then make a note so you can do the actual refactoring in the next release.
Saurabh Pillai wrote:If documentation is the way to go, how do you document the codebase such a way that it is easy to find existing functionalities? Same problem with managing HQLs too? Thank you.
Depending on your IDE and on the quality and current organisation/documentation of your code, you may be able to reverse engineer things like class diagrams from your code using your IDE. This may give you at least a starting point for working out how to re-structure/re-factor your code - even a printed diagram can be a useful starting point if you can sketch on it to work out where things should go. You might also be able to make sense of the data-access code by looking at the ERD for the DB as well. But it's still going to be a lot of work - good luck!