What is the best code review practice for a handful number of developers on an ajax web application project?

Using a tool like ReviewBoard (http://reviewboard.org), I'd encourage you implementing a pre-commit review process with an optional override ability.  This encourages a standard of reviewing code prior to submitting to source control, but provides a capability for overrides as an exception. You can also use a tool like IRC or HipChat (http://hipchat.com), and integrate group chat messages - so developers are alerted that someone needs a review.  It's a great quality control step, and it ensures there's always two different sets of eyes on every line of code checked in.  If you build it into your culture, my experience is that it doesn't slow developer productivity as greatly as not having such a process in place - and also encourages more sharing of best patterns and practices.

I manage a small development team for an agency. We have between 4 and 6 developers at a given time (depending on contractors), and we do post-commit reviews on an as-needed basis. This keeps development moving, and leaves the code review process up to the individual team member. I.e., when an individual team member needs/wants a review, they can kick one off. This works well for us for a the following reasons: We have experienced programmers, and We primary work with the web framework Django, which gives us a lot of structure. We do QA reviews on the code's behavior. I.e., all new code is pushed through to a staging/test environment where our project managers pound on it. This ferrets out a lot of bugs. We use git to develop new code on an isloated branch or a non-production line of development. By following Django's conventions, we're able to push through a lot of code that is fairly standardized. For example, developing a form is straight forward in Django, so there is rarely a need to do a pre-commit review. (Django is just one example: something like Ruby on Rails or PHP's symfony will yield the same result) However, when we need to develop something tricky or complex, doing a review yield great results. However, even in these cases, we rarely see the need to do a pre-commit review. As long as it's not going into the main line of development before QA, there's a chance to test/review the code proactively. Your milage will vary, of course. A lot of complex and/or unique code that doesn't utilize a framework would benefit form more proactive reviews.

Excellent question. My experience is that the ol' traditional code-review processes are extremely inefficient compared to what you get from a proper application of Pair Programming. A proper application of pair programming means that each pair contains at least one member who's keen on details and elegance. The code-review is on the fly that way. The pair must know they are supposed to come up with results which are of high-quality and also meet the constraints (timetables, etc.). i've been doing pair-programming way before the method had a name and the results were no less than astonishing, performance-wise and quality-wise. It has other benefits two, like the distribution of solution-domain knowledge, the speed by which newcomers are brought up to speed, and more. Another practice which further enhances the development, is the no code ownership principle, which goes hand in hand with proper practice of pair-programming: that means, any other programmer/pair of programmers may change, refactor and enhance another's code. That's also a code-review facet and an application of a third principle: On-going refactoring. Code should never aim to be perfect at the first shot - that's one of the lessons from which Agile emerged from....But that's another issue...

You can use http://sourcetalk.net–it allows you to discuss the code in real time without actually blocking your development process.