[LRUG] Code Auditor / Reviewer Needed

[Eleanor McHugh]

On 5 Oct 2009, at 16:20, Matthew Rudy Jacobs wrote:
> Who out there likes reading other peoples code, digesting it, and  
> then telling other people why it's right /wrong?

Like is probably too strong a term, but reading other people's code is  
always interesting.

> A friend of mine in Shanghai has been building his site (http://SourceTheGlobe.com 
> ) with a Chinese Rails team for a year,
> and is now looking for someone to carry out a Code Audit / Review.

This probably isn't useful advice for your friend, but for anyone else  
looking at a similar approach make sure you schedule regular code  
reviews throughout development rather than waiting until you've a  
year's worth of code in hand. That way your team will gain useful  
skills and insights much earlier and be capable of using them fluently  
throughout the rest of the lifecycle to deliver a higher quality  
product without any great increase in cost. The alternative is to  
retrofit these insights onto an existing and mature codebase at  
significantly increased cost.

And for those who prefer pair-oriented agility, code reviews fit in  
nicely with pairing (as does external QA) if you're looking to build  
systems which reflect your highest ambitions. Pairing by itself will  
not get you there because it ignores the value to be derived from  
studying a codebase in the large.

> It is probably a few days worth of work getting to grips with the  
> system, and then preparing a report on a few key areas.
>
> I'm trying to build a list of desirable qualities right now, so  
> please feel free to make some suggestions;
> 	• readability - the code should be easy to understand
> 	• organisation - the code should be well organised, and easy to  
> modify or add new functionality
> 	• standards - the system should produce HTML, CSS, and Javascript  
> which conforms to current web standards, as administered by the W3C
> 	• scalability - the code should be efficient, with effective use of  
> caching where necessary / possible
> 	• clean - the code should avoid using too many "hacks" and make use  
> of reusable plugins, and gems where appropriate

Readability should also cover consistency of style as that's a strong  
determinant of long-term maintainability. Likewise there should be  
good documentation covering deployment and administration of the  
resulting as well as its architecture and implementation.

Steve McConnell's "Project Management Survival Guide" and "Rapid  
Development" contain lots of useful methodology-agnostic advice on how  
to judge the quality of project deliverables gleaned from large real- 
world projects.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
http://www.linkedin.com/in/eleanormchugh