Chapter 9: Story One Is Done

We ve got a story working, Customer Acceptance Test and all! It s time to reflect a bit and refactor before we call it done.

Lesson: Retrospectives

Whenever we reach a pause in our work, we like to reflect on what has happened and to try to learn from it. We look forward and think about what we should work on and how we should adjust our practices for better results. In the agile software community, these sessions are usually called Retrospectives. In other realms they re called After Action Reviews, Reviews, and sometimes Postmortems. We don t like that last term because we aren t dead yet. Sit back and observe our little retrospective and planning session.

 

Planning Our Next Session

As we generally do but haven t reported , Chet and I discussed what we should do in this session before starting. We ll report it this time because there was a lot more discussion than just Let s get the code manager running and OK. We quickly agreed that we have all the Customer Acceptance Tests for our first story running. So it s time to ship it, right?

Wrong. It s time to be sure the code is clean. We talked for maybe 10 minutes about what we might want to do. Here s what we touched on:

Pushing the Command Metaphor

We needed the InputCommand, primarily because we turned out to be too stupid to make things work without it. The code called out for an object, and we wrote it. InputCommand turned out very nice ”so nice that it s clear that we should have an OutputCommand and that ultimately all the operation of the CustomerTest would be embodied in Commands.

We also notice that the InputCommand, though it has some smarts, is just a utility object. We feed it some text, it processes the text, and we rip the text back out and stuff it into the model for testing. It might make sense to tell the InputCommand something like input.execute(model) and have it do its own stuffing . It might also make sense to tell the model to execute the command. But the model doesn t have that kind of functionality now. Still, the model does suck the text out of the TextBox and put it back, so maybe the InputCommand is trying to grow up into some more advanced kind of object.

However, we have no driving need to do that. We re not maintaining the CustomerTest class right now, and we have no story that would drive us to do these improvements; our only reason would be to add functionality later. Our discipline is not to make this kind of change unless the code is really asking for it. And our view is that it is not asking...yet.

Chet also pointed out that the Command hierarchy, if we built it, would be in some way parallel to the TextModel, and/or parallel to the CustomerTest. He felt that there isn t enough functionality there for that to come out. Summing it all up, we decided not to do anything about pushing the Command metaphor further at this time.

Duplicate Reading Logic

Because InputCommand reads the input file up to "*end" to get input, and because CustomerTest reads input up to "*end" to get output, the system has some very similar-looking code. In InputCommand we have

 private void ReadLines(StringReader reader) { 
 lines = new ArrayList(); 
 String line = reader.ReadLine(); 
 while (line != null && line != "*end") { 
 lines.Add(line.TrimEnd()); 
 line = reader.ReadLine(); 
 } 
 } 

And in CustomerTest we have this:

 private String ReadToEnd(StringReader reader) { 
 String result = ""; 
 String line = reader.ReadLine(); 
 while (line != null && line != "*end") { 
 result += line; 
 result += System.Environment.NewLine; 
 line = reader.ReadLine(); 
 } 
 return result; 
 } 

These both have the same kind of loop, and they re doing the same kind of thing, although one of them creates an ArrayList and one appends everything into a String. We see this as duplication, even though it s certainly not as obvious as if all the lines were exactly equal. We don t like duplication, so we don t like this. Possibly we need another utility class that wraps StringReader. Or maybe InputCommand is actually what we want here, just with the wrong name because we don t see its real function yet. Either way, we re a bit torn by this duplication because we re afraid that if we don t fix it, we ll forget because we re not likely to remember these two classes as clearly later as we do now. But fixing the problem seems too large, and we don t have a clear sense of direction. Again, we defer the change.

Code Manager Needs Autorun

At this point, we turned to coding. Chet reminded me to start the code manager running so that it would snapshot all our changes. We need a tool for this, so we re reflecting on it for a moment. We re not going to write the tool, but we are reinforcing the idea in our minds a bit.

Watts Stuff

We reflect briefly on our chat with Watts Humphrey and our promise to scan the code trying for clean compiles, in hopes of finding other errors. We re still not ready to do this, and frankly we re not sure it s a good idea in this environment, but we keep thinking about it. As you ll see, we paid a little attention to it this time.