作者在twitter上發的一條短訊：
「你永遠都有簡化的空間。」
11:29 am – 2012-5-21
rich skrenta在「code is our enemy」（**是我們的敵人）一文中是這麼說的:
**不是什麼好東西。**會隨著時間的推移慢慢腐爛。**需要週期性的維護。**裡還藏有bug。新增功能意味著舊的**需要被修改。你的**越多，bug能藏身的地方就越多，遷出（check out）或者編譯的時間也就越長，新員工理解你的系統所需要的時間也就越長。如果你不得不進行**重構，那麼你需要調整的地方還有更多。
**是工程師製造出來的。如果要寫更多的**，那就需要更多的工程師。眾多任務程師之間有n2的溝通成本。他們在擴充套件功能時加進系統的所有**，也將增加整個系統的成本。你應該盡一切可能去提高每個程式設計師在**表現力方面的能力，以使用更少的**來完成同樣的事情（甚至可能做得更好）。你雇用的程式設計師越少，組織溝通成本也就越低。
rich在這裡給出了一些線索，但是真正的問題不在**。**就像乙個新生嬰兒，在被帶到這個世界來的時候，它是無辜而無可非議的。**不是我們的敵人。你想看看真正的敵人嗎？去照一照鏡子吧。那裡就是「你」的問題。就在那裡！
作為乙個軟體開發者，你就是你自己最大的敵人。你越早認識到這點，你的境況就會越好。
我知道你抱有極大的善意。大家都一樣。我們是軟體開發者；我們熱愛編碼。那就是我們每天的工作。給我們一些強力膠帶、乙個簡易衣架，再加上一小撮**，我們總能解決任何問題。但是，will shipley卻認為，我們應該控制住這種寫上一大堆**的自然傾向：
作為程式設計師，我們的任務是要意識到，我們所做的每個決定都是乙個折中——這就是編碼的本質。要想成為程式設計大師，那就要理解這些折中的本質，並且在我們編寫的任何**中都善加處置。
在編碼過程中，你可以從很多維度去評價你的**：
記住，這些維度相互之間都是對立的。你可以花上3天時間寫乙個非常美觀而迅捷的程式，這樣你在兩個維度上獲得了提高，但是因為你花了3天的時間，所以在「編碼所花費的時間」這個維度上就落後了很多。
那麼，在什麼時候這樣做才是值得的呢？我們該如何做這些決定呢？其實，答案非常合乎情理，也很簡單，但就是從來沒有人好好遵從：從簡潔開始，然後依據測試的結果按需提公升其他的維度。
對此我非常贊同！我曾在「code smaller」一文中勸誡開發者們編寫更小的**。我給出的建議其實異曲同工。但不要走極端！我並不想挑起一場「reductio ad absurdum」競賽：我們用盡書上所有的聰明技巧，讓**能夠塞進更小的物理空間。我想要的是乙個實用而明智的策略，以縮減乙個程式設計師在想要了解程式的工作原理時所須閱讀的**量。我這裡有個很小的例子，以進一步說明我想表達的意思：
譯者注：
reductioad absurdum
意指反證法，是拉丁語中的
「轉化為不可能
」。反證法（又稱歸謬法、背理法）是一種論證方式，它首先假設某命題不成立（即在原命題的條件下，結論不成立），然後推理出明顯矛盾的結果，從而下結論說原假設不成立，原命題得證。if（
s==string.empty）if
（s==」」
）對我而言，後面的那個顯然更好一些，因為它更為簡潔。然而，我幾乎可以斷定，一定會有開發人員跳出來與我爭辯，可能還要「血戰到底」，因為他們深信這個囉嗦的string.empty對編譯器來說更為友好（真是莫名其妙！）。說得我好像在乎這個一樣。好像真有人在乎這個一樣！
對於絕大多數軟體開發者而言，承認這個事實是很痛苦的，因為他們是那麼地熱愛**。但是，最好的**就是完全沒有**（所謂「大道至簡」）。每一行你欣然帶到這個世界來的新**都需要被除錯，需要被其他開發者閱讀和理解，並且被維護和支援。每當你需要新寫**的時候，你都應該很不情願、但又迫不得已，因為你已經證明其他所有的方法都無濟於事。之所以有人說「**是我們的敵人」，正是因為我們當中的很多程式設計師寫了太多太多的糟糕**。然而，如果你不得不寫**，你也須從簡潔開始。
如果你熱愛編碼——而且愛得情真意切——那你就應該惜墨如金。
看了《大道至簡》
無意間在網上翻到這本書，粗粗的看了一遍，有點感觸。可以研究細節，但不能陷入，可以一時陷入，但不能一世陷入。當然，這對技術狂熱者或許是除外的。如果要解決問題，那麼無論何種程式語言，都是一種工具，要做的是對於當前的問題選擇適合的工具。任何一種工具都是在某個情境下才可以區分孰優孰劣。中國的一些理論，很少放...
讀大道至簡
軟體開發 方法 過程 工程 組織 演算法 結構 方法 面向過程 物件導向 過程 瀑布模型 迭代模型 工程 專案管理 進度 成本 質量 組織 體制 組織結構和制度 是乙個向外擴充套件的過程。方法 分，模組化設計 過程 增量迭代，還是瀑布模型 工程 進度 成本 質量 組織 組織結構 制度 舉乙個做生意的...
大道至簡Segment Routing
聽了一下思科服務支援社群的講座，以下為筆記 1.基礎知識 1 igp基礎 ospf和中間到中間系統協議 2 bgp基礎 3 mpls 多協議標籤交換 2.模擬器為ios xrv 6.0.1 3.sr架構基於源路由。節點擊擇路徑，並且引導資料報沿著該路徑通過網路，做法是在資料報頭中插入帶順序的段列表，...