Every developer knows the pain of banal mistakes. A wrong attribute here, a misspelled property there, an accidentally duplicated line of code which you missed because of the coffee-fueled 16 hour hackathon you've been on. [...] Code review is simply the act of having someone else look at your code to find the mistakes you missed.

The tutorial talks about the types of code reviews (three of them with varying levels of involvement) as well as some best practices to follow in your reviews like:

• Know your common mistakes and actively fight them.
• Peer code review means being reviewed by someone of equal or greater skill.
• Collect metrics.
• Be mindful of the social aspect - finding bugs is good, not bad!

When you are held responsible to other people and when you are in an environment that has competition, that not only helps the company as a whole, but it allows for more individual growth. In the typical corporate atmosphere, accountability and competition can be lost because no one really knows anyone else. But the other side of this, in extra small companies, you can have too much accountability...where every move is constantly watched.

He notes that, without the pressure of peers - ones that you really know and that really know you and your work - the quality of the applications written degrades in most situations. Sure, there'll be the one or two developers that are extra motivated, but without the real interaction with other skilled developers, innovation can quickly fade.

There is one last area that I want to address, and this has everything to do with object-oriented principles and code reusability. For those who are familiar with OO programming, they realize that the use of classes does not make something object oriented by nature. In this final part of the series, we'll move one step closer to being object-oriented, by introducing the concepts of request and response objects.

He changes up the Twitter object to take in a HTTPRequest object (instead of creating one by itself) and to use exceptions and a "Twitter response object" to encapsulate any responses from the service making it much easier to work with and understand than just a true/false return.

Now that we've worked out the abstraction issues and the logic questions, we should take a moment to focus our attention on a few of the issues relating to the architecture and testability of the class we've worked out.

He mentions changes to a call to get_included_files, a bit of code requiring magic quotes, and changes to the code to make writing using tests simpler (like injecting objects rather than creating them and writing a unit test every time a bug is found so it doesn't happen again).

So far, we've done quite a bit of work on our Twitter class, making it better. There's still work to be done, though, especially improving the logic. The Twitter class we have now has a number of logical flaws in it that we need to address. Additionally, there are some logical flaws that we started with that I want to highlight, even though we've already fixed them. Let's get started with those.

He looks at a few things like setting the host name as a property, using the return of the HTTP request and handling exceptions (like when Twitter's down). The resulting code is included.