Session 14

Project Development, Day 5

810:188
Agile Software Development

Daily Stand-Up Meeting

We go around the room and report:

• What did you do yesterday?
• What do you plan to do today?
• What is in your way?

Everyone reported on the progress they made last time. No obstacles, though several teams made simplifying decisions while waiting for transaction dates to work. All but one story (producing balance sheets) is finished.

One lesson I learned yesterday: I missed an opportunity to point out a valuable use of TDD with the pair working on Account.examineAt(someDate). They were struggling with the algorithm, which requires finding the last entry to display and then displaying 10 items up to that one. When they were strucggling, I should have suggested: Write a simpler test. That would have focused us on the first problem, the search loop, and help us get unstuck from the bigger problem. It also would have produced a testable method, which Account.examineAt(someDate) could call to do its job -- but also:

• It would have an intention-revealing name, making the code easier to read.
• Other parts of the class could have used the method, too, making them easier to implement and reduce duplication to be factored out.

Development

We changed our routine. With only two high-value but high-risk stories to implement, and the iteration ending today, we decided not to push ahead. Instead, we decided to devote today's effort to improving our code through review and refactoring.

First, we ran reek against the repo to see what smells it detected. We looked for a few specific improvements we could make. reek's list was large and helpful. I pointed out a few things:

• reek thinks that our test class files smell -- a lot. Automated tests are code, too, and we face all the same issues writing and maintaining this code as we do with system code. Given the brevity of our semester and the many other things we want to learn, we won't devote much time to engineering better test classes. Do be aware, though, that this is an important issue in any shops with high test coverage in automated test code. Check out the xUnit Patterns web site for lots of great information!


• reek says that our program uses way too many uncommunicative names. Danny hypothesized that our problem is that too much of the code uses camel-case for method and instance variable names, instead of lowercase with _-separated words -- Ruby style. A later test confirmed this hypothesis, and a quick set of renamings eliminated these smells altogether.

  In the meantime, though, I eliminated the uncommunicative name smells and saved the smells to a file using this command

           reek *.rb | grep -v UncommunicativeName > smells.txt
  

  We then focused our attention on the non-test files.



• Duplication and low cohesion are good indicators of places that can be improved, though sometime the idea to fix is an inference away from the symptom. Example: repeating (i - 9) indicates not only the need for a method but also the need to factor out the code's dependence on the magic number 10.


• When there are multiple occurrences of duplication and low cohesion in the same short method, then we should take seriously the idea that this code can be improved in a major way.

(We discussed the fact that reek is aggressive in labeling a method "long". I looked up the documentation for this feature and learned that its default limit is 5 lines of code -- and that users of reek can configure the tool to set whatever limit they prefer. Very nice!)

At this point we decided to spend the rest of this iteration improving our code. Developers paired off to work on a class or two they have not worked on yet, with team members they had not paired with yet. They grabbed a clean copy of the project repository:

    svn checkout https://student.cs.uni.edu/svn/810188-May10

and went to work. The result: We have much better code now, and it all still works. Our tests protected us!

Wrap Up

• Homework. None.


• Reading. Tomorrow we will do a retrospective of our first iteration. Read these articles to learn about the whys and hows of agile retrospectives:
  • Iteration Retrospective, the earliest documentation of retrospectives in XP
  • Some Patterns for Iteration Retrospectives, which discusses the goals of retrospectives and how to achieve them
  • How To Run An Iteration Retrospective, a one-page flier describing how one company runs its retrospectives

  Please read all three. It won't take long!



• Programming. Keep learning Ruby, especially any language features you encountered today but didn't understand well. You may also work on the team project but only with a partner. We will continue to do pair programming for all team code.