One of 17 UNIX design principles (Unix programming art note)

I recently studied Unix programming art. The first chapter is very good. It tells us a lot about the history and philosophical basis of Unix. The most important part is the 17 design principles mentioned. I know many principles, but I have never summarized them in such detail.

Most of the content below comes from the book "Unix programming art", which is a small part of my understanding. This is a habit of reading. I think it is important for me. I will give it out and understand it based on Deep Thinking During the typing process. Therefore, note is an auxiliary means for me to think and remember.

1. Module principle: use simple interfaces to splice simple components

"The essence of computer programming is to control complexity.".

The only way to compile complex software without losing ground is to reduce its overall complexity-to combine several simple modules into a complex software with clear interfaces. As a result, most problems will only be confined to a certain part, so we still hope to improve the part without affecting the whole body.

Note: I have seen the control complexity in multiple places. After the overall structure is set up, each module can also evolve independently without affecting each other.

2. Clear principle: Clear is better than clever

ProgramIt's for people, not machines..

This principle not only refers to readability, but also to SelectionAlgorithmFuture scalability should be taken into account in real time. Do not increase the complexity and obscure of Technology to Improve the Performance of a program.CodeIt is easier to breed bugs because it will make reading and maintenance more difficult in the future.

Elegant and clear code is not only not easy to crash-it is more conducive to immediate understanding of later revisions.

3. Combination Principle: Consider splicing and combination during design

If the program cannot communicate effectively, the software will inevitably fall into the mud of complexity.

Traditional UNIX systems strongly advocate simple, simplified, stream-oriented, and device-independent formats.

To make the program composite, the program must be independent of each other. The program at the end of the text stream should try not to consider the program at the other end of the text stream. Replace one end of the program with a completely different program, and it should be easy to do without disturbing the other end.

For protocol design, try to use a simple text data format.

4. separation principle: policy and mechanism separation, and interface and engine Separation

What is the mechanism: the functions provided, and the policy: How to Use the functions are confusing.

Policy changes are far greater than mechanism changes. Separating the two can make the mechanism relatively stable while supporting policy changes.

This criterion is also widely used outside the GUI environment. All in all, this rule tells us to strip the interface from the engine.

"Interfaces and engines "? There are two confusing concepts. The author lists two instances. One is Emacs, which is implemented by using a program driven by LISP-that is, the C service program is driven by an embedded scripting language:C LanguageWrite the underlying service (engine), call the script language, and use the script language to implement the process. Another example is to divide applications into the frontend and backend for collaboration, the frontend implementation policy, and the backend implementation mechanism.

You can think of interfaces as policies (user interfaces) and engines as mechanisms.

Note: The concept of "isolated change" is mentioned in the Code Daquan, and the idea of separating the easy-to-change part from the easy-to-change part is also mentioned in the design pattern.

5. Concise Principle: The design should be concise, and the complexity should be lower.

Various pressures make the program complex. One of the pressures is the technical vanity. Programmers are very smart and often proud of playing complex things and playing abstract concepts. "Let's see who can stick to the most complicated and wonderful thing ":

"It sounds self-contradictory. UNIX programmers are proud of who can be" concise and beautiful.

Another view comes from the software marketing strategy: to see who provides more features-this will eliminate excellent design.

We need to encourage a culture that is concise and beautiful, and can take advantage of complicated things.

6. stingy principle: Do not write large programs unless you do not have it.

Meaning: it is large and complex;

Avoid splitting programs by writing large programs. One program only does one thing well.

7. transparency principle: design should be visible for review and debugging

Debugging accounts for 3/4 of the Views. An effective way to reduce debugging workload is to fully consider transparency and visibility at the beginning of the design.

The transparency of the software system means that you can see at a glance what the software is doing and how it is done. Visibility refers to the program's function of monitoring and displaying internal states. Such a program not only runs well, but also shows how it runs.

If you fully consider this during design, it will bring benefits to the entire project process.

8. robustness principle: Robustness stems from transparency and conciseness.

The robustness of Software means that the software runs well not only under normal circumstances, but also beyond the unexpected conditions imagined by the designer.

Most software lacks robustness because it is too complex.

Robust Method: makes the internal logic of the program easier to understand. There are two main methods: transparency and simplification. The simpler the program, the more transparent it is, the more robust it is.

Modularity (simple code and concise interfaces) is a way to organize programs for a more concise purpose.