Dear Vangel, I encourage you to read Joel's article on testing the software.
http://www.joelonsoftware.com/articles/fog0000000067.html The value of reloadable service is questionable. If you write tests you don't have to start the application at all if you are fixing bugs in services. The cycle of fixing bugs in services is much, much shorter if you write tests. You change a line of code, click the "Test" button in your IDE and see the results of the test immediately. You don't have to switch to browser, reload the page, etc. On Fri, Feb 12, 2010 at 12:27 AM, Vangel V. Ajanovski <a...@ii.edu.mk>wrote: > 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. > > > > -- Best regards, Igor Drobiazko http://tapestry5.de/blog
