Thursday 5 September 2013

Code Quality: Diagnosability of your application

Code coverage, unit tests, static analysis are some of the code quality measures that are typically referred to code quality. I want to touch base on few more important aspects of code quality. Let's start with diagnosability. 

Diagosability means ability to diagnose the issue quickly and accurately. Defects are always going to be there it’s a question of once tester finds a defect, how quickly and accurately can you diagnose the defect and know where to fix?

In other words how your application facilitates troubleshooting and ability to diagnose defects? Developers are always fan of debuggers. If you can attach a debugger, you can find any crazy defect's root cause. However you are not always going to have a liberty of debugging. It takes time and requires exact setup as of the production database along with various different systems involved in order to replicate the issue. You may have conditional logic which gets hit during specific state of the application. Debugging requires you to replicate exact same state in your dev environment so as to step through the code and see which code lines are executed along with values of variables used etc. 

Sometimes (or most of the time) there is not enough time to do all this setup for debugging. Management may demand urgent fix and it’s a fair expectation.

In such scenarios, diagnosability comes to rescue if developers build the application keeping diagnosability aspect in mind. Simplest solution is to add enough logging or trace statements that redirect to either log file, event log or console etc depends on the nature of the application. Many architects prefer event logs for critical errors since it can be monitored through SCOM like tools. 

In .Net we have system.diagnostics namespace that provides all necessary supporting classes to instrument logic flow from application into event logs or trace files. There are many third party paid and open source loggers out there.  

.Net supports info, warn and error as trace settings in diagnostics namespace. You can use this efficiently wherever possible and be able to control the amount of logging. Too much logging can also slow down the performance. 

Also its important to note not to log sensitive data into log files e.g. user names, confidential info, and encrypted info. You can log mostly identifier of the entities and any decision variables so as to determine the state of the application.

However the next question that comes to my mind is how about third party code or shared modules from other teams across the enterprise. Logging standards may not be consistent across the board. It may be a legacy code that you can't change to add diagostability support. For this .Net provides a way to IL inject the code and extend diagnosability of any application. There is one tool that I am evaluating currently called dynaTrace. Ill publish my findings later on it but I would prefer such tools for new projects. Complexity of enterprise applications has gone up exponentially and we are already in the era of multi-platform, multi-device, multi-language, multi-geography, multi-tenant, multi-xyz applications. Diagosability becomes very important and it’s directly proportionate to the maintenance budget.