在軟體工程領域有乙個長期的著名討論，其標題為「 越糟越好 」。 我從來沒有拿過我的兩分錢，所以我想在這裡再談一點。 這也是嘗試根據我在microsoft進行軟體開發的經驗應用這種觀點的機會。
此討論最初是由richard gabriel提出的。 他將兩種不同的方法稱為「 mit」方法與「 new jersey」方法。 這些標籤來自麻省理工學院的common lisp和scheme組採用的方法，以及紐澤西州的貝爾實驗室採用的相反的unix方法。 我發現討論特別有趣，因為我在bell labs進行了4個實習，同時在mit獲得了學士和碩士學位。 因此，我設法跨越了兩種思想流派。 當然，在某種意義上，unix本身是對ken thompson和dennis ritchie在與mit合作進行multics專案時所接觸到的「 mit方法」的反擊（我父親帶領bell labs團隊與mit一起在multics和隨後管理了開發unix的bell labs研究小組，因此我在兩個陣營中都有其他根基。
對於mit方法，本質是「正確的事情」。 設計人員必須正確地具備以下特徵。 釋義：
紐澤西州或「越差越好」的方法稍有不同。 釋義：
加布里埃爾（gabriel）將他對紐澤西州方法的描述視為諷刺畫。 顯然，這是乙個較差的設計策略。 那為什麼更好呢？ 他認為它「更好」，因為它顯然是獲勝的-lisp系統在mit / stanford社群之外的早期興起並不順利。 隨著大量微型計算機和工作站的興起，unix易於在這些計算機上啟動和執行-它效能卓越，簡單易用，並且在快速發展的硬體環境中生存良好。 lisp機器是經過高度調整的硬體/軟體系統，無法隨著快速變化的硬體和技術環境而發展。
這些方法之間的主要差異之一顯然是對實現簡單性的關注。 在紐澤西州的方法中，這最終勝過一切-甚至是正確性！ 這有許多後果。
其結果之一就是一種趨勢，即從建造「完美的寶石」轉向建造和使用某種東西。 顯然，這與所有各種軟體方法都一致，其指導方針集中於實際使用的速度和驅動反饋過程（「提早並經常發貨」或「最小可行產品」）。
該方法還使開發人員能夠「在本地實用」-願意在複雜性上進行權衡，而不是被迫過度投資於最終無法提供成本價值的系統特性。 當然，錯誤地解釋或錯誤地使用「一定不能過分不一致」是有失敗的餘地的–這不是反覆無常的設計的論據。 而「本地實用」和「懶惰」則是連續的。
我將圍繞滲漏的抽象 ， 意外的複雜性和總體可訪問性將另一組問題歸為一類 。 在內部複雜性很高的系統中，不可避免地存在這種複雜性以意外方式洩漏的風險。 常見的洩漏是效能不一致-使用api的某些方法快速且可**，而其他方法導致不可**的效能後果（在最壞的情況下，將可**的本地計算轉換為涉及無限制的遠端通訊的結果）-是的，是執行此操作的使用率很高的microsoft api）。
我對windows presentation foundation的設計存在的問題之一是，它們在如何應用用於構建使用者介面的視覺化轉換和動畫方面提供了強大的功能和靈活性，但是在gpu / cpu通訊和記憶體頻寬以及有些非常昂貴。 在不了解實現細節的情況下，很容易濫用系統並產生無法很好擴充套件的結果（跨資料集大小或具有不同效能特徵的裝置）。 在這種情況下，系統提供了「人為的一致性」，即api看起來是一致的，但實際上卻不是。
討論的原始**提供了效能不一致的另乙個示例。 高度調整的系統在應對快速變化的技術前景時通常會遇到挑戰。 真正利用快速改進的硬體來改變有關系統不同部分應該如何互動的重要假設的難度更大。 實際上，這種無法適應的問題既是業務問題，也是技術問題。 如果要適應不斷變化的硬體環境的成本很高，則業務案例必須非常強大才能保證投資。 適應失敗通常是技術和業務成本/收益因素混合造成的結果。
偶然的複雜性是由於複雜實現的特徵通過介面洩漏而發生的，客戶端應用程式和整個端到端系統隨後變得依賴於這些特徵，這使得系統難以發展。 從直觀上看，顯而易見，內部實現越複雜，防止這種複雜性洩漏的難度就越大（並且許多示例可以證明這些直覺）。
平易近人的特性似乎並不那麼明顯。 追求一致性和完整性的系統/ api難道不是更平易近人嗎？ 我使用unix多年的經驗是，它並不能完全發揮作用。 我讀過asp.net和php的比較，這一點引起了我的強烈共鳴（對不起，無法找到參考文獻）。 它談到讀一本書像「專業asp.net」手動和離家以後的感覺：「哇，這些傢伙的方式比我聰明」。 相比之下，您閱讀了「 php程式設計」，並且所揭示的每個步驟和新功能似乎都是合理且可以理解的—您了解自己可能是如何構建它的，但很感謝他們將其包含在系統中。 顯然，這不是這兩個截然不同的系統的整體比較，而是與內部複雜性如何在可接近性的重要特徵中發揮作用有關。
nodejs的成功是另乙個例子，可接近性最終對最終成功產生重大影響。
對完整性的關注可能特別有害，特別是因為它引入了圍繞簡單性的張力。 完整性和一致性都會導致功能集大小n的增加，這會導致內部複雜度的增加（功能相互作用，因此複雜度的增長遠快於功能集大小的線性增長）。 這種內部複雜性使元件或系統更難隨時間適應外部變化。 一致性的目標通常可以促使人們採用重要的內部機制，尤其是當元件將可能具有自身不一致之處的其他元素分層時。 實際上，對於元件構建者而言，這種對基礎不一致的記錄本身就是所提供的功能。 不幸的是，這種一致性幾乎總是伴隨著效能開銷和權衡決策，而這些決策現在已經從元件的任何使用者手中奪走了。 當沿著這條道路前進時，端到端的論點通常會非常謹慎。
翻譯自:
我的0 02美元的價格更優惠嗎？
在軟體工程領域有乙個長期的著名討論，其標題為 越糟越好 我從來沒有拿過我的兩分錢，所以我想在這裡再談一點。這也是嘗試根據我在microsoft進行軟體開發的經驗應用這種觀點的機會。此討論最初是由richard gabriel提出的。他將兩種不同的方法稱為 mit 方法與 new jersey 方法。...
將應用從5美元的價格降到1美元，我得到一樣的收入
這位名叫oliver reichenstein的移動應用開發者是個非常有心的人。為了證明收入與 的關係，他對他非常暢銷的寫字應用ia writer進行了調價實驗。以下是他發布在自己google 賬戶內的文章 我們最近一直在實驗應用的 一遍又一遍的我們得到了乙個非常有趣的現象 不論我們給應用的 定到多...
js 同步ajax在IE上會產生頁面假死的問題
一 問題的起因 今天做乙個需求遇到了這麼個情況，就是使用者個人中心有個功能，點選按鈕，可以重新整理使用者當前的積分，這個肯定需要使用到ajax的同步請求了，當時喀喀喀三下五除二寫玩了，大概 如下 非同步當前使用者積分 by zgw 20161216 return description functi...