I'm biting the bullet and am going to try and understand this magic web 2.0 technology. I'm still on Chapter 1. Wish me luck!
I thought this news item was interesting, since I just moved my family from a big house about 20 miles from work to a large apartment within walking distance, in part to save on gas and utilities. Apparently, taxing based on the true environmental cost (e.g., greenhouse gas emissions leading to global warming) would raise the tax per gallon of gasoline by 50¢.
This book was my introduction to what Extreme Programming really is. Before, I had some misconceptions that it was a couple of guys writing a bit of code at one computer, and high-fiving each other every once in a while, yelling "Extreme!"
Apparently, pair-programming is only one part of it. Test-driven development is another part, which I like. The book presents it as largely a set of practicing for minimizing risk and maximizing results on small to medium software projects. By and large, I recommend this to book to anyone seeking to learn what XP is all about.
I just finished this book. It was the first book I ever read devoted to the subject of test-driven development (TDD). I highly recommend the first 3 chapters where the topic is introduced by way of using TDD to implement an object stack from scratch, and then to refactor a prime numbers calculator. The rest of the book is devoted to a fictional web services application. Once you've read a couple of chapters of that, the rest of the chapters start to blend together. The chapter on customer tests was also a worthwhile read.
I found it worthwhile. I thought I'd been doing test driven development, but really I was writing my code, then immediately validating selected aspects of it with pseudo-unit tests. By pseudo-, I mean that I was actually putting multiple tests together into each routine. Also, I wasn't using (because I wasn't aware of) the classic TDD workflow described in the book:
A surprising thing for me was the constant refactoring, especially of test code. It shouldn't have been, but it was. Also, it's completely normal to think of more tests that are needed as you cycle through this workflow. I can't wait to put this into action!
Duplicate code is a problem. It breaks a basic signature of code quality, which is that code gets re-used whenever possible. Whenever a developer takes the shortcut of cutting and pasting a code fragment in order to implement something faster, he introduces instability into his software. Here’s the problem. If a bug is found that is localized to a section of code, and then is fixed, all is well. But if that fragment of code has been copied around the project one or more times, the bug really hasn’t been eliminated. It must still be eliminated from other locations.
I am in the process of taking a large code base and using an automated tool to scan it for duplicate code, eliminating them however it makes sense. Future articles will concentrate on the exact ways in which this can be done.
The Simplest Case
When does it make sense to refactor duplicate code into a common location? Let’s take the simplest case. A developer copies N lines of code from one routine to another. Assume those N lines of code can be simply refactored into a separate routine that gets called by location. One measure of the reduction in code is simply to count lines of code. I count the routine declaration as one line, but don’t count any closing bracket living on its own line, or comment lines. The total reduction R in number of lines of code is twice N, minus 2 for the replacing routine call. R is reduced by N+1 for placing the N lines of code into their own routine, because of the additional routine declaration. In more compact terms:
R = 2N – 2 – (N+1)
R = N – 3
This means that you break even in code reduction when the refactored fragment is 3 lines long. Does this mean it only makes sense to look for duplicate fragments at least 3 lines long? It depends. I would argue that even a sufficiently complex of difficult single line of code sometimes makes sense to put in its own routine. Also, there are many instances of 2 lines of code that are sufficiently non-trivial to warrant refactoring, even though from a typing standpoint, you are losing a little bit. Hopefully readers can easily see that if the duplicate section is 4 lines or longer, then it makes complete sense to refactor.
I wanted to bring this to the attention of anyone reading this blog. There is a wonderful series of short documentary films called "Hometown Baghdad" that has me captivated lately. The one I put here shows three young Iraqi men's very diverse feelings about American troops in their country.
If you like it, many more available for viewing at chattheplanet's page on YouTube.