11.4. Defining a Policy
As part of any software project, you should define and disseminate a tracing policy. It is important that every member of your team has a common understanding of this policy and how to apply it. Your tracing policy should include such elements as which tracing system to use (you don't want half the team using .NET tracing and half using log4net, for instance), where tracing should be done in the code, and how each message should be composed and formatted.
Keep your policy short. Most developers won't read more than a page or two of text, so keep it concise and to the point. Make sure that everyone reads the policy, and follow up with periodic reviews and inspections to make sure that the policy is being implemented properly.
Because many of the details around tracing may be defined at configuration rather than compile time, the critical things for developers to be aware of are how to categorize their traces' messages by trace level and what information needs to be included. How these messages are distributed, saved, and formatted can be defined as part of your applications configuration, and may not be within the purview of the developers at all, but rather handled by an operations or IT department.
A sample tracing policy might look something like this:
More information is better than less as long as trace messages are characterized properly. It is harder to add tracing statements later than it is to turn off tracing if you don't need it. Make sure that ...
Get Code Leader: Using People, Tools, and Processes to Build Successful Software now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.