|
Re: Can You Write Quality Software Quickly?
|
Posted: Feb 2, 2005 9:42 AM
|
|
> It's hacking if you don't have automated tests, or don't > refactor to improve quality later. > > It's XP if you have automated tests, and you refactor your > code regularly rather than letting it go stale. > > I don't hack; I XP.
From my reading of XP Explained, it isn't XP unless you do all the practices together, because they depend on each other. If all you're doing is automated tests and refactoring, you're not doing XP, you're just doing P.
Nevertheless, one of the main issues I would take with XP is that it seems to suggest that we mindlessly follow a recipe all the time. It doesn't talk about when and to what extent to do testing and refactoring, or anything else that will help you improve quality. It says, always write a test before you write the code, and always refactor afterwords. I hear echoes of that XP mantra in your post. The when and to what extent question is really what this thread is about. In your experience, when did you feel that you didn't do enough testing or refactoring? When did you feel that you did too much?
In the particular case I described before, where I wanted to add weblogs to Artima and get it out the door fast, I chose to "hack" by writing more ugly JSPs in the way demonstrated by Jive 2.1, which I had licensed. I did it that way because "refactoring" the architecture provided by Jive would have been too costly and time consuming given the business context at the time. In that case, I deemed that writing tests and refactoring would have been exactly the wrong thing to do, and looking back I think that was the right choice.
One of the main things I didn't like about mixing business logic with presentation in those ugly JSPs is that I couldn't test the business logic. Having an MVC architecture gives you not only a nice separation of concerns between business logic (in the controller) and presentation logic (in the view), MVC also enables you to write tests where the return on investment is compelling: the controllers. I was in a situation where I couldn't write tests unless I refactored the architecture, and I needed to get weblogs out the door, so I didn't write any tests.
Luke Hohmann suggested to me that when he's leading a project, he doesn't want people doing any refactoring right before a release. At that time, the reward of refactoring isn't worth the risk that you'll break something that either delays the release, or goes undetected and wreaks havoc once the software gets out in the field. If something needs urgent fixing right before a deadline, you hack it in and get it out the door. But after the release, he puts time in the schedule before starting on new features to do a "post release entropy reduction," which is basically a time to refactor and clean up any messes created to meet the deadline of the previous release. I thought that was really useful advice.
I did eventually start refactoring the ugly JSPs using something Frank Sommers and I called "poor man's struts". At one point I felt it was reasonable to spend a few hours looking around at different MVC frameworks, so we spent that time but just felt that none of them were worth moving to at that point, so we rolled our own extremely simple framework. I had a bunch of URLs that I didn't want to break, such as the URL of this page, so I simply left the JSPs in place, but started pulling business logic out of them into external controller classes. I just called the controller method at the top of the JSP, and pulled the results of the context object returned into variables on the JSP page. The rest of the JSP was the view.
I never finished the process of doing poor man's struts. I usually refactored a JSP with poor man's struts if I needed to do some major editing on it. And while the poor man's struts refactor was an improvement, in truth I still wasn't happy with the result. Even after the refactor, the JSPs were still ugly because they are a mix of Java and HTML, angle brackets and curly braces. I could never keep track of indentation. It was too tempting to mix a bit of business logic here and there in the JSPs despite the presence of poor man's struts. I imagined also that in the future it would be harder to hire web designers to work on the views and Java programmers to work on the controllers if everything could so easily get jumbled together in the JSPs.
A few months ago, Frank and I started not so much a refactor but a redesign. We spent time researching the various MVC frameworks, and once again, decided to roll our own. In great part because of my experience with JSPs, I decided to use Velocity. I think this is the right time to do this redesign, in part because I now have enough experience to know how to fix it. I think had I done a major refactor beforehand, such as replacing the entire set of skins with an MVC framework such as WebWork, I would have just been wasting time.
By the way, the page your looking at was served up, quite effectively, by one of the most ugly, hacked JSPs in our system, flat.jsp, which originally came from Jive 2.1. And it works pretty well.
|
|