The Pragmatic Programmer :From Journeyman to Master

TIPS
1.Care About Your Craft
2.Think About Your Work
3.Provide Options，Don't Make Lame Excuses
4.Don't Live with Broken Windows
5.Be A Catalyst of Change
6.Remember The Big Picture
7.Make Quality a Requirements Issue
8.Invest Regularly in Your Knowledge Portfolio
9.Critically Analyze What You Read and Hear
10.It's both What You Say and the Way you Say it
11.Don’t repeat yourself
12.MAKE It Easy To Reuse
13.Eliminate Effects Between Unrelated Things
14.There are No Final Decisions
15.Use Tracer Bullets to Find the Target
16.Prototype to Learn
17.Program To the Problem domain
18.Estimate to Avoid Surprises
19.Iterate the Schedule with the Code
20.Keep Knowledge in Plain Text
21.Use the Power of Command Shells
22.Use a Single Editor Well
23.Always Use Source Code Control
24.Fix the Problems, Not the Blame
25.Don't Panic
26."Select" Isn't Broken
27.Don't Assume it, Prove it
28.Learning a Text Manipulation Language
29.Write Code that Write Code
30.U can't Write Perfect Software
31.Design with Contracts
32.Crash Early
33.If It Can't Happen ，Use Assertions To Ensure That It Won't
34.Use Exceptions for Exceptional Problems
35.Finish What U Start
36.Minimize Coupling Between Modules
37.Configture ,Don’t Integrate
38.Put Abstractions in Code, Details in Metadata
39.Analyze Workflow to Improve Concurrency
40.Design Using Services
41.Always Design for Concurrency
42.Seperate Views from Models
43.Use Blackboards to Coordinate Workflow
44.Estimate the Order of Your Algorithms
45.Test Your Estimates
46.Refactor Early,Refactor Often
47.Design to Test
48.Test Your Software Or Your Users Will
49.Don't Use the Wizard Code You Don't Understand
50.Don't gather Requirement，Dig for Them
51.Work Like A User To Think like A User
52.Abstractions Live Longer than Details
53.Use a Project Glossary
54.Don't Think Outside the box，-Find the box
55.Listen to Nagging Doubts - Start When You're Ready
56.Something are better Done than Described
57.Don't be a Slave to Formal Methods
58.Costly Tools Don't Produce Better Design
59.Organize Teams Around Functionality
60.Orgnize Teams Around Functionality
61.Don't Use Manual Procedures
62.Test Early, Test often. Test Automatically.
63.Coding Ain't Done,Till All The Test Done.
64.Use Saboteurs To Test Your Testing.
65.Test State Coverage, Not Code Coverage.
66.Find Bugs Once
67.English Is Just A Programming Language.
68.Gently Exceed Your Users' Expectations
69.Build Document In, Don't Bolt It On.
70.Sign Your Work

Words
知識上的投資總能獲得最好的回報
——本傑明 * 富蘭克林
我相信被打量比被忽略要好
——Mae West
語言的界限就是一我的的世界的界限
——維特根斯坦
進步遠非由變化組成，而是取決於好記性。不能記住過去的人，被判重複過去
——George Santayana
最容易欺騙的人事一我的本身
——Edward Bulwer-Lytton
每一個人都確實要對你不利時，偏執就是一個好主意
——Woody Allen
沒有什麼比常識和坦率更讓人感到驚訝
——拉爾夫*沃爾多*愛默生
我把你帶進這個世界，我也能夠把你趕出去，那沒有我影響，我要再造另外一個你
——Bill Cosby
好籬笆促成好鄰居
——羅伯特*弗羅斯特
再多的天才也沒法賽過對細節的專一
——Levy's English Law
不要假定，要證實
——佚名
按照合約設計
——佚名
完美，不是在沒有什麼須要增長、而是在沒有什麼須要去掉的時候達到的
——Antoine de St.Exupery

正交性
在計算機技術中，正交性表示某種不相依賴性或者是解耦性。若是兩個或者更多事物中的一個發生變化，不會影響其它事物，這些事物就是正交的。在設計良好的系統中，數據庫代碼和用戶界面是正交的：你能夠改動界面，而不影響數據庫；更換數據庫，而不用改動界面。

重構
養成不斷地批判的對待本身代碼的習慣。尋找任何從新進行組織、以改善其結構和正交性的機會。這個過程叫作重構（Refactoring）

薛定諤的貓
假定在一個密封的盒子有一隻貓和一個放射性的粒子。這個粒子正好有百分之五十的機會分裂。若是裂變了，貓就會被殺死，反之則不會。貓是死是活？按照理論，正確的答案是「都對」，每當有兩種可能結果的亞核反應發生時，宇宙就會被克隆。只有當你打開盒子的時候才知道你處於哪一個宇宙裏。

事件
一旦你基於責任把程序劃分爲不一樣的模塊，你就有了新的問題，在運行時，對象之間怎樣相互交互，你怎樣理解邏輯，怎樣同步不一樣對象中的狀態的變化，可是咱們不想讓它們相互知道的太多，要像TheBox同樣，只聽到它想聽到的東西，事件EVENTS 就是一個特殊的消息，說明剛剛發生了什麼有趣的事情，咱們能夠用事件把某個對象的狀態變化通知發送給可能感興趣的其餘對象。事件發送者不須要對接受者有任何的瞭解，能夠存在多個接收者，每一個接受者都專一於本身的「議事日程「。

MVC
咱們建立一個模型--數據自己，以及用於對其進行操縱的經常使用操做。而後咱們建立不一樣的視圖，以不一樣的方式顯示數據：做爲電子表格、做爲圖表、或是在總計框中。每一個視圖都有本身的控制器。這是位於Model-View-Controller（MVC）慣用手法以後的關鍵概念：既讓模型與表示模型Gui分離，也讓模型與管理視圖的控件分離。這樣作可有許多有趣的可能性。你能夠支持同一數據模型的多個視圖。你能夠在許多不一樣的數據模型上使用公用的查看器。你甚至還能夠支持多個控制器，以提供非傳統的輸入機制。

算法速率
能夠有許多常識估算估算許多基本算法的階：簡單循環 O(n)，嵌套循環 O(m x n),分而治之 O(nln(n)) ,二分法O(ln(n)), 組合 時間可能會失去控制。

軟件測試
一旦某個軟件部署之後，你經常須要對其進行測試--在現實世界的數據正留過它的血脈時。咱們能夠提供模塊的內部狀態的各類視圖，而不適用調試器。含有跟蹤信息的日誌文件就是這樣一種機制。日誌文件的格式應該正規、一致。你或許須要自動解析它們，以推斷程序所用時間或邏輯路徑。瞭解程序運行中的代碼的內部情況的另一種機制是「熱鍵」序列。按下特定的鍵組合，就會彈出一個診斷控制窗口，顯示狀態消息等信息。對於更大更復雜的服務器代碼，提供其內部操做的內部視圖是一種漂亮技術是使用內建的Web服務器。任何人均可以讓Web瀏覽器指向應用的HTTP端口，並看到內部狀態、日誌條目、甚至多是某種調試控制面板。

需求
製做需求文檔時的一大危險就是太過具體。好的需求文檔會保持抽象。在涉及需求的地方，最簡單、可以準確的反映商業須要的陳述是最好的。需求不是架構。需求不是設計。也不是用戶界面。需求是須要。

反饋會訓練你的下意識和反應能力