Unix programming philosophy and Software Design Methods

 

UNIXProgramming philosophy:

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

2. Clear principle: Clear is better than clever.

3. Combination Principle: Consider splicing and combination during design.

4. separation principle: the policy and mechanism are separated, and the interface is the same as the engine.

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

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

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

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

9. expression principle: Fold knowledge into data to make the logic simple and robust.

10, the general principle: interface design to avoid unconventional.

11. Silence principle: if a program has nothing to say, it will be silent.

12. remedy principle: if an exception occurs, exit immediately and provide sufficient error information.

13. Economic Principle: rather than spending a second on machines, it will take a second on programmers.

14. Generation Principle: Avoid manual hack and write programs to generate programs as much as possible.

15. Optimization Principle: you must first have the original type before carving, and learn to go before running.

16. Principles of diversity: never believe in the so-called "no two methods" assertions.

17. Expansion principle: design focuses on the future, and the future is always faster than expected.

 

In addition:

A program only does one thing and does a good job.

Programs must be able to collaborate.

The program must be able to process text streams because this is the most common interface.

From the book "Unix programming art. These principles are mentioned in many books on software engineering, design patterns, and agile development.

 

Sometimes my colleagues are challenged by design issues. It is quite troublesome to explain, not to be clear in just a few words.
These principles will be backed up in the future, and the challenges will be based on the ** principle. If you are not clear about the book Unix programming art or agile development, it is easy to explain.

 

Some people prefer the binary protocol and think that the text protocol is a waste of resources. In fact, there is not much text protocol waste (except for XML format). There are many programs that can be processed and the error correction capability is strong. Most importantly, it is easy for people to view and edit.

 

Some people require optimization to improve machine execution efficiency. In fact, many of them are useless. Even because of the introduction of bugs. At least make the code harder to understand. The tested bottlenecks should be optimized, rather than taken for granted.

 

Some people prefer to use a large program to complete the task, rather than multiple small programs. Because the interaction between threads is simple, and the interaction between processes is complex, and inter-process communication is required, the efficiency is low. The advantage of multiple applets is that they provide mechanisms rather than policies. It is easy to reuse and has greater flexibility to meet multiple needs.

 

In addition, it can accumulate a lot of reusable tools to improve development efficiency in the future.
Some companies have been operating for many years and have not accumulated at all. Every time they come to the project, they should start from scratch.

If you do not want to or cannot be divided into multiple small programs, at least provide logical isolation between the service and the GUI layer. In this way, modules such as the service layer can be packaged into dynamic link libraries and jar packages for reuse.
 

 

In this way, if at least one day your web program needs to provide openapi (which is very popular now), you do not need to make a big fuss and rewrite a lot of code.

 

In addition, the quality of Open Source Code such as Linux is excellent, that is, full source code exposure and source code review.
It is recommended that the company establish open and open source code review in the project to improve the code quality. Of course, this is hard to be achieved by politically serious teams in some companies. Conflicts may occur between programmers.

15. Optimization Principle: you must first have the original type before carving, and learn to go before running.

<! --
@ Page {margin: 2 cm}
P {margin-bottom: 0.21}
A: link {so-language: zxx}
-->

Some engineers like waterfall development. I wrote the design document for several months, and the future is very beautiful. The code line is not dynamic.

The project was last extended, and finally found that the architecture design had fundamental problems and bug fixes were difficult. The project could only be canceled or completely rewritten.

 

It is difficult to figure out the entire technical solution without going deep into the problem and getting close contact with it.

I like to design a prototype, build a shelf, and find risky technical problems. And the problem, and then adjust and reconstruct to get a working prototype, and also get the design scheme. And then implement it step by step.

I am very surprised that some engineers haven't figured out the problem and the technical risks have not been ruled out, so they dare to spend a lot of time writing detailed design solutions!

It can be understood that, after all, the overall design of the project will not change much.