Code Review is an age old practice in Programming. Nevertheless, code review becomes a bit challenging for distributed teams. If the development team policy does not allow junior developers to commit (check-in) unreviewed code to their development branch in version control, then it becomes a bit difficult for distributed teams to implement an efficient code review process without creating separate branches in the version control repository for every change. A new branch for every task can potentially create hundreds of branches which can soon become confusing and unmanagable for the team. In my experience, only the most expensive version control tools are good in dealing with merging/promoting code across multiple branches.
I think a cost effective approach to solve this issue would be to utilize the "create patch" functionality available in most version control tools (like Subversion). Patches are nothing new in the world of programming. Every open source project utilizes this feature. Developers can create a Patch and commit (check-in) the patch file to a well known location (say a patch folder) and notify the reviewer. The reviewer (located in a different location/time zone) an apply the patch to his local work area, review the changes at his own convenience and get back to the programmer with his feedback (by email, phone, discussion board, etc).
For detailed instructions on how to create and apply a patch in Subversion using Tortoise SVN Client visit http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html.
I think we can also utilize patch functionality to store code which is useful but not yet ready for release. Often we end up building functionality/proof of concepts which cannot be checked in to the main development branch because it is still not ready for prime time. In these cases we can preserve the changes as a single patch file for future use.
No comments:
Post a Comment