Re: [flexcoders] Re: Cairngorm is bad?

Fri, 18 Nov 2005 01:51:32 -0800

Anatole,

I do not agree that it is a big problem in refactoring serverside code. Sure if you have no unit tests for RIA client you will not be able to detect that something broken when you change server interface. But in agile methodology that is most popular now you always have to have tests. And it is not impossible to do them for RIA client.

Another thing that can help you is code generation. In our application we completely generate all Flex2Java interaction code (Business delegates for all java services and value objects), also we are trying to use strong typing as much as it is possible. So if you change server interface your RIA code will not compile in most cases.

I agreed with you that bright people can work without frameworks but the code they will produce will not be quite maintainable. One of the main benefits of the frameworks is that makes code to be more clean for other people who knows that framework, however it raise some bounds for developers. Also I think that any serious project should be built using single approach. By approach I mean coding conventions, framework, and style of framework usage. Each framework can be used in multiple ways but to succeed you have to choose your own. I did so many times and in most cases we deliver stuff in time.

--
Best Regards,
Mykola

On 11/17/05, Anatole Tartakovsky <[EMAIL PROTECTED]> wrote:
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
  
   





--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com



SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice

YAHOO! GROUPS LINKS



Reply via email to