2016年11月，接受了一個(gè)工作，是對“悟空CRM”進(jìn)行一些修補(bǔ)。這是一個(gè)不錯(cuò)的 CRM，開源，并提供一個(gè) SaaS 的服務(wù)。正好微軟的 .NET Core 和 ASP.NET Core 也發(fā)布了。于是就有了這個(gè)想法：使用 ASP.NET Core 來開發(fā)一個(gè) CRM。當(dāng)然這里面的私心是：朝后坦白講，悟空CRM 的代碼真的是不怎么樣。大量的代碼堆在 Controller 里，多個(gè)功能在一個(gè) EndPoint 里混合。權(quán)限管理也有些亂來。View 里充滿了“臨時(shí)解決方案”。所以我真的是一邊改，一邊難受。由于11月我還在做一個(gè) Xarmin 的小程序，所以對 CoreCRM 的開發(fā)就定在12月開始了。
因?yàn)樾薷奈蚩誄RM，本來以為對業(yè)務(wù)的邏輯已經(jīng)比較熟悉，先開始的時(shí)候照著悟空CRM的UI直接開始擼就可以了。在嘗試了幾個(gè)頁面之后發(fā)現(xiàn)這樣比自己直接寫還麻煩。而在這中間，我的老毛病有犯了：在幾種技術(shù)方案之間不停地權(quán)衡和嘗試。這樣，時(shí)間就一天天的浪費(fèi)掉了。技術(shù)方案的選擇經(jīng)歷了：VueJS + jQuery，React.NET，aspnetcore-spa (ReactJS + Redux)，最后又回到 VueJS + jQuery。CSS 框架使用的是 Bootstrap 3.3.6，這個(gè)是一直沒有變（雖然我也曾經(jīng)想過使用4.0的alpha版，不過最后還是忍住了）。圖標(biāo)使用了font-awesome 4.7.0，也是沒有改。一直折騰了一個(gè)月（這中間還有因?yàn)閷?ASP.NET Core 不夠熟悉而付出的學(xué)習(xí)成本），整個(gè)12月將要過完的時(shí)候，我才只完成了 Layout 和 Login。（其實(shí)原來的首頁、結(jié)構(gòu)架構(gòu)也完成了，但只有UI的部分）。
關(guān)于技術(shù)選擇
為什么要選擇 ASP.NET Core？
我的一個(gè)基本判斷是：帶有類型檢查的語言應(yīng)該是未來的趨勢。雖然從歷史角度看，動態(tài)類型和靜態(tài)類型總是交替上臺表演的。不過，隨著程度規(guī)模的不斷變大（想當(dāng)年一個(gè) DOS 程序就幾十，幾百K，求伯君可以使用彙編擼一個(gè) WPS 出來，而現(xiàn)在一個(gè)手機(jī) App 也是幾十MB），動態(tài)語言的一些不方便的方面是突顯出來了。特別是多人協(xié)作開發(fā)的時(shí)候，因?yàn)闆]有類型的靜態(tài)類型檢查，很多錯(cuò)誤都只能在運(yùn)行的時(shí)候才能發(fā)現(xiàn)。其實(shí)這個(gè)問題如果配合上足夠的單元測試，也是可以減輕一些的，然而到了2016年，還是有很多人把測試當(dāng)成負(fù)擔(dān)。結(jié)果就是大量的 bug 和安全漏洞，以及改了補(bǔ)了一個(gè)洞，又開了三個(gè)洞。
從現(xiàn)實(shí)情況看，PHP 7 已經(jīng)引入了一些類型標(biāo)注，Python 3.5 也有這樣的東西，JS 系里有 TypeScript 這樣的 Transpiler（而且，Angular 2 這樣的框架已經(jīng)開始在使用 TypeScript 進(jìn)行開發(fā)了），以及 Facebook 的 flow。所以，動態(tài)語言在漫漫的靜態(tài)化。雖然只是提供了類型的運(yùn)行前檢查，但也減少了很多運(yùn)行時(shí)的問題。
