On 11.02.2010 23:17, Howard wrote: > You wouldn't be able to change service interfaces this way, or module > classes (including contributions and the like) ... but changing a > service implementation should be a snap. This would especially be > useful for DAOs while creating and tuning database queries. > In our project 90% of all bugs were either in page classes or in DAO implementation classes (bad queries, queries returning nulls, queries returning more than a single row etc). The former are reloadable, the latter not. So if we would be able to change the DAO impl. classes while developping it would speed things up by at least 50%.
In fact we rarely have the need to change the interface of a service. It is usually that we were wrong in the insides of the code behind. Some of the bugs were detected when we went in production and the application was under pressure by real users because we didn't have time for proper testing. I had to restart the whole application many times during peak load, and sometimes even the entire Tomcat service just for a simple change of a constant in a query that was only reflected in a single web page. I know that I should test first, and I know that I should enforce some QA before going in production for any serious application. But sometimes you just don't have the time and resources to do it, and RAD via many prototypes and fixing code on the fly is the best you can do. So I would urge for any type of fix - even a quick fix/patch, not a full release, even if it would only help in a very constrained case - for example only in the case of dao implementation classes and only when no modification is done to class properties and method signatures.
smime.p7s
Description: S/MIME Cryptographic Signature
