Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Object-oriented software maintenance
- Thread starter cgre84
- Start date
Ummm, Google?
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
- Thread starter
- #3
What I've seen is that it's as possible to write bad O-O software as it was in procedural languages.
The difference between maintainable code and non-maintainable code is having a good design, and having someone enforce that the design is followed thru the entire life of the product.
In other words, there is nothing that the language, the development environment, or external tools can do to prevent bad code from being written -- it all comes from having good management.
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
The difference between maintainable code and non-maintainable code is having a good design, and having someone enforce that the design is followed thru the entire life of the product.
In other words, there is nothing that the language, the development environment, or external tools can do to prevent bad code from being written -- it all comes from having good management.
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
Of course you can often refactor yourself out of a bad situation, but to do it easily you must have a set of unit tests (JUnit, NUnit or similar) to prove that the changes you are making don't break the code.
Even well-designed code can decay over time as new features are bolted on later, often by people who don't have a grasp on the big picture. Refactoring can allow you to 'tune up' older software to keep pace with new requirements, and make it more maintainable.
If you are serious about this, I'd recommend Refactoring: Improving the design of existing code by Martin Fowler. As well as showing why to refactor, when to refactor, and how to refactor, he catalogues a large number of refactoring patterns that will get you started.
But unless you have automated unit test cases you can run over and over (or are prepared to write some) you probably shouldn't even consider refactoring your application.
Even well-designed code can decay over time as new features are bolted on later, often by people who don't have a grasp on the big picture. Refactoring can allow you to 'tune up' older software to keep pace with new requirements, and make it more maintainable.
If you are serious about this, I'd recommend Refactoring: Improving the design of existing code by Martin Fowler. As well as showing why to refactor, when to refactor, and how to refactor, he catalogues a large number of refactoring patterns that will get you started.
But unless you have automated unit test cases you can run over and over (or are prepared to write some) you probably shouldn't even consider refactoring your application.
Yeah, if the app is so far gone that no one understands it, at that point you're probably better off starting from scratch, working from a set of business requirements.
Trying to figure out the original business requirements from the existing code will be more expensive than starting over would be.
But if the culture at the office is "just slap something in there to get it to work", you'll have a tough time selling this approach.
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
Trying to figure out the original business requirements from the existing code will be more expensive than starting over would be.
But if the culture at the office is "just slap something in there to get it to work", you'll have a tough time selling this approach.
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
Hello.
This paper called "The Art of Maintenance Programming", authored by Nemanja Trifunovic could be of your interest:
Best regards,
Polu.
This paper called "The Art of Maintenance Programming", authored by Nemanja Trifunovic could be of your interest:
Best regards,
Polu.
- Status
Similar threads
- Locked
- Question
- Locked
- Question