A few weeks ago I did my first code review on work that I had no involvement with other than some initial brainstorming and high-level architecture.  As I was looking at the code I only saw one or two things that concerned me but even those were not critical.  When I typed up the review I realized that first and foremost I need to clarify that the software was working and frankly, it’s hard to argue with working software.

In this case the component was designed with good object-oriented principles and there was really only one place where I thought a particular class had too many responsibilities.  The developer, who is pretty new to REJIS, was extremely open to the feedback and all in all it was a good experience.

This had me thinking, what if you were reviewing software which wasn’t designed using good object-oriented principles?  If the software was working, what angle would you take to suggest changing the design without offending the author?  This is a tough question because there are many organizations where the development teams have a mix of procedural minded and object-oriented coders.

My friend and colleague David Risko wrote about this in his post "The Elusiveness of Object-Oriented Thinking".  His post highlights some of the challenges of bringing developers into the OO space.  Fundamentally OO breaks many of the traditions of traditional procedural thinking.  It is a mind-shift that can be difficult to make and in a mixed environment where you have those in an OO mindset and those who are not, the differences begin to surface more often.

So what about that 1,000 line class with 3 methods and if statements nested 5 deep?  It works and it’s consistent.  How do you show that developer ways they could improve it’s readability or flow?