It is highly likely that a development team will log informational messages, errors, and warnings. The team determines the format and log content. Mistakes can happen. The signs of trouble ahead are: application life cycle events and user touches unleash print-out hell. The console shows server responses mixed with Xcode warnings. Various methods spit custom messages, some of which are vague old debugging remnants.
As we will see, the above signs foreshadow problems that include: the finding failures in the development or production environment, the confusing new team members.
Problems Logs Cause
The first peril is a decreased chance of detecting failures. The person who monitors the obscure logs, whether it is our colleague or we do it by ourselves, will sweat to find relevant information in the logs. Filtering and searching logs will be cumbersome. At the worst, sieving through the logs will crawl to where hardly anyone will read them, forcing the team to prioritize cleanup above development tasks.
The second threat is confusing new teammates. They will have a hard time figuring out logged events and may abstain from adding their logs. The latter can happen because of over-complicated logging or unrelated messages flooding the screen with no efficient mechanism to pin particular events. The worst-case scenario is a person keeping mouth shut because of being new to the team or being intimidated by the complexity of the logs.
The above problems bring us to seeking a solution.
Depending on the business context, the team might have to consider several factors. Among many the first is the client’s security policy, the second is the team’s internal logging policy, the third is the mechanism implementation.
If a client security policy disallows external tools or storing logs on a device, like in applications made for traditional banks or Fintech, one can send the logs to the back-end. If security policy allows only in memory storage, then the logs can deplete it. To mitigate the risk, the development team can consider using a Ring buffer data structure.
The Team’s Log Policy
Moving on to the team’s internal logging policy, three rules can be of paramount importance.
First, nobody should object to adding print statements temporarily to his copy of the code. What a teammate gets up to his repository is his business. But once a developer finally commits changes to the canonical version of the program, any “temporary” print statements must come out.
Second, the team should categorize the logs and logging to the error category must be important enough that the developers are willing to have someone call them about it.
Third, the team ought to be mindful of writing informative error messages and drop obsolete logs. One information log message for every significant application event is enough. Maintaining logs is significant. A cluttered log shows that an application will be hard to debug once it reaches later development stages or production.
So much then for the team’s internal policy. Let us now turn to the implementation.
Several tools on the market facilitate logging. Apple advises its Unified Logging System as an efficient way to capture log messages to memory and disk and to manage logging behavior and persistence.
Apple instructs to use its system directly. However, moving logging to a different module and hiding it behind an interface is a safer option, if for whatever reason the team decides to change the tool.
To sum up, a noise-free error log can become a first sign that the system is reasonably healthy, or can serve as an early warning if it’s not.