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 :-).
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)
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:
Number of posts: 2418
Number of comments: 6163
Yesterday's hits: 18820
Today's hits: 17675
Post reads / hour: 685
Top posts:
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 #