小項目的總結

前言

本身學習node也有些時日了。終於在前些日子，本身的第一個node項目終於上線跑了，也第一次在node方面賺到了外快的甜頭。項目是一個企業內部的oa系統，不大。抽離表面看本質，就是一個express框架下的連接mongodb展現數據並可對數據進行CRUD操做的應用。代碼和demo，會在以後抽離掉一些具體業務內容後放出。下面來雜談一些總結，不足，和隨想。

1. 關於配置文件

私認爲配置文件存放着兩種類型的信息：項目運行的環境信息和關於項目結構的信息。前者保證了項目須要在另外一個（地理/運行）環境跑的時候能夠迅速方便地遷移，後者保證項目結構的統一性，存就在這裏存，改就在這裏改，以點輻射面，其餘的controller，service神馬的要東西都來這裏取，保證了項目的伸縮性。說俗話就是「這些那些均可以根據要求本身來配」。因爲小項目的代碼一開始是從小夥伴那接手來的，一開始並無專門的存放各種配置文件的地方，每一個業務點裏的信息都是寫死的，致使一個業務信息的小修改，每每就變成代碼十幾處的大改動，想改個mongodb配置找半天。幸虧回頭是岸，懸崖勒馬，岸就是/conifg/xxConfig.js。。。

2. 關於視圖模板

其實仍是一個伸縮性的問題，對於要作若干個大致相似，細節略有不一樣的頁面，可能你們和個人第一反應都是先作第一個頁面，而後複製黏貼幾份，把細節改一下，OK收工。的確，這樣作可能在短期內是最快完成任務的選擇。本身的小項目當時因爲第一階段要馬上有一個展現demo，時間略緊，採起的就是這個作法：幾個項目管理頁面，先寫好一個，複製黏貼，改改細節，輕鬆愉快。可是當後續須要再往裏添加功能時，恍然一悟，這坑真是給本身挖得夠大，一處實現，到處黏貼，到處修改，到處可能遺漏了某個修改，出小差錯的可能隨着規模的增長線性增加，大修改更是苦不堪言，又聞到了上文中那種業務結構沒有設配置文件時的熟悉又噁心的味道，但又覆水難收，只得把坑繼續堆疊。痛定思痛，在從此寫視圖模板時，必定要將視圖模板儘可能組件化，公用的組件公用，各頁面略有不一樣的地方也寫成組件分開存放，這樣修改纔能有效率和集中。本身有時會疑惑，爲何一個有經驗的程序員總能又快速又正確的完成任務呢？可能就是由於他對業務對視圖對各類需求的抽象能力吧。合理的抽象便意味着更少的代碼量，同時也意味更低的出低級差錯機率，真是有點魚和熊掌兼得的味道。。吾將繼續鍛鍊和求索。。

3. 關於各類輪子

node的迅猛發展，離開不了npm的百花齊放和神同樣的用戶體驗，迄今爲止，npm上Top100的庫也是聆郎滿目，幾乎涵蓋了開發需求的方方面面，本身總會糾結於在項目裏到底用它們呢，仍是不用呢？用的話，總以爲小小需求有點「殺雞用牛刀」，不用的話，又在作稍微有點複雜的功能時有種重複造輪子的不爽感。對於這個糾結，本身如今的態度就是這些Top100庫只要能用到就用。由於咱們老是很難預知項目的發展，如今的簡單邏輯不表明之後仍是隻用這些邏輯。npm這麼方便，反正用了也不麻煩嘛，若是之後要用庫，如今這些實現相似邏輯的代碼該如何是好？好比本身在項目裏作一些fs操做時，儘管知道有fs-extra這樣的好輪子，可是想一想簡單邏輯就本身寫吧，但隨着項目的發展，一會須要寫個mkdir -p，一會須要寫個rm -rf。爲了回頭是岸，果斷用上fs-extra，以致於留下一堆原生fs操做代碼與fs-extra操做代碼共存，看上去極其不和諧。。

4. 關於緩存

知道它的魔力，可是項目對數據的實時性要求較強，而且使用規模較小，想不到好的緩存切入點（除了靜態資源）。。感受加緩存是在徒增額外的複雜，有點吃力不討好。。

5. 關於mongoose的virtual type

之前總糾結於virtual type什麼時候用？如今的感受是，只要這個數據是能夠用現有數據庫裏的數據簡單算出來的，就用vurtual type。

6. 關於mongodb(v2.6)

在初學node時，總會在各類地方看到mongodb已經是node的缺省數據庫，標配之類的話。的確，json文檔模型，js操做語言看起來與node如此天造地設。可是隨着時間的流逝，項目的深刻，本身愈來愈有一個奇怪的感受，mongodb真是node不可質疑的真命天子的嗎？尤爲是在寫傳統的CRUD應用時。衆所周知，mongodb數據操做的原子性僅在單個document層面，並無傳統SQL的那些封裝事務，roll back這類的功能，直接寫多document的數據改寫操做，其中的一步報錯了，可能就要承擔數據不一致的風險。固然解決方法也有如「執行兩個階段的提交」，但老是透着一股hack味。或許，傳統的SQL才更適合這類數據結構固定，而且大量依賴「事務」的應用吧？總感受這會比mongodb省心省力很多。mongodb可能更適合那些數據以結構靈活多變，獨立性強幾乎相互不耦合爲特點的應用。因此是否是該以應用的數據模型特色來選擇本身的真命天子數據庫，而不是語言。。？

7. 關於代碼的職責分離

如今的結構：

• controllers：路由，獲取請求的內容，調用service，將service的結果返回
• models：
  
  
  • schemas/models：mongoose數據schemas和models及相關方法
  • services： 業務邏輯(包括調用mongoose與數據庫進行交互)
• views ：ejs模板

起初接手時各部分比較耦合，後本身重構成此結構，用起來感受還不錯。也看了很多node項目源碼的代碼職責規劃，感受也大同小異了。可能會再抽象出一個工具函數目錄和一個公共中間件目錄，想了想的確是個能夠繼續改進的地方。

8. 關於單元測試

項目的痛，規模一大以後跑起來，沒有測試簡直就是秉燭夜行。因爲是半途接手而且有段時間挺趕，雖然本身感受寫的代碼的功能單一性保持得不錯，也挺利於寫單元測試的，可是終究仍是沒寫。靠大量的手工測試總仍是不放心，心慌慌。唉，之後無論寫代碼或者工具，都要附上測試，而且保證竟可能高的覆蓋率！（已保持。。）

最後

demo地址

js用戶名:admin 
密碼:admin
//請勿修改此用戶的密碼，或在用戶管理頁中刪除此用戶

代碼