很多程式設計師喜歡辯解說「盡早崩潰」是最佳實踐——在遇到問題的第一時刻報錯，報得越早越好，畢竟越接近問題發生的第一現場越方便他們除錯。這個說法本身當然是沒問題的——如果你用個預設值糊弄一下，或者是寫某種容錯邏輯來忍耐了破壞假定的行為，那麼錯誤很有可能會蔓延到之後更加遠離出問題的地方才爆發，那時丟失了源頭和上下文，查錯的成本會變得非常高。
如果只考慮程式設計師，不考慮團隊中同樣依賴每日版本來工作的策劃，美術和測試的話，這個思路是沒有問題的。然而跟程式設計師不同，當發生崩潰時，團隊內的其他成員能做的非常有限——以最快速度通知程式設計師，版本掛了 (the build is broken!!!)。如果壞的地方正好是他們工作的部分，那麼他們只好停下來，等待修好才能繼續工作。否則要麼一直備有乙個可靠的老版本 ，要麼手動回滾。
現在請摘下程式設計師的帽子，假設自己是乙個負責「測試多人副本，任務和活動」等業務邏輯相關的測試人員，每測一次都要花不少時間進入測試情境，偶爾甚至需要多人一起協同測試。那麼乙個跟你的工作毫不相關的底層崩潰，所帶來的影響就會被迅速放大，很可能得完版本後的幾個小時就在反覆嘗試和等待之中被消耗掉。
這是一種驚人的浪費。
給程式設計師巨大便利的「盡早崩潰」，對非程式設計師來說，意味著日常開發中的每一天，都要冒著被「不可控的因素」延誤工作的風險。有人說，正確的姿勢難道不是讓程式設計師有更好的自律，在提交前做盡可能充分的測試，確保不要搞破壞嗎？是的。可是即使是經驗豐富的程式設計師也不能拍胸脯保證自己 bug-free， 更不能保證由若干人提交的若干「不相干」的改動整合到一起就能無縫地良好工作。讓非程式設計師去承擔這種因為版本不成熟導致的效率折扣，是既不公平也不高效的。
說到「巨大便利」，不得補充乙個字首——「本機上的」，也就是說，只有崩潰恰好發生在製造這個問題的程式設計師的機器上 (或可以方便地即時遠端除錯) 時，這種巨大的便利性才得到體現。考慮到發生在非程式設計師環境下的崩潰，不少情況下是由於環境配置錯誤等雜音所致，「有經驗的」程式設計師往往不會浪費他們「寶貴的開發時間」，第一時間趕往現場開始分析和除錯（打斷自己的工作跑去協助除錯，滿頭大汗弄了半天，發現是環境配置的問題/版本問題/別人**導致的問題，足以喚醒乙個溫順的程式猿內心的洪荒之力了）。更多的，他們會在 im 上回個訊息：「嗯，這個功能我提交前測試是正常的——你的環境乾淨嗎？需要的資料都乾淨地重新生成了嗎？第三方庫的二進位制檔案更新了嗎？你們幾個人測試的版本一致嗎？要不你 cleanup / 重啟 / 重新儲存 / 重新建個賬號試試？」，試圖通過盡可能小的時間開銷來幫助診斷和解決問題。長遠來看，這些試圖節省除錯時間的溝通，會讓「盡早崩潰」所帶來的巨大便利慢慢地揮發殆盡。
乙個不那麼容易覺察卻更為嚴重的系統性問題是，總是採用「盡早崩潰」的實踐的團隊所產出的**庫，隨著系統內不同模組之間的互動（以及隨之而來的各種假定）越來越多，往往傾向於通過更多的斷言來讓系統變得越來越敏感和脆弱。因為，認真細緻地考慮模組間的依賴時序，並系統性地從結構上解決過深的模組間耦合，總是比乙個簡單的斷言要複雜得多。
「盡早崩潰」的主張是如此的簡潔有力，以至於我們在那些應當通過改良結構，去除耦合來解決問題的時刻，往往簡單地選擇了使用斷言來做乙個時序上的約定。這種顯式的指定會把系統的壞氣味轉化成太多的不必要依賴。的確，問題從表面上看起來變得更簡單了——誰破壞了斷言，導致了崩潰，誰就修唄——實質上，修來修去，把乙個本質上可以剝離的簡單互動，變成了嚴重依賴各種時序和條件的「靠巧合工作」的雜耍系統。
你看，「盡早崩潰」的簡單性和便利性，在一些情況下反而成了乙個讓**質量退化，鼓勵系統熵不斷增加的問題機制。那麼問題來了，在滿足了「必要的時候程式應當盡早崩潰」的基礎上，還有什麼可以選擇的實踐嗎？
黎克特制替換原則在現實中的應用
我記得在之前xx大型的網際網路公司，該公司只能算是很偽的網際網路公司，以業務為主，非技術指導的公司，所以裡面的寫業務的人員水平也是參差不齊，在不停地重構，沒過多久又會發現 的維護難度在增加，然後又是重構，出現了惡性迴圈。每次來了新需求，都會頭疼得緊，擔心需求的改變會對上乙個版本有很大的衝擊。今天來介...
設計原則在手機攝影中的運用
為了給在校的最後一年留下紀念，最近我總是拿著手機溜達到校園的角落拍照。手機拍照很容易分享。我漸漸發現，那些最受朋友喜愛的 無意識中符合了某些設計原則。這些原則交錯遊走，不斷遵循和打破，最終定格成下面的一張張 如果說藝術是對生活的提煉，那麼攝影就是對視覺的提煉。所謂的 提煉 就是從日常看到的東西中做減...
開放封閉原則在OC中的實現辦法
開放封閉原則就是在開發過程中開發實體 類，模組，函式等 應該可以擴充套件，但是不能修改。是物件導向的核心設計所在。要容易維護又不容易出問題，就要多擴充套件，少修改。俗話說磨刀不誤砍柴工，在設計的時候可以先猜測最有可能發生變化的地方 可能頻繁發生變化的地方 然後建立抽象來隔離變化。這需要我們在專案中多...