写在前面
短短的几天，我收货颇丰
js的异步回调处理（co）
初识node.js，并且对node.js的开发模式有了一定的了解
阅读深入浅出Node.js前四章
学会webpack多页配置
api接口调用的方式转换
对于第三方组件认识
知道并且了解新的数据传输格式Protobuf，用于不同服务之间的通信，更少的体积和带宽损耗
低耦合，高复用！
编程的边界情况要尽量多的去考虑
设计模式（单例模式、装饰者模式，观察者模式）
简单的看了下医生端的vue和node代码，压力很大。第一感觉是自己还需要打磨，还有很长的路要走，包括但不限于webpack多页的配置项和node.js相关开发。
单从vue的代码来看，同样是用vue的脚手架，对比以前自己写的代码，医生客户端的代码总会让人感觉更好。比如更加解耦的写代码方式、
一些更棒的封装以及更加规范的开发方式等等，都让我深刻的认识到以前开发的错误。不过遗憾的是因为开发环境的限制，没能本地运行起来查看相关的界面。
医生客户端代码阅读小记
因为对于vue脚手架的项目架构比较熟悉，这里就不一一列举了，仅记录一些知识点
webpack多页面输出
一直以为脚手架的单页改多页是比较困难的事，但是今天阅读了代码才知道其实并不是想象中的那么麻烦。给对应的页面增加一段entry入口，
然后在相关目录中存放每个页面对应的HtmlWebpackPlugin处理文件，去定义如何打包页面，在prod和dev的webpack配置中相应的merge将
配置合并进去即可。
本项目采用的是将html模板放在后端的形式，所以前端生产环境打包的时候就不需要去生成对应的html文件，也就不需要在webpack的prod的配置中进行相应的配置。
又因为模板在后端，所以需要一个映射文件，否则webpack每次打包的文件都带有hash，这就需要webpack的插件webpack-manifest-plugin去配合后端的渲染。
根据文档进行配置生成映射清单即可
对于组件的封装方面
components 中部分组件封装直接使用props来传递回调的方法，这一点是以前没想到过的，很新颖，减少了代码量
尽量将代码掌握在自己手中，减少第三方插件的使用
fetch-api中do-false?
api层使用async await对方法进行调用，异步转同步的方式更加符合编程习惯
#####
客户端的组件里props基本都直接是字符串，这样如果没有props验证的话，其他人调用是不是可能会传错参数或者参数类型之类的。
load-more组件如果不指定type就会报错
评价的星级感觉可以封装成一个组件
医生服务端代码阅读小记
首先因为node开发经验的匮乏，请教了童导师相关的结构。在导师耐心的讲解下，也有了一些理解和思考
为什么使用co而不是async await来直接进行异步
很多方法中都是一个方法做了很多事，是不是可以将其进行拆分。
项目结构
- config
- 这一层主要是项目的配置信息相关，不多做赘述
controllers
- 控制层，主要负责对客户端来的请求进行转发和处理
- api
- 这一层是对外开放的api接口，统一放在api文件夹下，方便阅读
- doctor
- 主要是获取医生自己的相关信息和修改在线状态等操作
- patient
- 主要是医生获取患者信息或者对患者进项相关操作的接口
- profile
- 对于医生的其他操作
- wechat
- 获取到医院的相关信息和url参数，然后获取jssdk签名信息返回
- 剩下的几个目录就是对应相对页面的路由
- controllers-common
- 该目录下主要存放一些通用的处理逻辑，区别于controller存放
- auth
- 存放微信授权返回之后的逻辑，首先是对医生的状态进行判断，通过之后对登陆表进行操作
libs
- 用来存放中间件，工具类等
- middlewares
- 主要用来存放中间件
- extend-req
- 对请求的request和response参数进行配置
- filter-scan
- login-check
- 对当前登录状态的处理进行封装
- 翻阅代码之后发现代码的健壮性比我之前写的版本好了很多，之前自己写的时候可能只是按照api文档写下去，并没有考虑那么多情况，所以健壮性方面还有待提升。
- utils
- 该目录主要是存放项目中的一些工具类包括跳转微信授权URL、对json、html格式输出处理、日志打印等工具。
models
- 该目录是使用sequelize之后需要的创建文件和数据库的表一一对应。
- rpc（远程过程调用）
- 因为项目是部署在docker容器中，所以该模块是用来和其他项目进行通信的。
- service
- 这一层主要进行业务逻辑的相关操作，对数据库进行存取
- 使用base-service对对返回值进行封装，统一调用，相对于之前写后台每个返回都要写一遍的做法方便了很多，也更加规范。
- template
- 这一层是放模板界面，使用ejs语法
理解
在导师的讲解之后发现，同为后端，node和java相通的地方还是比较多的，所以很多技术通过联想
之前java开发的时候使用的技术都可以很快的理解。例如controller和service层可以通过之前
的spring mvc进行理解，templates里面的写法可以通过之前的jsp进行理解、sequelize可以
通过jpa来理解等等。可能因为以前有过一些开发基础，所以总体听下来还是比较清晰的，对整个项
目也有了一定的认识。
思考
通过这一系列的对比，让我认识到了语言的互通性，不一定非要说精通所有东西，或许专精一样
会更好，尽管领域不同，或多或少的还会有一些相通的特性。并且业务代码的高度解耦，对我也
有很大的启发，以前写业务代码的时候，因为组内人比较少，业务也不是很复杂，一般都是想到
哪里写到哪里，等到最后写完需要回去修改的时候才发现是多么的不方便，以后写代码的时候一
定要充分考虑到这些因素，最大程度上实现代码的解耦。进一步提升自己的编码水平。总会感觉
自己的知识面还是太窄，虽然能理解是什么，但是一下子看到这么多没用过的技术还是有点慌的，
或许是自己平时的积累少了，应该抓紧时间去弥补这些不足
wenzhen-serve阅读小记
和医生端服务端的代码又一些重合的地方，所以这里只是简单的坐下记录
目录结构
- doc
- rpc数据交换格式存储目录(使用jec格式的文件更加适合网络上的存储和交换，因为空间小，所以占用的带宽更加小)
- src
- config
- 主要存放项目的配置文件，比如数据库、微信、rpc、基础页面设置等配置
- contollers
- 控制层，主要是对业务流程模块的控制，在这里调用service接口和用来控制对应的界面跳转
- decorators
- 通过装饰者模式增加用户认证和获取模板页功能
- middlewares
- 存放日志打印、文件上传、url检测等中间件
- models
- 主要对应数据库设置和文件映射
- proxy
- 对于之前的jce文件的js生成版本
- schedule
- 一些定时任务，比如
- service
- 业务逻辑层，主要用来处理相关的业务逻辑
- config