權衡的藝術
hoping翻譯
來自：www.pragmaticprogrammer.com
你是怎樣開發軟體的？
在那些以編寫軟體為生的人們之間有乙個常見的爭執。有些人堅持認為在編寫**前必須先要有乙個完整的模型，那些過早進行編碼的人只不過是一些「在地獄中編碼」的
hacker
。然後，就會有另外一群人說，嗨！等一下。你無法從乙個簡單的預先模型中學到足夠的知識。你必須得編寫某些形式的**。否則，你很可能會遺漏掉一些重要細節，甚至建立出乙個無法構建的模型。
正確答案
那麼哪一方正確呢？是整天侵淫在**之中的那一方呢？還是堅持在思考**前必須先完整地建立對世界感知的模型那一方呢？
嗯，他們在某種程度上都是正確的。至少，他們在試**決同樣的問題－－獲取正確實現乙個系統的足夠知識。
請注意，軟體專案和其他工程學科中的專案不同。軟體專案在本質上是以發現為中心的專案。隨著時間的過去，你和你的團隊會學到更多的知識。你對客戶、應用、環境以及發起者的認識也會隨著專案的進展而增加。
你必須得做好適應新發現的知識的準備。典型的瀑布方法的錯誤就在於根本沒有任何反饋。在瀑布模型中，低層編碼中的任何發現根本無法影響到需求和架構。然而，這些低層細節對於理解更高層的東西來說常常具有深遠的影響。
降低風險
降低風險是傳統工程的核心。當建造一座橋梁時，你不會考慮把它建造成一座永遠不會倒塌的完美橋梁。相反，你只會考慮它能經受
500年的風吹、
200年的水淹、最大
3倍於所期望的承重，等等。如果不做這些設計權衡，那麼所有的橋梁都將是從橋面到地面的實心混凝土，都將有
500英呎寬。工程的全部就是做這些折中，軟體工程也是如此。
軟體工程的困難在於：大部分的風險都存在於構建它的過程以及所完成的結構之中。原因就是其發現的本質。
知道了要在前進中不斷地進行發現，那麼問題的核心就在於要使所發現的東西使你已完成工作失效的風險最小化。
那些直接去拼湊產品**的人在開始之前就已經陷入麻煩之中：（由增加的知識所導致的）方向上大的變化此時更改起來最為困難，也最為昂貴。
那些建議在做任何實現之前要先建立完整模型的人，同樣也冒著在建立產品**期間會出現重要發現的風險。作為現實抽象版本的模型，必然會失去一些細節。而惡魔很可能就潛伏在這些細節之中。
於是，就有一些人試圖在這兩個極端之間進行平衡，他們建立一點模型，就進行一些編碼，他們使用一次性的原型或者**曳光彈進行建模。
usenet
中許多關於這個主題的討論都集中在是寬度優先還是深度優先；何時建模以及何時編碼等細節之上。針對這個問題，不同的方法會給出不同的建議。
方法就是我們自己
極限程式設計是基於降低風險的前提之上，當今所有其他流行設計方法在某種程度上亦是如此――不管它們是否承認這一點。
已公開的方法都在試圖回答下面問題：「為了建立乙個軟體系統，我和我的團隊如何才能以最為經濟的方法獲取最多的問題領域和解決方案領域知識。」
很明顯，風險固有地存在於專案的發現過程之中。然而，該發現是一直在進行的，我們無法承受遊戲後期的重大發現。在理想情況下，我們希望能夠預先發現我們希望知道的一切，並且完全理解它們。現實肯定不會是這樣的，所以每個方法都試圖建立出乙個環境，在其中你能夠盡可能早地做出最重要的發現。乙個特定方法最有價值之處就在於它是如何降低在晚期出現的關鍵發現的風險的。
不過，這些答案對每個人來說都是不同的。答案和你的團隊、專案、經驗、問題領域、工作環境等相關。如果你曾經發現乙個方法很適合於乙個專案，誰也無法保證它會適合於下乙個專案。如果所列出的這些因素中的任何乙個發生變化，很可能就要對過程進行修訂。
它並不完美
你已經看到，和演算法或者堅固的機器指令序列的質樸之美不同，它並不完美。過程和方法依賴於人去維持它們，去理解將被檢查的要素。而人是很容易犯錯誤的。
所以在最後，我們再回到對管理權衡的想法。你可以在乙個專案的物件模型上浪費
6個月的時間，結果在實現期間卻發現你錯誤的理解了客戶的效能需求。你可以很早就開始實現，把自己鎖定在乙個無法支援一些你還不知道的重要需求的設計和架構上。
或者，你可以對權衡進行評估以最小化總的風險，接著分析一點、設計一點、編碼一點。每個任務所佔的相對比例、順序、反饋的數量――所有這些對每個專案、每個實踐者都是不同的。不存在在任何時間、任何場合都正確的答案。所以，一定要注重實效，作出最適合當前問題、當前團隊、當前環境的選擇。
所以，當你下次進行計算機是工程實踐還是藝術的討論時，請考慮一下權衡的藝術。其他的工程學科必須要建立在和物理世界有關的權衡之上；我們必須要面對和我們自己相關的權衡。
然後我們就可以開始開發軟體了。
軟體的藝術之美源於權衡（Trade off）
1 time or space 時間 vs.空間 犧牲記憶體換取時間或犧牲時間以節省記憶體是我們常用的伎倆。2 elegancy or efficiency 優雅 vs.效率 比如，多型很優雅，卻是以效率為代價，而醜陋的函式指標卻正好相反。3 fashion or familiarity 不熟悉的新...
「權衡」的來歷
我給你說說這秤上的學問。這秤桿，叫權，這秤砣，叫衡，權衡一詞就是打這來的。手拿這桿秤，要懂得權衡之道 用秤之道。你看，這秤上這些小星，叫定盤星，也叫準星。這桿秤上，十六錢等於一兩，十六兩等於一斤。這秤上為什麼要用十六進製呢？這是老祖上 古聖人給定的。十六進製制，十六顆準星。這七顆星，表示北斗七星，告...
偏差 方差權衡
偏差度量了學習演算法的期望 與真實結果的偏離程度，刻畫了學習演算法本身的擬合能力。方差度量了同樣大小的訓練集的變動所導致的學習效能的變化，刻畫了資料擾動所造成的影響。雜訊表達了當前任務上任何學習演算法所能達到的期望泛化誤差的下界，也就是最小值。泛化誤差可以分解為偏差 方差和雜訊之和。一般來說，偏差和...