Tanenbaum對於構建產品，網路和生活的一些建議

原文連結

標題可能有些誤導，技術上說此文是Andrew Tanenbaum和David Wetherall關於RFC 1958的改變。此外，此文也簡化了兩位大師的思想（關於如何設計一個成功網路協議的原則）。

然而，我相信他們的思維大綱不但更具有普遍性，而且也適用於構建成功的產品，甚至包含了生活的哲理。

1.保證它能工作。不要釋出設計或者標準直到多個原型已經成功的互相互動了。有太多時候，設計者一開始寫了1000頁的標準，使它通過了稽核，然後發現它有著根深蒂固的缺陷而且不能工作。然後他們寫了1.1版本的標準。這不是一個好主意。

2.保持簡單。當你有疑惑的時候，使用最簡單的解決方案。奧卡姆在14世紀的時候提出了這條原則（奧卡姆剃刀）。用現代人的話講：如無必要，勿增實體。如果某一個特性不是最基本的，拋棄它，尤其當這個特性可以通過組合其他特性來達成的時候。

3.選擇明確。如果有多種方法能夠達成同一件事情，（只）選擇一個。有兩個或更多的方式去做同一件事情只會帶來麻煩。標準通常有多種選擇或者模式或者引數，只因為幾個有權利的組織堅持各自堅持他們的方法才是最好的。設計者應該強烈地抵制這個趨勢。果斷對多選說NO。

4.使用模組化。這個原則直接導致了協議棧思想的產生，每一層協議都獨立於其他層協議。通過這種方式，如果環境中某一個模組或者協議層發生改變，其他的部分將不會受到影響。

5.預估異構。不同的硬體，傳輸裝置和應用程式都會出現在任何一個大型的網路當中。為了處理他們，網路設計必須保持簡單，常規和靈活。

6.避免靜態選項和引數。如果某些引數是必須的且是不固定的（比如：最大網路包長度），最好的方式是讓傳送者和接收者通過協商來得到一個值，而不是預先定義幾個固定的選擇。

7.追求好的設計；不要過分苛求完美。通常，設計者們都有一個不錯的設計，但是這個設計卻不能處理一些超乎常理的特殊情況。與其對設計修修補補，設計者們應該繼續這個良好的設計，同時將擔子交給那些有超乎常理需求的人自己去處理。

8.嚴於傳送寬於接收。換句話說，傳送那些嚴格遵從標準規範的包，但是容忍那些可能不完全遵守規範的回包，並且嘗試去處理他們。

9.思考擴充套件性。如果一個系統要高效地處理數百萬主機和數十億使用者，沒有任何一箇中央集權的資料庫有能力承受的了，負載應該儘可能地均勻分佈到所有可用的裝置上。

10.考慮效能和開銷。如果一個網路的能行低下或者開銷高昂，那麼沒有人會去使用它。

去iTran樂譯參加活動，讀好文章！