Software code is a work of art. But it is not something which is seen, felt or eaten. It has to work, and work well, and be directed to a set of scenarios which probably will evolve with time and needs. Hence, writing bug free code is impossible.
But software development has reached a mature stage by now, and anyone who has worked well does know a few things about what qualifies as good code. It should be clean and easy to maintain, have minimum redundancy, should be high on performance and take care of security. Most importantly, it should take care of a few more scenarios than in the Business Requirements Document; something we call non-functional requirements.
With these in mind, a peer or a senior can review the code. A peer will be able to show basic mistakes which the developer has done in coding. Lets think of the peer as the developer's batch-mate - both were taught by the same teacher and taught very well. But due to pressures and oversight, which are natural for anyone, a few important points were missed. Here, the peer who is reviewing others work has the frame of mind to properly notice the mistakes. Lets accept the fact that it is hard to be effectively self critical. Here peer review comes handy, so that when the code goes to the senior, there are no reasons for the developer to be embarrassed about himself.
The reasons of code review, as enlisted before, are more effectively handled in the senior review. Assuming the senior to be worth his salt, a number of good review comments will come the developers way. When i had started off, i unfortunately never did a peer review. Instead, 2 of my seniors and the client himself would review my code and i had a lot of review comments to handle. I would be angry looking at the number of comments, but eventually i realised that a developers job is of continuous learning and this process not only ensures code is of the accepted standard, but also the developer gets some insights acquired by the seniors in their years of experience.
Re-iteration experience, does give one a few funny observations. In the recurring code reviews, some comments are given on code which has already been reviewed earlier, and the developer thinks that why were these not pointed out earlier. In this, the right way to think is to consider everyone human, and keep in mind that we all are part of a team and are working towards ensuring that the product delivered is of a very high quality. The idea of being part of one team needs to be nurtured constantly, and this only improves the pleasure the team gets on delivering a successful software release.
But software development has reached a mature stage by now, and anyone who has worked well does know a few things about what qualifies as good code. It should be clean and easy to maintain, have minimum redundancy, should be high on performance and take care of security. Most importantly, it should take care of a few more scenarios than in the Business Requirements Document; something we call non-functional requirements.
With these in mind, a peer or a senior can review the code. A peer will be able to show basic mistakes which the developer has done in coding. Lets think of the peer as the developer's batch-mate - both were taught by the same teacher and taught very well. But due to pressures and oversight, which are natural for anyone, a few important points were missed. Here, the peer who is reviewing others work has the frame of mind to properly notice the mistakes. Lets accept the fact that it is hard to be effectively self critical. Here peer review comes handy, so that when the code goes to the senior, there are no reasons for the developer to be embarrassed about himself.
The reasons of code review, as enlisted before, are more effectively handled in the senior review. Assuming the senior to be worth his salt, a number of good review comments will come the developers way. When i had started off, i unfortunately never did a peer review. Instead, 2 of my seniors and the client himself would review my code and i had a lot of review comments to handle. I would be angry looking at the number of comments, but eventually i realised that a developers job is of continuous learning and this process not only ensures code is of the accepted standard, but also the developer gets some insights acquired by the seniors in their years of experience.
Re-iteration experience, does give one a few funny observations. In the recurring code reviews, some comments are given on code which has already been reviewed earlier, and the developer thinks that why were these not pointed out earlier. In this, the right way to think is to consider everyone human, and keep in mind that we all are part of a team and are working towards ensuring that the product delivered is of a very high quality. The idea of being part of one team needs to be nurtured constantly, and this only improves the pleasure the team gets on delivering a successful software release.
No comments:
Post a Comment