Java (EE) Fallacy 3:We have only to consider ther development phase. The maintenance and production are not important. 📎
- Try to put everything in the main-method.
- Try to minimize the number of methods, classes and exceptions
- Do not think about exception handling – a big try-catch block is often good enough
- Do not provide levels of abstraction (or layers) - it is only a dead code.
- Just start hacking!
- In case you need the same portion of code just reuse this section using the proven „copy and paste“ strategy
- Prefer static methods, objects are too new (legacy systems, c-languages etc. were effective enough…).
- Developers are creative – do not prescribe naming conventions, patterns or idioms.
- In case the requirements change – just throw the affected piece of code (in extreme cases the whole main-method) away and copy the pieces of remaining code together again.
- Do not comment. Try to generate Javadoc (is faster)
- Do not create expensive UML-documentation - just reverse engineer you code after deployment.
This approach is really fast, but you should not stop coding for longer period of time or go to vacations.
Having eager developers, your project will go likely in budget and on-time into production. If you think about it: patterns, design approaches, frameworks are really not needed. Especially scripting languages like JavaScript or VB are very efficient, so it is possible to develop a complex application without any design or architecture overhead.
Now the question: Why we need then platforms, patterns and defined architectures? All the additional effort is needed only because of lowing the costs of maintenance. Especially project managers make the common mistake and consider only the development phase and not the whole lifecycle. But the maintenance, bug fixing, realization of extensions are much more expensive, than the actual realization of the system.
A structured system is easier to understand for new developers in team. Java EE is very similar in this case. It comes with already existing services like: transactions, monitoring, defined deployment, logging, fail over, diagsnostic services, so it is much easier in production environment to monitor the application. These facts become more relevant after the first deployment.
If you have some knowledge in threading and distributed computing, it is not a big deal to reinvent the wheel and reimplent parts of Java EE. It is relatively easy to use threads, instead of JMS, DAO instead of CMP, or JDBC-Connection instead of JTA. It is easy for a skilled developer, but is such solution also maintainable?
You can even use complete other frameworks - but the question rises: why?
From my point of view the architect should concentrate on standards. So first Java SE should be considered, in case it is not sufficient, Java EE can be used. After these steps the usage of additional or complementary frameworks can be considered. Also in this case "industry" standards like Apache, Eclipse, java.net, sourceforge.net etc. should be used.
It is more likely to find skilled developers,trainigs and literature for standard technology, than esoteric frameworks.
I described the architectural approach in my last, but german, book "Enterprise Architekturen".