2016年11月，接受了一個工作，是對“悟空CRM”進行一些修補。這是一個不錯的 CRM，開源，并提供一個 SaaS 的服務。正好微軟的 .NET Core 和 ASP.NET Core 也發(fā)布了。于是就有了這個想法：使用 ASP.NET Core 來開發(fā)一個 CRM。當然這里面的私心是：朝后坦白講，悟空CRM 的代碼真的是不怎么樣。大量的代碼堆在 Controller 里，多個功能在一個 EndPoint 里混合。權限管理也有些亂來。View 里充滿了“臨時解決方案”。所以我真的是一邊改，一邊難受。由于11月我還在做一個 Xarmin 的小程序，所以對 CoreCRM 的開發(fā)就定在12月開始了。
因為修改悟空CRM，本來以為對業(yè)務的邏輯已經比較熟悉，先開始的時候照著悟空CRM的UI直接開始擼就可以了。在嘗試了幾個頁面之后發(fā)現這樣比自己直接寫還麻煩。而在這中間，我的老毛病有犯了：在幾種技術方案之間不停地權衡和嘗試。這樣，時間就一天天的浪費掉了。技術方案的選擇經歷了：VueJS + jQuery，React.NET，aspnetcore-spa (ReactJS + Redux)，最后又回到 VueJS + jQuery。CSS 框架使用的是 Bootstrap 3.3.6，這個是一直沒有變（雖然我也曾經想過使用4.0的alpha版，不過最后還是忍住了）。圖標使用了font-awesome 4.7.0，也是沒有改。一直折騰了一個月（這中間還有因為對 ASP.NET Core 不夠熟悉而付出的學習成本），整個12月將要過完的時候，我才只完成了 Layout 和 Login。（其實原來的首頁、結構架構也完成了，但只有UI的部分）。
關于技術選擇
為什么要選擇 ASP.NET Core？
我的一個基本判斷是：帶有類型檢查的語言應該是未來的趨勢。雖然從歷史角度看，動態(tài)類型和靜態(tài)類型總是交替上臺表演的。不過，隨著程度規(guī)模的不斷變大（想當年一個 DOS 程序就幾十，幾百K，求伯君可以使用彙編擼一個 WPS 出來，而現在一個手機 App 也是幾十MB），動態(tài)語言的一些不方便的方面是突顯出來了。特別是多人協(xié)作開發(fā)的時候，因為沒有類型的靜態(tài)類型檢查，很多錯誤都只能在運行的時候才能發(fā)現。其實這個問題如果配合上足夠的單元測試，也是可以減輕一些的，然而到了2016年，還是有很多人把測試當成負擔。結果就是大量的 bug 和安全漏洞，以及改了補了一個洞，又開了三個洞。
從現實情況看，PHP 7 已經引入了一些類型標注，Python 3.5 也有這樣的東西，JS 系里有 TypeScript 這樣的 Transpiler（而且，Angular 2 這樣的框架已經開始在使用 TypeScript 進行開發(fā)了），以及 Facebook 的 flow。所以，動態(tài)語言在漫漫的靜態(tài)化。雖然只是提供了類型的運行前檢查，但也減少了很多運行時的問題。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉無線電——不安全的藍牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現JSON轉Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應用分析 2017-07-26
- 集合結合數據結構來看看(二) 2017-07-26
學習是年輕人改變自己的最好方式