Adam Bien's Weblog

Monday Sep 25, 2006

Guide to maintainable (Java) software

  1. 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.
  2. Minimize the amount of design and architecture patterns.
  3. Define constraints for the used patterns - or do not allow variations.
  4. Use coding and naming conventions.
  5. Always rely on standards first.
  6. Explain design decisions in short (list of items) and unambigous way.
  7. Take everything away from your design, what is not needed.
  8. Do not follow hypes - use reasonable arguments.
  9. Always document political decisions (they are rarely reasonable).
  10. Separate business logic from technology.
  11. Think about errorhandling, logging, monitoring because the coding begins
  12. Create a lean, and expresive project or architecture documentation (<=20 pages).
  13. ...be pragmatic. Theory does not work in the practice :-).


NEW: Java EE 7 Testing and Quality Workshop

A book about rethinking Java EE Patterns

Comments:

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 #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
...the last 150 posts
...the last 10 comments
Links
License