Third Reading "UNIX Programming Art" --UNIX philosophy

If my current career to elect an impact on my greatest books, I will choose "UNIX Programming Art" ESR's. The first time you read this book junior, more reading materials as a point of view, but with a more professional in contact with different operating systems, complete more projects product design, architecture, implementation, of the book is to talk had a greater resonance. In the third reading the book on the occasion, the book extract a lot of valuable ideas out to a summary of their own, it also brings hope to give everyone a share.


The book focuses attention: more than just a method, almost more important idea. Knowledge (methods) and their professionalism huge (the concept of) difference, by virtue of knowledge can be inferred what to do, but specifically make you even unintentionally, like a conditioned reflex to get things done.

  • UNIX look of vitality: Today, metaplasia as Linux, BSD, Solaris, MacOS X and several other variants of Unix, making it stronger than ever. This UNIX stable and strong vitality will make you more stable investment knowledge.

  • UNIX design philosophy: always better than the end-user operating system designers more clearly what they really need. It provides a mechanism, not policy. Although such a laissez-faire style will make you lose a lot of non-technical users. But in the long run, this is an advantage, because the strategy is relatively short-lived, and the mechanism will be forever .

  • Criticism of the windows: in such an operating system, a complete operating system for the foreseeable task is easy, but did not expect to complete its task, the user can not do anything that is not painful. But UNIX has a very complete flexibility.

  • UNIX-hack of interest: for programmers and developers, to complete a task if the effort required is a challenge for them but just another within the limits of its resources, they will feel a lot of fun. Therefore, the interest is a sign of peak efficiency. Painful development environment will only waste labor and creativity; only time-consuming virtually, money, opportunity.

UNIX philosophy

Unix philosophy is bottom-up, rather than top-down. Unix philosophy pragmatic, based on a wealth of experience. You will not find it in the formal methodologies and standards, it is closer to the semi-invisible instinctive knowledge that professional experience UNIX culture propagation.

  1. Module principle: the use of the interface simple simple split member

    • Essence of computer programming is to control complexity.

    • With a clean interface to several simple modules are combined into a complex software. As a result, most of the problems will only be confined to a localized, then there is hope for local improvements rather than to affect the whole body.

  2. Clear principles: clarity rather than ingenuity

    • Maintenance costs are so high and so important; when writing a program, you do not want to think of computer code written for execution look, but giving - read the future maintenance of the source code, including your own - to read.

  3. A combination of principles: to consider a combination of stitching design

    • In terms of input and output, Unix strongly advocate using conventional simplification, textual, for the independent flow device format.

  4. The principle of separation: separation mechanism with the strategy, the interface with the engine disconnected

  5. Simple principle: to design simple, low complexity can lower the

    • Pressure from a wide range of programs will often become complex, one of which is from the technical vanity.

    • Excessive complexity often comes from the project requirements, and these requirements are often based on selling hot month, instead of giving functional needs of customers and software can actually provide.

    • To avoid these pitfalls, the only way is to encourage other software culture, concise for the United States, all of the large and complex things accusation - this is a very simple traditional value engineering solutions, always managed to program system into smaller parts to collaborate and instinctively resist any attempt to use too many gimmicks to whitewash the program.

  6. Stingy principle: unless there is no alternative, do not write large programs

  7. The principle of transparency: Design to be seen in order to review and debugging

    • Because the debugger usually takes up three-quarters or more of development time, so we start to do more work in order to reduce the workload of the future will be very cost-effective debugging. A particularly effective method for reducing debugging workload is obvious transparency and full consideration of the design.

  8. Robustness: robust based on a transparent and simple

  9. Expressed principles: knowledge in order to stack the data into logical simple and robust

    • Data more manageable than the programming logic. So then, if you want to select a complex data and complex code, I would prefer the former. Furthermore: In the design, you should take the initiative to the complexity of the code transferred into the data go.

  10. Popular principles: Avoid unconventional interface design

    • Most user-friendly program is that users need to learn something new minimum program - or, in other words, the most user-friendly program that is most relevant to a user's existing program knowledge.

  11. Silence principle: If a program does not have much to say, remains silent

  12. Remedy principle: When an exception occurs, immediately exits with an error message enough

    • Software relaxed as possible to cope with a variety of input errors and their runtime error. However, if this is not possible, let the program as much as possible in an easy diagnosis wrong way to terminate.

  13. Economic principles: the machine rather spend a minute, do not spend one second programmer

  14. Generating principles: avoid hand-hack, try to write a program to generate program

  15. Optimization principles: come prototypes before carving, first learn to walk before running

    • 90% of the functionality can now achieve more than 100% of the functionality can not always achieve strong. Prototyping can do to help you avoid petty and invested too much time.

    • The first prototype, and then crafted. Before optimization can make sure.

    • Give your design to be a non-optimized, slow, memory-intensive but very correct implementation, and then adjust the system, look for places where you can obtain a larger performance gain at the expense of the minimum local simplicity.

  16. Diversity principle: Never believe the so-called "only way" assertion

  17. Extended principles: focus on the future design of the future better than expected fast

    • To leave room for the expansion of data formats and codes.

    • When designing protocol or format, so that it should have sufficient expansion so as to be self-descriptive.

All of the Unix philosophy condensed into an iron law

KISS——Keep It Simple,Stupid!


Released eight original articles · won praise 18 · views 8779

Guess you like

Origin blog.csdn.net/weixin_38054045/article/details/104243910