簡單是架構設計的第一原理，值得我們認真思考
什麼是簡單，簡單是指解決問題的最短路徑。比如我們要從從a點出發到達到b點，直線是最短的距離。相同交通工具下，直線距離可以更快到達。
複雜的定義和簡單是相對的，複雜就是解決同樣的問題，花費了更多的成本，並且沒有得到明顯的收益。比如還是從a點出發到b點，我們不走直線，走一些彎路（紅色路線），很明顯路途變遠了，相對於直線，需要更多的時間。如下圖所示：
如果問題的場景發生了變化，簡單的方案未必能解決問題，最簡單的方案會變為不可行方案。原來相對複雜的方案會變為當下最簡單的方案。比如上圖中如果有一天在a和b之間直線路徑上出現了山體滑坡，造成原來的道路不通。那麼原來的彎道（紅色路線）已經變為最簡單從a點到b點的最簡單解決方案。我們考慮解決方案的簡單性，必須要考慮可行性。
方案不僅僅要簡單可行，要真正解決使用者的痛點，這才是我們選擇方案最核心的思考。還是同樣的問題，如果使用者的需求不是從a點盡快到達b點，而是從a到到b點旅行，在a點到b點眾多的可行路線中，哪個才是適合使用者的呢？
這時候要分析出使用者真正想要的，比如使用者想賞花，賞花就是收益。使用者時間有限，時間就是成本。使用者金錢有限，金錢就是成本。如果使用者就是想打發時間，那麼時間可能並不是主要成本，甚至是受益。
要根據具體場景，分析使用者的成本與收益的權重，找出滿足使用者需求的最小成本路徑。
如果使用者金錢有限，想用盡量少的錢，買到到更多功能的產品。解決方案就是選擇高價效比的方案，比如優衣庫的思路，都是基本款，讓使用者可以花費最少的錢，得到產品最重要的體驗。
如果使用者非常有錢，想達到最完美產品體驗，不在乎付出多少金錢。那麼是奢侈品方案，願意為了提公升體驗，花費比正常商品高達上百倍，甚至更高的**。
分析：錢不是成本，完美的產品是收益，真正的成本是時間。
在我們選擇技術方案的時候，應該盡量通過簡單的方案來達到目的。技術本身並無優劣之分，沒有萬能的方案，每個方案都有它適合的場景。關鍵是要識別當前問題中的痛點，尋找可以解決當前痛點方案，並進行成本與收益，以及簡單與複雜的權衡。
第二步：尋找可行方案列表。列出所有的方案列表，甚至不用關心是否可行。
第三步：篩選去除不可行方案。要注意今天不可行的方案，未來可能成為可行方案。
第四步：選出最優可行方案。1.權衡方案的成本與收益。2.權衡方案的複雜度，複雜方案意味著風險和潛在成本（比如維護成本）。
比如我經常接老婆下班，原來我們每次臨時溝通接人位置，然後尋找彼此，結果發現根本找不到對方。原因是彼此認知不同：乙個人知道道路正確的名稱，另乙個人記錯了道路名稱；乙個人能分辨出方向，另乙個人使用了錯誤的方向；乙個人說的是這個橋，另乙個人認為是另外一條路上的橋。不管一方表達多麼精確，依然無法找到另一方，兩個人用的不是同乙個概念描述。所以這個方案是複雜的，沒有辦法提前對描述可能用到的概念進行一致性約定，帶來了巨大的潛在溝通風險。
改進：我和老婆一起，選擇了個相對好接的位置，告訴老婆以後就在這裡接你。以後接老婆，我只需要說，老位置見，保證不會接錯。雖然選擇的位置不一定是每次最優選擇，但避免了溝通巨大的風險，每次都很簡單和省心。
這個簡化方案的原理其實是「約定大於配置」，不用每次約定，大家只要遵守提前訂好的規約。在程式設計中，經常會使用「約定大於配置」，比如程式的源**目錄結構，約定好src下的是主程式原始碼，test下的是測試程式原始碼，編譯的時候不用告訴編譯器，編譯器按照約定執行test目錄下的測試用例，並把src下的源**編譯為執行程式。
質量的相對性
質量的相對性 在上面的故事中，我之所以會陷入兩難的境地，可以通過質量的相對性來加以解釋。這個關於minicozy 公司的故事清楚地告訴我們 某個使用者認為是質量完全過關的某個軟體產品，另一位使用者可能會認為質量不完全過關。發現相對性 由於軟體的質量，有過種種定義。只要考察一下這些定義，您就會發現上面...
價格的相對性研究
首先我們看乙個概念 消費者其實並不知道什麼東西該值多少錢，他們茫然穿過貨架，根據種種線索判斷 任意連貫性首先是一種相對理論，買家的主要敏感點是相對差異，而非絕對 可能我們對上述概念是理解的，但是在日常生活中並沒有認為他是問題。比如 四季寶 花生醬最近重新設計了包裝的塑料罐。以前是的罐子底部是平的，諮...
正則入門 邊界的定義與相對性
講了這麼多，還漏掉了乙個重要的內容 究竟什麼才算邊界？通常情況下，以 空格 段落首行 段落末尾 逗號 句號 等符號作為邊界，值得注意的是，分隔符 也可以作為邊界。正則如下 bmagic b效果演示 welcome to nowa magic this magic place 本例 function ...