That said, I do have something important to add. The series is missing the first, most basic rule: Don't refactor unless you have good automated test coverage (typically with unit tests). And if there are no test, write them before you start refactoring.

He notes that with successful unit tests in place, you can freely change the underlying structure of the application with (almost) no worries that your application will fall apart the next time it's run. He does point out the need for a bit of refactoring before the tests could really be successfully run (since there's a need for an external twitter connection).

One of the first things I look for when I check out code is how is the code organized? Is it laid out well? Is it coded to a particular standard? In our code sample, the first thing we should address is how does the code look. There are a number of suggestions I would make immediately.

His list includes four suggestions for/comments about different areas of his example code:

• There are no DocBlocks or clear coding standards
• Examining The Properties (comments of the class properties)
• Conditionals (changing inline to braced)
• Improving The Constructor (to make it more flexible)