Michael Stephenson

Name:

More logging than a lumberjack

Description:

On one project our team inherited a BizTalk solution which had a lot of logging in it.  I feel that with both BizTalk and also standard .net projects when you see code with excessive logging in it is because the developer needed all of this information to be able to write the code and know what is happening.  This logging usually masks the fact that the code was very buggy during development and also probably has no unit tests or has very low code coverage. 

Symptoms:

1. A solution has too much logging
2. Often people start to use the solution in system testing and production and there are a lot of queries about "what has happened" and no one really knows
3. The unit testing of the solution will probably be poor and coverage will be low
4. The event log will be very cluttered and often it will be difficult to find relevant information when troubleshooting

 

Pain:

1. Lack of confidence - People are not confident in the solution because it is often not well tested
2. Bugs- Because it is usually has low test coverage the solution will usually

 

Cure:

1. Use BizUnit to test your BizTalk solutions.  This will result in a higher level of confidence and understanding of your code and as result you will not need to log as much
2. Unit Test and .net code which will be called by your BizTalk solution.  Sometimes logging is used in say an orchestration to check the component returned what is expected.  If this had been correctly unit tested you would not need any of this.
3. Use Tracing or a logging block.  Logging to the event log is okay for some things such as events etc but you often see unimportant information always being written to the event log.  If you use tracing for things which are not as important but you still feel you need to know then you can use trace listeners to turn it off or write things to different sources.  The other good thing is that this can be configured at runtime.  This also applies to logging blocks such as Enterprise Library or Log4net.  DebugView can also be a handy tool for viewing trace messages.
4. Code reviews can be very important here because if a colleague reviews your solution they may be able to offer suggestions or identify things which they feel aren't right (such as excessive logging)

 

Comments: