你已經毀了JavaScript

　　（注* 之前我們比較過Angular.JS和Backbone, 作者以AngularJS為例，表明了他對JS領域過度使用設計模式的焦躁，言辭激烈，引起廣泛討論） 

　　以前

　　過去我們在頁面上用很時尚的方式寫了一些確實很可怕的程式碼，它給我們帶來了巨大的麻煩。可能很多人現在還在這樣做，但他們不會看這篇博文，我們可以假裝他們不存在。

　　JS的偉大/了不起/讓人驚訝的地方在於沒有人想走近它，而且在那些有組織的大型企業中，他們只想呆在他們自己的小世界裡，由各種抽象層和XML注入的框架中。

　　這對於像我這樣想要靠這些企業養活，但卻不想忍受那由N多層次組成的可怕的“最佳實踐”（而且他們會由於擔心效能問題不想讓非DBA的人動資料庫）來說，這非常棒。

　　更好的是，當這些效能問題出現時，通過寫一段前端JS程式碼，我們可以轉危為安。我們可以假裝這些效能問題不存在，儘管後臺程式碼很爛但能給使用者一個好的體驗。

　　JS已經發展到頂峰

　　當jQuery出現，這是更好的事。它能將可重複使用的jQuery外掛緊密地連線在一起。當NPM面世，我們開始用一種半自動的模組系統來管理這些自包含的小部件，我們最終到達JS的頂峰了。

　　由於這些小模組及其組合都是有獨立功能和小部件，我設想著一個我能用良好的程式碼庫，和出色的優秀的UI團隊一起工作的未來。也許我們能從這些企業級的Bean, Orm，各種抽象工廠、方法、模式中，慢慢地奪回程式碼庫的控制權。

　　我們有一些更有意義的事情需要做，寫優秀的程式碼和構建優秀的框架，並能使我們從繁重的企業框架中解脫出去。

　　你毀了它

　　現在，我依然在用JS，但最近我主要還是在用Erlang，建立視訊流/編碼系統等等，現在我還沒有把他們寫成部落格，但基本上我的後臺很性感，我的前臺也很性感（facebook的React+NPM填補了空白）。我在Stackoverflow上發現的一些東西，讓所有以前苦難日子又重現了，讓我驚恐的是，它像性病一樣在前端傳播，連結在這：

　　Angular.js: Server vs Provider vs Factory？

　　好吧，還不算太糟，但讓我們來看看投票率最高的答案（好吧，本文發表時就已經不是了）同時觀察下它，很顯然還是有一些非常滿意的使用者的：

噢！多謝詳細的講解。你把它變得很容易，讓人易於理解。好樣的！！

　　如果我善良的話，我會說這個評論是諷刺的，且整件事就是"Pow 法則"很好的一個例子，但看完整個評論我覺得事情並不是這樣的，我沒有為此皺眉。

　　因此，我們看到的第一件事是奇怪的Angular文件的引證，如下面這樣：

Angular“服務”是由“服務工廠”建立的一個單例物件。這些服務工廠是函式，反過來，他們也是由“服務提供者”建立的。“這些服務提供者是建構函式”。當例項化時，他們必須包含一個叫$get的屬性，它是服務工廠函式的關鍵。

　　這TM到底是幹什麼玩竟兒？我是這樣理解的“為了寫了Hello World程式，你必須首先建立一個hello world服務來建立hello world工廠來建立hello world應用，這樣你就可以在螢幕上輸出hello world了”。

什麼？？我是在讀論文嗎？這玩意兒真讓人凌亂。

　　不，你不是在閱讀論文，顯然你在閱讀angular文件。

　　如果這是一篇論文，那麼它會試著陳述一些問題的解決方案，而不是給編造出來的問題編造答案（實際上，這不太正確，因為學者們都活在他們的世界裡）。

　　可能大多數建立Angular的情景都是編造的，因為這是我們竟會在前面需要所有這些工廠，代理，服務的唯一原因。這些我們將要使用的程式碼和說明都來自於幻境，且讓人難以相信，這居然不是一個玩笑。

服務，工廠，提供者可以是相同的。

　　什麼？這當然不可以，他們僅僅只是有返回值的函式，讓我們繼續跟隨這瘋狂的文件來看看它會發展成什麼樣。

　　作為前提，我們得到了一個“汽車例項化”的例子。

通過服務（單例的），你不能實現它，因為不允許被例項化。

　　為了證明提供者的存在，因為

要例項化，你需要工廠(Factory)或提供者(provider)。

　　不！天哪，這什麼玩意兒。

var car = new Car({ cylinders: 4 })

　　奇怪的“new”關鍵詞。我們在企業級應用中一直在重複這個引數，看到它又出來了，這真的羞辱了我。

Provider能幫你配置應用程式

　　當然，如果我們需要配置應用程式時，我們可以通過(Provider)配置。但我們怎麼配置那些配置應用程式的配置程式呢？

　　我喜歡下面的程式碼，它幾乎在重複它自己。它甚至不需要評註就就已經很搞笑了。

app.service('CarService', function () {
    this.dealer = "Bad";
    this.numCylinder = 4;
});
 
app.factory('CarFactory', function () {
    return function (numCylinder) {
        this.dealer = "Bad";
        this.numCylinder = numCylinder
    };
});
 
app.provider('CarProvider', function () {
    this.dealerName = 'Bad';
    this.$get = function () {
        return function (numCylinder) {
            this.numCylinder = numCylinder;
            this.dealer = this.dealerName;
        }
    };
    this.setDealerName = function (str) {
        this.dealerName = str;
    }
});

　　為了配置它，我們要做的就是

app.config(function (CarProviderProvider) {
    CarProviderProvider.setDealerName('Good');
});

　　Hey,這只是一個配置而已——不需要改變任何程式碼！！

　　我寧願寫一段相同的原生JS來充實自己，上面的例子簡直讓我想找個地洞鑽，拿頭撞牆。

　　這兒有個小竅門。如果你發現你自己也問同樣的問題。如果你發現自己問一個像這樣答案的問題，然後此類問題會被問道你已經做錯了。

　　做錯這個本來沒有什麼羞恥的，這沒問題——我們都會犯錯，但是給出當前這個扯淡的軌跡，我們已經遠離我們之前的想法了，我們會成為Angular的顧問，且給我們的學生去上Angular昂貴的培訓班。很好——你愛上它了。

　　你們怎麼回事？

　　我們有美好的東西，你們毀了它。我們有荒唐企業版的出路的，且你不是去學習如何玩弄程式碼，你只需要讓這些Provider/ Factory休息一下，然後把事情做好（不鑽研）。

　　去你們的，我要回家了

　　沒事，實際上我不會再做企業級的東西了。我將問題和答案展示給我的同事們，對於你的付出我們都覺得很好笑，因為愚蠢得簡直太好笑了。但是你知道嗎？當你們都停止挖這個坑的時候，你們會發現這個坑看起來到底有多深，我會站在外面大聲嘲笑你的，因為這還是你自己的錯。

　　開始為自己著想，亡羊補牢為時未晚且學會寫一些實際的程式碼。資訊就在那裡，你可以做的。如果你需要掌握Factory，Factory Provider和Service Provider(各種模式，框架，服務)然後意識到這個世界並不需要你的程式碼，然後去找一份你確實在行的工作。不要再禍害我們剩下的人了。

　　原文 codeofrob.com