|
Mykola,
I just want to clarify the point
I was making about the refactoring and non-heterogenic environment. There is a
huge difference between RIA and desktop application. It is called "distributed
non-heterogenic" application. Refactoring the back-end Java code will
not cause compilation notifications of missing/changed fields/methods in UI -
they have to be found via global search and (with larger apps) through
testing - and can easily slip into production, especially if done in
maintenance phase. The same applies to changes in UI - very easy to get out of
synchronization with back-end.
Here is simplier example for
desktop application developers. Let us say you do changes to non-heterogenic
piece of application - SQL table used by application - changing column names and
datatypes. Compiler (unless it is integrated with pre-compiler/code generator)
is not going to catch those and prompt you that your queries are no longer
correct. You can start getting random errors based on overruns of the buffers
due to field length, etc.
While programming is definetly
fun, retesting large application after each change is definetly not. Writing
test cases to anticipate future enhancements is not possible, adding ones along
the change is not a reliable solution but rather desparate measure to plug the
obvious hole.
I am aware of 2 approaches
to reduce the impact of refactoring (while hopefully reducing coding as
well):
1. usage of higher-level "model" objects
encapsulating communications as well - i.e. "super" dataProviders that are aware
of retrieval/update methods, maintain state, provide diagnostics and can be
submitted as a part of bigger transaction - just few features to be delt
within any application. Such "models" can also greatly simplify coding of
datagrids, forms and other databound controls
2. use code generators to be included as a part of
"build" process. You can produce "proxy" objects that can facilitate strong type
checking in either java of flex. They can improve performance of the software
execution as "guesswork" is taken out of both client and flashgateway software.
You can also generate UI resources so initial form painting is less time
consuming.
I use both approaches - actually one on the
top of the other - to reduce amount of "manual" code. That drives application
into using high-level objects instead of framework - and I personally like
it.
However I would say for one person who uses these
approaches there are 10 people using frameworks. It come down to the project
management - small teams of highly trained specialists vs uniformly trained in
framework large development teams with predicatble (while long) development
schedule/replaceable resources. If you foresee the lifecycle of the project to
be completed via reducing the team toward the retaining the better technology
people of the team and insuring the quality across the modules (and company
budget allows for that) then the framework-less approach is the way to go. If
you anticipate to retain maintenance crew of the least creative people that
would prefer to do "spot" fixing then low-level code and framework might be
better choice.
Here is very simple article on abstractions that is
also applicable to refactoring:
Toward the end, there is Joel's estimate what
using code generators or frameworks amounts to:
"The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time." Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning. And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder." Sincerely,
Anatole Tartakovsky
917-304-3381
----- Original Message -----
|
- Re: [flexcoders] Re: Cairngorm is bad? Anatole Tartakovsky
- Re: [flexcoders] Re: Cairngorm is bad? Mykola Paliyenko
- Re: [flexcoders] Re: Cairngorm is bad? Anatole Tartakovsky
