3 posts tagged “software engineering”

Ship it! A Practical Guide to Successful Software Projects

Jared Richardson

This is a fantastic book. Developers of all levels of experience can learn something from their hard-won pragmatic best-practices.

Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series)

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.

Test-Driven Development in Microsoft .NET (Microsoft Professional)

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:

1. Try to think of all the tests you'll be needing. This is also great for planning the time you'll spend on your project.
2. Pick a test. You could start simple, then go complex. With experience, you could start with a more complex, but more "fundamental" test for your problem space.
3. Write your test.
4. Write the minimum implementation that lets your test compile.
5. Run your test. If it fails (it usually will, if you were truly minimal), write what's needed to get it to pass.
6. Pick another test. Repeat steps 3-5 until all existing tests pass.
7. Refactor. Look for code smells in both the test and the implemention to fix. The book mentions a heirarchy of priorities to follow when making refactoring decisions. I'll leave it to you to pick the book up and find out what they are.
8. Repeat steps 3-7 until all tests have been written and are passing.

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!