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">
![浏覽<Pragmatic Thinking and Learning:Refactor Your “Wetware”>筆記[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)