欲求更好，常把好事變糟。——李爾王 1.4
有乙個（有點）老的笑話，說一家美國公司向一家日本製造商訂購100 000片積體電路。規格說明中有次品率：10 000片中只能有1片。幾周過後訂貨到了：乙個大盒子，裡面裝有數千片ic，還有乙個小盒子，裡面只裝有10片ic。在小盒子上有乙個標籤，上面寫著：「這些是次品」。
要是我們真的能這樣控制質量就好了。但現實世界不會讓我們製作出十分完美的產品，特別是不會有無錯的軟體。時間、技術和急躁都在合謀反對我們。
但是，這並不一定就讓人氣餒。如ed yourdon發表在ieee software上的一篇文章[you95]所描述的，你可以訓練你自己，編寫出足夠好的軟體——對你的使用者、對未來的維護者、對你自己內心的安寧來說足夠好。你會發現，你變得更多產，而你的使用者也會更加高興。你也許還會發現，因為「孵化期」更短，你的程式實際上更好了。
在繼續前進之前，我們需要對我們將要說的話進行限定。短語「足夠好」並非意味著不整潔或製作糟糕的**。所有系統都必須滿足其使用者的需求，才能取得成功。我們只是在宣揚，應該給使用者以機會，讓他們參與決定你所製作的東西何時已足夠好。
讓你的使用者參與權衡
通常你是為別人編寫軟體。你常常需要記得從他們那裡獲取需求[2]。但你是否常問他們，他們想要他們的軟體有多好？有時候選擇並不存在。如果你的工作物件是心臟起搏器、太空梭、或是將被廣泛傳播的底層庫，需求就會更苛刻，你的選擇就更有限。但是，如果你的工作物件是全新的產品，你就會有不同的約束。市場人員有需要信守的承諾，終端使用者也許已基於交付時間表制定了各種計畫，而你的公司肯定有現金流方面的約束。無視這些使用者的需求，一味地給程式增加新特性，或是一次又一次潤飾**，這不是有職業素養的做法。我們不是在提倡慌張：許諾不可能兌現的時間標度（time scale），為趕上最後期限而削減基本的工程內容，這些同樣不是有職業素養的做法。
你所製作的系統的範圍和質量應該作為系統需求的一部分規定下來。
make quality a requirements issue
使質量成為需求問題
你常常會處在須要進行權衡的情形中。讓人驚奇的是，許多使用者寧願在今天用上有一些「毛邊」的軟體，也不願等待一年後的多**版本。許多預算吃緊的it部門都會同意這樣的說法。今天的了不起的軟體常常比明天的完美軟體更可取。如果你給使用者某樣東西，讓他們及早使用，他們的反饋常常會把你引向更好的最終解決方案（參見曳光彈，48頁）。
知道何時止步
在某些方面，程式設計就像是繪畫。你從空白的畫布和某些基本原材料開始，通過知識、藝術和技藝的結合去確定用前者做些什麼。你勾畫出全景，繪製背景，然後填入各種細節。你不時後退一步，用批判的眼光觀察你的作品。常常，你會扔掉畫布，重新再來。
但藝術家們會告訴你，如果你不懂得應何時止步，所有的辛苦勞作就會遭到毀壞。如果你一層又一層、細節復細節地疊加，繪畫就會迷失在繪製之中。
不要因為過度修飾和過於求精而毀損完好的程式。繼續前進，讓你的**憑著自己的質量站立一會兒。它也許不完美，但不用擔心：它不可能完美
程式設計師修煉之道
在所有的弱點中，最大的弱點就是害怕自己暴露弱點。j.b bossuet,politics from holy writ,1709 provide options,don t make lame excuses 提供各種選擇，不要找蹩腳的藉口 don t live with broken window...
程式設計師修煉之道
身為一名程式設計師，當一本叫做 程式設計師修煉之道 的書出現在面前，又怎能忍住不去看呢？於是，出現了下邊的讀書筆記。該書確實博大精深，包含了很多內容，但很多都是點到為止。那種心中有劍的感覺，躍然紙上，或許高手都是如此吧。根據多年武俠觀摩經驗，一定要把不懂的記下來，以後肯定大有用處。那就記。第一章 注...
程式設計師修煉之道
1 通過自己工作上的不斷努力，成為公司的骨幹員工，構建自己的不可替代性。2 學院派講究的是把簡單問題複雜化，實戰派講究的是把複雜問題簡單化，模組化。3 c語言，資料結構與演算法，編譯原理。4 修煉程式的內功，是學習抽象能力和描述能力，與語言無關。5 獲得智力資本，從而為自己的資產提供最佳的方式 摘自...