Log Output Rule

Run the log Application scenario prototype iteration process

In this scenario, the log output must be required. The reason is obviously, because it is an iterative process, the overall structure model is not clear, some logic is not very reliable, it is necessary to provide a side for the observation program to run dynamic.

Two-time development

Two times development is usually done iteratively using a prototype. Even if it is not based on prototype iteration changes, the log observation is more needed, at least some of the platform dependent calls we need to observe. Programmers are generally not fully trusted for logic that is not defined by themselves. Unless there is reliable evaluation data.

For dependencies that have unit tests

There is a unit test, that is, there is credible and reliable evaluation data. For this part of the dependency, with two development notes, let's just apply the log output of the layer logic, and it's best to block the output of these reliable dependencies. Because the unit tests are guaranteed, we do not want to be dependent on the internal output and inflate my human flap to observe the range.

Output rule

Log as the internal side of the program run, is written to the people to see, different forms of output logs to the programmer experience is not the same. So we need a specification log, the process clear, to observe some key information. The following summarizes three rules to define our development process.

Process log

When a process log is required, this looks at the dependency of the function block on the other blocks;

The simplest rule is that there is a more critical log record of the calling function name and the entry parameter before a call occurs.

Export log

In this case, the process log only focuses on the recording of other function calls. Then the export log is concerned about the function block target output;

The simplest rule is that, before the function returns, the return value of the function and the parameter are compared to the key log records.

An old question really answers, structured design has a single-entry single-out module design principles. This is why try to request single exit, easy to track records!

Portal Log

Here again to explain, since there are export logs naturally consider the entrance also print a record. Mo, Don't Panic! This is a particular article.

Do not provide an external function module, do not generate the entry log. Why, because there are process logs that are pre-declared, all of the context processes are reflected in the log.

The simplest rule is to export the key records that are part of the function block called by other engineering targets.

That module design principle, an entrance an exit. In the context of a function body, the entry is always the only one. I can only have a hey!

Results

With the process log and export log as a guarantee, we can easily observe the context in which the program is running.

For the above three rules have a premise note, a log record, the most basic need to have time stamp, function name these information, with the function name we can clearly see the complete process operation!

Follow this specification to perform iterative development, program design is good, it is obvious that can be reflected in the log output. Well-designed can be from the log to reflect the clear process, the level of distinct characteristics.

Engineering operations

The project here only speaks code engineering. Each project consists of a number of compilation units and contains some dependencies.

Project Target executable file

Application and Application extensions.

Static Library

The dependencies required to complete the target link.

Engineering Team

This is related to functional objectives and division of labor.

Project objectives are generally divided into different functions, and then grouped to manage different developers, that is, to organize different teams to accomplish different development goals.

Platform Applications

Log Output Rule