Code Metrics: How good is your code ?

Code review and code metrics are two facts of life that a good developer cannot (or should not) escape. Code metrics are ways of quantifying traits about your source code that can give developers feedback about the quality of the source code. Code metrics are usually run by an automated process like a continuous integration process (see Continuous Integration: Going Beyond Builds). Setting up a process to generate code metrics and collecting them at intervals is quite easy. However code metrics is a slippery slope because it will also give you tools to squarely point a finger at  your developers and tell them how bad their code is, when in reality nothing may be wrong with their code. It is very important to know how to interpret the metrics in the context of your application and developers. So let's have a look at few of those metrics. 

Last week I wrote an article about Database Versioning Database Versioning: The ignored aspect of version control. In the article I stressed the importance of versioning the changes made to databases and methods that can be used to do so. I suggested existing tools can be used to version databases and if tools were lacking then with the help of simple automation and policies database versioning can be achieved. The article received very good response including lots of comments and a lively discussion on reddit which can be found here. I also received a lot of suggestions for tools that can be used for versioning databases including Red Gate SQL Source Control, Liquibase, Delphix, FluentMigrator, Golden Gate, South, FlyWay, DBGeni and sqitch. So I thought I would try some of these out in real world scenario. As I go along I will also get to learn about these product. Now some of these are commercial products and some can do much more than version and migrate a database. So realistically I cannot try out all these products but I will try to demo software that are free and have trial versions available. So let's start with Liquibase.

Version Control: Branching Models

A good developer always versions his or her code. And all good version control systems provide means to create branches. On some version control systems like Subversion and git the cost of creating a branch is minimal. On others like Perforce and Visual Source Safe the cost of creating a branch on the server can be quite expensive. However if your code is not corralled by a good branching strategy you will soon have a unmanageable mess on your hand. I believe a good branching model can be developed individually for each project based on its needs and workflow. However some of the commonly used branching models can be used as guides to establish basic branch and merge policies. These can then be fine tuned per the need of individual projects.