小项目的总结

前言

本身学习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
//请勿修改此用户的密码，或在用户管理页中删除此用户

代码