Code Review : whats all the fuss about?

"Code review" for those of you who are not familiar with the terminology it is the practice of reviewing code written by another developer/programmer in a development team. Here are my brief thoughts on how and what a code review process is and should be about.

Is there an emotional side to it?

Much too often code reviews are sought with distress. This can easily be attributed to a lack of understanding as to the purpose of a code review. A code review policy in a team should be aimed at creating and maintaining a consistent, structured and standardized code base. Nothing more nothing less.

So we got the essence of it now what?

To achieve all of the above we need to come up with a list of process's and tools that can help achieve our goals. To get you started here are a few

1. Determine when you will conduct your code review, is it after each development iteration, is it after testing?

2. To achieve standardization, create a guide and update it regularly with necessary checks you want to cover with your code review. Here are a few to start with.

a. Check for hard coded data.
b. Check for performance bottlenecks IO operations, db connections etc.
c. Check for adherence to naming convention.

3. Train your team in your code review process

4. Regularly discuss your code review policy with all involved. Remember code review is not a solitary exercise and your code review policy will have a wider acceptance when everyone's opinions/ideas are heard.

5. The code review exercise is not one just for your Team Leads. Anyone and everyone in the team should be have the ability to conduct a code review. This will help inculcate your coding standards across the team.

Tools

Here are some tools that can help with your code review objectives

1. A good code repository that can help you identify the code required to be reviewed

2. A good diff tool that can highlight the differences between the latest and previous versions of your code.

3. A good refactoring tool that will automate most of your code review process

Conclusion

Id like to end my thoughts on the code review process with the following

For the reviewer : Focus on the code not the developer! This is an opportunity to learn for you too, you can learn how to do it or how not to do it so keep an open mind.

For the developer : This is not a critic of your your coding skills but an exercise to improve the code in the code base.


CodeProject

Centralized asynchronous logging

If you’ve been working long enough in application development like me I’m sure your aware of the benefits  of incorporating a  good logging mechanism within your application.

Recently I was designing an SOA based enterprise platform. There were a number of services and applications that required some serious logging and honestly I wouldn't have given it much thought and just included some third party component such as log4net or Microsoft Enterprise Application Logging Block that would log data to a text file within each application or service.

But  I had a second thought when re-factoring my architecture and  being a firm believer of consolidating and centralizing application development and anything related that perfects the reuse of code, process or data. I thought there must be a better way to implement logging?

So I made a list of woes I had experienced from previous logging implementations. The most significant thing that hit me was the difficulty involved in accessing logging information when things went wrong. You had to locate the application, the server then scan through a huge massive log file and you had to be the one who has access to this file. That meant a significant down time even if the solution was a tiny change in the config.


So the most possible solution was centralized logging, but wait what about performance? logging to a flat file surely meant a hit on performance. So lets have centralized asynchronous logging  is  what I came up with

Centralized Asynchronous Logging.

I used Enterprise Application Logging Distributed Services to implement Centralized Asynchronous Logging.
Briefly you have various applications on different servers log to a Message queue and run a windows service that will read from the queue and populate a database. You then create a log viewer application which you can use as to  analysis the logs . With this set up  you can implement a number of useful process to deal with logging.

Benefits

* No more dealing with large log files.
* Template for the type of logs you collect will make your logging a lot more uniform in content and easy to read 
* Clean and maintain your logs efficiently and effectively.
* Search and query your logs.
* Having a central logging repository enables you to report and analysis the health of your applications.
* Developers need not be the only ones required to analyze a problem, other levels can access this information via the web viewer application.

For more information on how to implement the above have a look at the following url

See the following link http://msdn.microsoft.com/en-us/library/ff647847.aspx

CodeProject

Writing an extensible polling service

In an enterprise system environment you often come across the need to execute asynchronous processes/tasks. The most common approach is to create a windows service that will poll for tasks and execute them. However this leads to the creation of a number of services over time.

Managing multiple services and ensuring that they are all up and running can be huge task by itself. Not to forget the development time involved in rewriting the same polling service code every time. This led me to build a generic polling service that could run any task in an orderly manner and be flexible enough to allow for the addition of new tasks with relative ease in the future.

If your interested click here is the article with the source code