Before I jump into Chapters 5 and 6 of Agile Software Development - Principles, Patterns, and Practices by Robert C. Martin, I ran across Uncle Bob's website today in a round about way via a pretty cool article he has written on the Principles Of Object Oriented Design (read it here). Some of the items in his article were the nuggets I had mentioned I was planning to talk about in later chapters of the book.
You can read my really quick summary of Chapters 1 - 4 in the following post:
Chapter 5: Refactoring
Chapter 5 is on Refactoring, which when done as part of Test-Driven Development (TDD) is my personal favorite way to spend my development time. I have to pull a paragraph from the chapter on refactoring, because I think it sums up the importance of refactoring pretty well:
“Every software module has three functions. First, there is the function it performs while executing. This function is the reason for the module's existence. The second function of a module is to afford change. Almost all modules will change in the course of their lives, and it is the responsibility of the developers to make sure that such changes are as simple as possible to make. A module that is hard to change is broken and needs fixing, even though it works. The third function of a module is to communicate to its readers. Developers unfamiliar with the module should be able to read and understand it without undue mental gymnastics. A module that does not communicate is broken and needs to be fixed. [Martin, p.31]”
Refactoring is the process by which you accomplish all the above. And, from Fowler, the definition of Refactoring:
“...the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its iternal structure.”
The chapter takes you through the process of refactoring a function that generates prime numbers, which I personally didn't care for too much. Maybe when I read it over again at some point I will think differently.
Chapter 6: A Programming Episode
Chapter 6 is a really cool chapter that gives you a play-by-play episode of Pair Programming done by two developers using Test-Driven Development to create a program that calculates the score of a game of bowling. This was a pretty laid back, fun-to-read chapter that really showed the power and realism of TDD and probably Pair Programming. I say, probably Pair Programming, because I have never done it.
This is just one of those chapters that you have to read for yourself. TDD is a process, not a silver bullet, and if you do it right you will eventually get to clean code. It was fun to read how the developers would backstep at times, poke fun at each other, take turns with the keyboard, and get to a really nice solution that calculated the score of a game of bowling. The final solution was much simpler than they had expected when they were initially talking about the problem. Very cool.
That ends the first section of the book, Agile Development, which is really just an introduction to concepts and practices. It isn't the best introduction to these concepts. You can certainly buy complete books just on the basics, and I recommend you look elsewhere if you are new to these topics and want a more thorough introduction. I don't think this is an introductory book, however, so the review was perfect for my needs. I am more interested in the next section, Agile Design!
Read Chapter 7, What is Agile Design?