1.爲什麼中國的程序員總是在不斷學習新的開發工具、鑽研程序代碼，而不呢逐步提升自己的視野、思維和經驗？
2.從衆多面向對象建模的描述中，你可以橫清楚地看到這些惡果，而且它們還經常伴隨着有關現實世界建模的非常美好的詞彙。然而，仔細看看，你就好發現它們其實是徹頭徹尾的編程對象！
3.如果說有任何和現實世界相似的地方，不管是死是活，純屬巧合。。。。。。
4.手中有個錘子，看到什麼都是釘子。
5.我相信由於人員的分工，大型編程項目碰到的管理問題和小項目碰到的管理問題區別很大；我相信關鍵需要的是維持產品自身和概念完整性。
6.學習編程最困難的部分，是將做事的方式向追求完美的方向調整。
7.大型的或小型的，龐雜的或精幹的，一個接一個淹沒在了焦油坑中。表面上看起來好像沒有任何一個單獨的問題會導致困難，每個問題都能獲得解決，但是當它們相互糾纏和累積在一起的時候，團隊的行動就會變得越來越慢。對問題的麻煩程度，每個人似乎都會感到驚訝，並且很難看清問題的本質。不過，如果我們想解決問題，就必須試圖先去了解問題。
8.不真實的假設——一切都將運作良好。
9.所以系統編程的進度安排背後的第一個錯誤的假設是：一切都將運作良好，每一項任務僅花費它所應該花費的時間。
10.是開發人員承擔創造性好發明性的實現責任，所以結構師只能建議，而不能支配。
11.有意識關注這個系統（第二個）的特殊危險；運用特別的自我約束準則，來避免那些功能上的過於修飾；根據系統基本理念及目的變更，捨棄一些功能。
12.保持對特殊誘惑的警覺，他可以不斷提出正確的問題，確保原則上的概念和目標在詳細設計中得到完整的體現。
13.絕不要攜帶兩個時鐘出海，帶一個或三個。
14.手冊不但要描述包括所有界面在內的用戶可見的一切，它同時還要避免描述用戶看不見的事物。後者是編程實現人員的工作範疇，而這裏他的設計和創造自由是不應該被限制的。體系結構設計人員必須爲自己描述的任何特性準備一種實現方法，但是他不應該視圖支配具體的實現過程。
15.形式化定義僅僅用於外部功能，說明它們是什麼。
16.所有定義的問題可以通過測試來解決。
17.作爲一種定義，實現體現了過多的內容：它不但描述了系統必須做什麼，同時還聲明瞭自己到底做了什麼。
18.當實現充當標準時，還必須防止對實現的任何修改。
19.正式的書面建議集中了注意力，強制了決策的制定。避免了會議草稿紀要方式的不一致。
20.同任何開銷一樣，規模本身不是壞事，但不必要的規模是不可取的。
21.任何在規模上碰到問題的程序員，會檢查自己的代碼，看是否能將其中一部分扔給其他人。
22.爲了滿足目標，每個人都在局部優化自己的程序，很少會有人停下了，考慮一下對客戶的整體影響，對大型項目而言，這種導向和缺乏溝通是最大的危險。在整個實現的過程期間，系統結構師必須保持持續的警覺，確保連貫的系統完整性。在這種監督機制之外，是實現人員自身的態度問題。培養開發人員從系統整體出發、面向用戶的態度是軟件編程管理員最重要的職能。
23.只有記錄下來，分歧纔會明朗，矛盾纔會突出。
24.不變只是願望，變化纔是永恆。
25.爲捨棄而計劃，無論如何，你一定要這樣做。
26.變化是與生俱來的，不是不合時宜和令人生厭的異常情況。
27.開發人員交付的是用戶滿意程度，而不僅僅是有形的產品，用戶的實際需要和用戶感覺會隨着程序的構建、測試和使用而變化。
28.軟件產品易於掌握的特性和不可見性，導致它的構建人員面臨永恆的需求變更。
29.拋棄原型概念本身就是對事實的接受——隨着學習的過程更改設計。
30.高強度的考驗查出了新功能中很多不易察覺的問題。
31.產品的概念完整性在使它易於使用的同時，也使開發更容易進行，而且Bug更不容易產生。
32.開發人員自己無法完成這項工作，他們不會告訴你他們不懂。相反，他們樂於自己摸索出解決問題和澄清疑惑的辦法。
33.一些糟糕的系統往往就是試圖挽救一個基礎很差的設計，而對它添加了各種表面裝飾般的補丁。
34.計劃日期是項目經理的工作產物，代表了經協商後的項目整體工作計劃，它是合理計劃之前的判斷。
35.估計日期代表了再現有資源和已得到了作爲先決條件的必要輸入的情況下，基層經理對實際實現日期的最佳判斷。
36.在獲取和制定軟件需求時，將快速原型開發作爲迭代計劃的一部分。
37.軟件的特性本身也導致不大可能有任何的發明創新。
38.軟件開發人員爲客戶承擔的最重要的職能不斷重複地抽取和細化產品的需求。
39.我的從業背景是程序員，樂觀主義是這個行業的職業病。
40.複雜性是我們這個行業的屬性，而且複雜性是我們主要的限制。
41.只有實際需要時，纔會用到最新的設想。
42.我們的構思本身是有缺陷的，因此總會有Bug。
43.我們圍繞成本覈算的估計技術，混淆了工作量和項目進展。人月是危險和帶有欺騙性的神話，因爲它暗示了人員數量和時間是可以相互替換的。
44.正如我們前面所看到的，實現同樣是一項高級的創造性活動。具體實現中創造和發明的機會，並不會因爲指定了外部技術說明而大爲減少，相反創造性活動會因爲規範化而得到增強，整個產品也一樣。
45.在說明完成的時候，才僱傭編程實現人員。這也正是在搭建一座建築時所採用的方法。
46.整個創造性活動包括了三個獨立的階段：體系結構、設計實現和物理實現。
47.概念的完整性要求設計必須由一個人，或者非常少數互有默契的人員來實現。
48.外部的體系結構規定實際上是增強，而不是限制實現小組的創造性。一旦他們將注意力集中在沒有人解決過的問題上，創意就開始奔涌而出。在毫無限制的實現小組中，在進行結構上的決策時，會出現大量的想法和爭議，對具體實現的關注反而會比較少。
49.實際上，產品的成本性能比很大程度上依靠實現人員，就如同易用性很大程度上依賴結構師一樣。
50.系統的概念完整性決定了其使用的容易程度。不能與系統基本概念進行整合的良好想法和特色，最好放到一邊，不予考慮。如果出現了很多非常重要但不兼容的構想，就應該拋棄原來的設計，對不同基本概念進行合併，在合併後的系統上重新開始。
51.結構師一直處在解決用戶問題，實現用戶利益的核心地位。如果要得到系統概念上的完整性，那麼必須有人控制這些概念。這實際上是一種無需任何歉意的貴族專制統治。
52.系統的結構師，如同建築的結構師一樣，是用戶的代言人。結構師的工作，是運用專業技術知識來支持用戶的真正利益，而不是維護銷售人員、製作者所鼓吹的利益。
53.對於給定級別的功能，能用最簡潔和直接的方式來指明事情的系統是最好的。
54.簡潔和直白來自概念的完整性。每個部分必須反映相同的原理需求的一致平衡。
55.由於目標是易用性，功能與理解上覆雜程度的比值纔是系統設計的最終測試標準。單是功能本身或者簡潔都無法成爲一個好的設計評判標準。
56.用戶發現尋找一個特定功能是很容易的，但相應卻有太多的選擇，要記住太多的選項和格式。
57.我主張在系統設計中，概念完整性應該是最重要的考慮因素。也就是說爲了反映一系列連貫的設計思路，寧可省略一些不規則的特性和改進，也不提倡獨立和無法整合的系統，哪怕它們其實包含着許多很好的設計。
58.他們每一個人犧牲了自己的一些創意，以獲得純粹的設計。同樣，這不僅顯示了上帝的榮耀，同時也體現了他拯救那些沉醉在自我驕傲中的人們的力量。
59.整個系統必須具備概念上的完整性，要有一個系統結構師從上至下地進行所有的設計。要使工作易於管理，必須清晰地劃分體系結構設計和實現之間的界線，系統結構師必須一絲不苟地專注於體系結構。
60.系統是一個人或者最多兩個人思考的產物，因此客觀上達到了概念的一致性。
61.對於效率和概念的完整性來說，最好由少數幹練的人員來設計和開發，而對於大型系統，則需要大量的人手，以使產品能在時間上滿足要求。
62.由一個人完成問題的分解，其他人給予他所需要的支持，以提高效率和生產力、
63.這就是小型、精幹隊伍概念上的問題：對於真正意義上的大型系統，它太慢了。
64.我常常重複這樣的一個觀點，需要協作溝通的人員數量影響着開發成本，因爲成本的主要組成部分是相互溝通和交流，以及更正溝通不當所引起的不良結果（系統調試）。這一點，也暗示系統應該由儘可能少的人員來開發。實際上，絕大多數大型編程系統的經驗顯示出，一擁而上的開發方法是高成本的、速度慢的、低效率的，開發出的是無法再概念上進行集成的產品。
65.項目的時間依賴於順序上的限制，人員的最大數量依賴於獨立子任務的數量。
66.向進度落後的項目中增加人手，只會使進度落後。
67.某項任務的計劃進度，可能受限於顧客要求的緊迫程度，但緊迫程度無法控制實際的完成情況。
68.軟件開發本質上是一項系統工作——錯綜複雜關係下的一種實踐，溝通、交流的工作量非常大，它很快會消耗新任務分解所節省下來 個人時間。從而，添加更多的人手，實際上是延長了而不是縮短了時間進度。