Guide to maintainable (Java) software
- Start with a minimum set of frameworks, libraries and technologies. So start with plain Java SE, extend if needed to Java EE, use another frameworks afterwards.
- Minimize the amount of design and architecture patterns.
- Define constraints for the used patterns - or do not allow variations.
- Use coding and naming conventions.
- Always rely on standards first.
- Explain design decisions in short (list of items) and unambigous way.
- Take everything away from your design, what is not needed.
- Do not follow hypes - use reasonable arguments.
- Always document political decisions (they are rarely reasonable).
- Separate business logic from technology.
- Think about errorhandling, logging, monitoring because the coding begins
- Create a lean, and expresive project or architecture documentation (<=20 pages).
- ...be pragmatic. Theory does not work in the practice :-).
Web 3.0 just begun. ;-)
To me the most interesting part is they want a fat client in Java.
http://www.theserverside.com/news/thread.tss?thread_id=42351
Posted by reader on September 26, 2006 at 12:00 PM CEST #
14. Write your source for humans not for machines, since develeopers time is more expensive than new hardware ... ;o)
Posted by Mario Gleichmann on September 26, 2006 at 07:03 PM CEST #
Mario,
absolutely: premature optimization is the root of all evil :-)
Posted by Adam Bien on September 26, 2006 at 09:13 PM CEST #
15. Have people in the project team who knows what maintenance is (= who have already maintained software in the past for more than one year)
I see a lot of developers/architects talking about maintainable software but they have never maintained software for a longer period.
I already wrote about that in 2006:
http://simonmartinelli.blogspot.com/2006/12/some-words-about-maintainability.html
Posted by Simon Martinelli on August 20, 2009 at 01:09 PM CEST #
Thanks for the tips,
Perhaps every point will ask for it's own blog entry;)
However, somehow I didn't fully get these:
3- Define constraints for the used patterns - or do not allow variations.
8- Do not follow hypes - use reasonable arguments.
10- Separate business logic from technology.
If you could elaborate on these a lil bit, I ll be thankful.
regards,
- mark benz
Posted by mark benz on August 23, 2009 at 01:45 AM CEST #
Everyone (at least J2EE-Developer) knows this extremely bad design example for 10:
JSP including Java Business Code. The environment you find inside the JavaServerPage is clearly technology-dependent (namely JSP and Servlet-API).
So if you switch to another View-Technology you'll have to port all this embedded Business-Code into something stripping it away from the old JSP stuff and so you will kill the business code - definitely.
And probably you cannot fall back on some existing unit-tests to test you're ported business code working well as before, because before it only worked interlaced with JSP technology...
Posted by Jonny Newald on January 31, 2011 at 12:50 PM CET #
Everyone (at least J2EE-Developer) knows this extremely bad design example for 10:
JSP including Java Business Code. The environment you find inside the JavaServerPage is clearly technology-dependent (namely JSP and Servlet-API).
So if you switch to another View-Technology you'll have to port all this embedded Business-Code into something stripping it away from the old JSP stuff and so you will kill the business code - definitely.
And probably you cannot fall back on some existing unit-tests to test you're ported business code working well as before, because before it only worked interlaced with JSP technology...
Posted by Jonny Newald on January 31, 2011 at 01:27 PM CET #