《Pragmatic.Programmer》精华摘录

柔情只为你懂 2022-08-25 10:57 291阅读 0赞

**Chapter 1. A Pragmatic Philosophy**

**Section 1 The Cat Ate My Source Code**  
  
  **Tip 3 Provide Options, Don't Make Lame Excuses(不要为失误找借口)**  
  
  
 **Section 2 Software Entropy(熵)**  
  
  **Tip 4 Don't Live with Broken Windows(无人维护的屋子会迅速破败)**  
  
   
**Section 3 Stone Soup and Boiled Frogs**  
  
 **Tip 5 Be a Catalyst for Change(恰如其分的充当催化剂，激发他人)**  
  
  **Tip 6 Remember the Big Picture(审视全局，不要执迷于局部)**  
   
  
**Section 4 Good-Enough Software**  
  
 **Tip 7 Make Quality a Requirements Issue(不存在完美的软件)**   
  
  
**Section 5 Your Knowledge Portfolio  
  
"An investment in knowledge always pays the best interest."**  
  
 **Tip 8 Invest Regularly in Your Knowledge Portfolio(不断学习)**  
   
 **Tip 9 Critically Analyze What You Read and Hear(不要填鸭式的获取知识)**  
   
  
**Section 6 Communicate!  
  
 "I believe that it is better to be looked over than it is to be overlooked."**  
  
  **Tip 10 It's Both What You Say and the Way You Say It(内容和方式同等重要)**

**Chapter 2. A Pragmatic Approach**

**Section 1 The Evils of Duplication**  
  
  **Tip 11 DRY—Don't Repeat Yourself(避免信息的冗余)**  
   
  **Tip 12 Make It Easy to Reuse (设计应易于被重用)**  
  
The DRY principle tells us to keep the low-level knowledge in the code, where it belongs, and reserve the comments for other, high-level explanations. Otherwise, we're duplicating knowledge, and every change means changing both the code and the comments  
  
Think also about comments in header and implementation files. There is absolutely no point in duplicating a function or class header comment between the two files. Use the header files to document interface issues, and the implementation files to document the nitty-gritty details that users of your code don't need to know.  
  
An important issue for object-oriented languages such as Java and C++： Where possible, always use accessor functions to read and write the attributes of objects.\[1\] It will make it easier to add functionality, such as caching, in the future.  
  
   
**Section2 orthogonality(正交性)**  
  
  **Tip 13 Eliminate Effects Between Unrelated Things(无关实体应该互不影响)**  
  
However, the concept of orthogonality is rarely taught directly. Often it is an implicit feature of various other methods and techniques you learn. This is a mistake. Once you learn to apply the principle of orthogonality directly, you'll notice an immediate improvement in the quality of systems you produce.  
  
In computing, the term has come to signify a kind of independence or decoupling  
  
We want to design components that are **self-contained**: independent, and with a single, well-defined purpose  
  
Also ask yourself how decoupled your design is from changes in the real world. Are you using a telephone number as a customer identifier? What happens when the phone company reassigns area codes? Don't rely on the properties of things you can't control.  
  
The Enterprise Java Beans (EJB) system is an interesting example of  orthogonality  
  
**Section 3 Reversibility(可逆性)  
  
"Nothing is more dangerous than an idea if it's the only one you have."**  
  
 **Tip 14 There Are No Final Decisions(避免不可变动的设计)**  
  
   
**Section 4 Tracer Bullets**  
  
  **Tip 15 Use Tracer Bullets to Find the Target**  
  
 Pragmatic Programmers, however, tend to prefer using tracer bullets.  
  
Tracer code is not disposable: you write it for keeps  
  
Tracer development is consistent with the idea that a project is never finished: there will always be changes required and functions to add. It is an incremental approach.  
  
You might think that this tracer code concept is nothing more than prototyping under an aggressive name. There is a difference  
  
**Section 5 Prototypes and Post-it Notes**  
  
  **Tip 16 Prototype to Learn(通过原型系统来加深理解)**  
  
We tend to think of prototypes as code-based, but they don't always have to be  
  
Prototypes are designed to answer just a few questions, so they are much cheaper and faster to develop than applications that go into production. The code can ignore unimportant details—unimportant to you at the moment, but probably very important to the user later on.  
  
Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned. That's really the point of prototyping.  
  
  
**Section 6 Domain Languages**  
  
**"The limits of language are the limits of one's world."**  
  
  **Tip 17 Program Close to the Problem domain (选择最适合解决问题的语言)**  
  
  
**Section 7 Estimating**  
   
 **Tip 18 Estimate to Avoid Surprises( 善于估算问题)**  
   
 **Tip 19 Iterate the Schedule with the Code**

**Chapter 3. The Basic Tools**

**Section 1 The Power of Plain Text**  
  
  **Tip 20 Keep Knowledge in Plain Text( 用文本方式存储和表示信息)**  
  
There are two major drawbacks to using plain text:  
  
(1) It may **take more space** to store than a compressed binary format, and  
(2) it may be **computationally more expensive** to interpret and process a plain text file.  
  
**In fact, in heterogeneous environments the advantages of plain text can outweigh all of the drawbacks. You need to ensure that all parties can communicate using a common standard. Plain text is that standard.**  
  
  
  
**Section 2**  **Shell Games**  
  
  **Tip 21 Use the Power of Command Shells(善用命令行的强大威力)**   
  
A benefit of GUI is **WYSIWYG**—what you see is what you get. The disadvantage is **WYSIAYG**—what you see is all you get  
  
  
**Section 3 Power Editing**  
  
 **Tip 22 Use a Single Editor Well(精通一种编译器)**  
  
**Section 4 Source Code Control**  
  
 **"Progress, far from consisting in change, depends on retentiveness. Those who cannot remember the past are condemned to repeat it."**  
   
**Tip 23 Always Use Source Code Control( 总是使用版本控制)**  
  
**Section 5 But My Team Isn't Using Source Code Control  
  
Section 6 Source Code Control Products  
  
Section 7 Debugging**  
  
  Unfortunately, modern computer systems are still limited to doing what you tell them to do, not necessarily what you want them to do.  
  
  **Tip 24 Fix the Problem, Not the Blame(首先解决问题，而不是抱怨)**  
  
 The easiest person to deceive is one's self  
  
  Before you start debugging, it's important to adopt the right mindset. You need to turn off many of the defenses you use each day to protect your ego  
  
  If your first reaction on witnessing a bug or seeing a bug report is "that's impossible," you are plainly wrong.  
  
 The best way to start fixing a bug is to make it reproducible. After all, if you can't reproduce it, how will you know if it is ever fixed?  
  
   **Tip 25 Don't Panic**  
  
  **Tip 26 "select" Isn't Broken(低层机制-OS,数据库很少出错，出错的是你自己)**  
  
  **Tip 27 Don't Assume It—Prove It(不要参测，证实它)**  
  
  
**Section 8 Text Manipulation**  
  
  **Tip 28 Learn a Text Manipulation Language(学会一种文本处理语言)**  
  
  
 **Section 9 Code Generators**  
  
  **Tip 29 Write Code That Writes Code**  
  
  There are two main types of code generators:  
  
**Passive code generators**——run once——for convenience  
  
**Active code generators**——run more than once——sometimes necessary  
  
Whenever you find yourself trying to get two disparate environments to work together, you should consider using active code generators.  
  
All this talk of active this and passive that may leave you with the impression that code generators are complex beasts. They needn't be. Normally the most complex part is the parser, which analyzes the input file

**Chapter 4. Pragmatic Paranoia**

**Tip 30 You Can't Write Perfect Software**  
  
**Section 1 Design by Contract  
  
“Nothing astonishes men so much as common sense and plain dealing.”**  
  
  **Tip 31 Design with Contracts(契约式编程)**  
  
  What is a correct program? One that does no more and no less than it claims to do. Documenting and verifying that claim is the heart of Design by Contract (DBC, for short).  
  
Meyer describes these expectations and claims as follows:  
  
  **Preconditions**  
 **Postconditions**  
 **Class invariants**  
  
  By not stating these things, you are back to programming by coincidence, which is where many projects start, finish, and fail.  
  
  **"lazy" code**: be strict in what you will accept before you begin, and promise as little as possible in return.  
  
 **Assertions**:  
  
Can't you use assertions to do everything DBC can do? Unfortunately, the answer is no  
  
**Other Uses of Invariants**  
  
  **loop invariant**  
  
 a loop invariant is a statement of the eventual goal of a loop, but is generalized so that it is also valid before the loop executes and on each iteration through the loop.  
  
 **semantic invariants**(be central to the very meaning of a thing)  
  
When your code discovers that something that was supposed to be impossible just happened, your program is no longer viable. Anything it does from this point forward becomes suspect, so terminate it as soon as possible  
  
   
**Section 2 Dead Programs Tell No Lies**  
  
  **Tip 32 Crash Early(问题发现的越早越好)**  
  
  
**Section 3 Assertive Programming  
  
"There is a luxury in self-reproach. When we blame ourselves we feel no one else has a right to blame us"**  
  
  **Tip 33 If It Can't Happen, Use Assertions to Ensure That It Won't(用断言来确认不可能的事情确实未发生)**  
  
Whenever you find yourself thinking "but of course that could never happen," add code to check it.  
  
  
**Section 4 When to Use Exceptions**  
  
 **Tip 34 Use Exceptions for Exceptional Problems(异常用于处理"异常"状况)**  
  
  
 **Section 5 How to Balance Resources**  
  
 **Tip 35 Finish What You Start(申请的资源要记得施放)**  
  
**Nest Allocations**  
  
When allocating the same set of resources in different places in your code, always allocate them in the same order. This will reduce the possibility of deadlock

**Chapter 5. Bend or Break**

**Section 1 Decoupling and the Law of Demeter**  
  
 **"Good fences make good neighbors."**   
  
  **Tip 36 Minimize Coupling Between Modules(将模块间的耦合最小化)**  
  
  
Writing "shy" code is beneficial. But "shy" works two ways: don't reveal yourself to others, and don't interact with too many people.  
  
As a "general contractor," your module must delegate and manage any and all subcontractors directly, without involving clients of your module  
  
 **physical decoupling & logical decoupling**  
  
  
**Section 2 Metaprogramming**  
  
   
 **Tip 37 Configure, Don't Integrate(设计应具备灵活的可配置性)**  
  
 **meta-data is data about data**  
  
 Meta-data is any data that describes the application—how it should run, what resources it should use, and so on.  
  
 **General rule**  
  
 program for the general case, and put the specifics somewhere else—outside the compiled code base.  
  
 **Tip 38 Put Abstractions in Code, Details in Metadata(代码应该是抽象的，细节则由metadata存储和表示)**   
  
  
**Section 3 Temporal Coupling**  
  
**"What is temporal coupling all about, you may ask. It's about time."**  
  
  **Tip 39 Analyze Workflow to Improve Concurrency(分析公作流以改善并发性)**  
  
  **Tip 40 Design Using Services**  
   
 **Tip 41 Always Design for Concurrency(设计应总是考虑到并发性)**  
  
  
  
**Section 4 It's Just a View**  
  
  **Tip 42 Separate Views from Models**  
  
 **MVC Model**：separating the model from both the GUI that represents it and the controls that manage the view  
  
  
The view and controller are tightly coupled, and in some Implementations of MVC the view and controller are a single component.  
  
 **Model**：The abstract data model representing the target object. The model has no direct knowledge of any views or controllers.  
  
**View**： A way to interpret the model. It subscribes to changes in the model and logical events from the controller.  
  
**Controller**： A way to control the view and provide the model with new data. It publishes events to both the model and the view.  
  
  
**Section 5 Blackboards**  
  
 **Tip 43 Use Blackboards to Coordinate Workflow(利用黑板模式协调工作流)**  
  
A big advantage of systems such as blackboard is that you have a single, consistent interface to the blackboard

**Chapter 6. While You Are Coding**

**Section 1 Programming by Coincidence**  
  
  **Tip 44 Don't Program by Coincidence**  
  
  
**Section 2 Algorithm Speed**  
  
  **Tip 45 Estimate the Order of Your Algorithms  
  
  Tip 46 Test Your Estimates**   
  
**Section 3 Refactoring**  
  
  **Tip 47 Refactor Early, Refactor Often**  
  
  Rather than construction, software is more like gardening—it is more organic than concrete  
  
At its heart, refactoring is redesign.  
  
  
**Section 4 Code That's Easy to Test**  
  
  **Tip 48 Design to Test(设计应始终考虑测试)**  
  
  **Tip 49 Test Your Software, or Your Users Will**  
  
**Section 5 Evil Wizards**  
  
  **Tip 50 Don't Use Wizard Code You Don't Understand**

**Chapter 7. Before the Project**

**Section 1 The Requirements Pit  
  
 "** **Perfecti** **on is achieved, not when there is nothing left to add, but when there is nothing left to take away** **"**  
   
 **Tip 51 Don't Gather Requirements—Dig for Them(正确的需求需要深入挖掘)**  
  
  **Tip 52 Work with a User to Think Like a User**  
  
It's important to discover the underlying reason why users do a particular thing, rather than just the way they currently do it  
  
 **Tip 53 Abstractions Live Longer than Details**  
  
  **Tip 54 Use a Project Glossary(统一概念名称)**  
  
**Section 2 Solving Impossible Puzzles**  
  
  **Tip 55 Don't Think Outside the Box—Find the Box(认清问题的实质)**  
  
The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you'll find your solution  
  
All you need are the real constraints, the misleading constraints, and the wisdom to know the difference.  
  
**Section 3 Not Until You're Ready**  
  
  **Tip 56 Listen to Nagging Doubts—Start When You're Ready**  
  
How can you tell when you're simply procrastinating, rather than responsibly waiting for all the pieces to fall into place?  
  
A technique that has worked for us in these circumstances is to start prototyping  
  
  
**Section 4 The Specification Trap**  
  
 **Tip 57 Some Things Are Better Done than Described(避免文档的过度规范)**  
  
**Section 5 Circles and Arrows**  
   
 **Tip 58 Don't Be a Slave to Formal Methods(不要沦为方法的奴隶)**  
  
  **Tip 59 Expensive Too Do Not Produce Better Designs**

**Chapter 8. Pragmatic Projects**

**Section 1 Pragmatic Teams**  
   
 **Tip 60 Organize Around Functionality, Not Job Functions**  
  
  
 **Section 2 Ubiquitous Automation**  
  
 **"Civilization advances by extending the number of important operations we can perform without thinking."**  
  
  **Tip 61 Don't Use Manual Procedures**  
  
People just aren't as repeatable as computers are. Nor should we expect them to be.  
  
 **The Cobbler's Children**  
  
The cobbler's(鞋匠) children have no shoes. Often, people who develop software use the poorest tools to do the job.  
  
  
**Section 3 Ruthless Testing**  
  
  **Tip 62 Test Early. Test Often. Test Automatically.**  
  
Finding bugs is somewhat like fishing with a net. We use fine, small nets (unit tests) to catch the minnows, and big, coarse nets (integration tests) to catch the killer sharks  
  
"**Code a little, test a little**" is a popular saying in the **Smalltalk world**  
  
 **Unit testing** is the foundation of all the other forms of testing that we'll discuss in this section  
  
**Integration Testing** is often the single largest source of bugs in the system.  
  
 **Regression Testing**:compares the output of the current test with previous (or known) values  
   
 **Tip 63 Coding Ain't Done 'Til All the Tests Run**  
  
  **Tip 64 Use Saboteurs to Test Your Testing(故意引入bug，来检查测试系统)  
  
  Tip 65 Test State Coverage, Not Code Coverage**   
   
 **Tip 66 Find Bugs Once(一个bug不应被多次被人工检测到)**  
  
  
**Section 4 It's All Writing**  
  
**“The palest ink is better than the best memory.——Chinese Proverb”**  
  
  **Tip 67 Treat English as Just Another Programming Language**  
   
**Tip 68 Build Documentation In, Don't Bolt It On(文档应随代码同时产生)**  
  
**Comments in Code**  
  
In general, comments should discuss why something is done, its purpose and its goal. The code already shows how it is done, so commenting on this is redundant—and is a violation of the DRY principle.  
  
One of the most important pieces of information that should appear in the source file is the author's name—not necessarily who edited the file last, but the owner  
  
The model is the source code: one view of the model can be compiled; other views are meant to be printed out or viewed on the Web  
  
**Section 5 Great Expectations**  
  
 **Tip 69 Gently Exceed Your Users' Expectations(产品完成的应比客户的期望更好一些，但不要"好太多")**  
  
**Section 6 Pride and Prejudice**  
   
 **Tip 70 Sign Your Work(在作品中自豪的留下作者的名字)**

style="border: 0px none ; margin: 0px; padding: 0px; overflow: hidden; width: 100%; height: 24px;" id="oakvoc\_iframe\_title">

style="border: 0px none ; margin: 0px; padding: 0px; overflow: hidden; width: 100%; height: 328px;" id="oakvoc\_iframe">