半年工做总结

一 先后端沟通

    先后端沟通是一个老生常谈的问题。先后端分离的同时就必然会存在这样的问题。   首先来看一下咱们的场景：

1.前端本地开发须要链接测试服务器，而且要作token验证（这个其实能够省略，但并无），以致于每次都要从数据库手动查一下token。

2.先后端须要联调，那么就要链接后端开发的电脑。频繁的切换开发和测试，以致于和不一样的开发合做，须要配置不一样的配置。

3.存在跨域问题。  目前经过本地启动nginx 以及更改host文件实现。  至关心酸，浏览器host有缓存切换host是个噩梦，还要莫名启动ngxin，我总感受怪怪的。

4. 有时候重构代码，接口请求参数不当心改了，本地测试没问题，只有放到uat或者生产才看出问题。

5. 后端把接口格式改了，须要即时通知你更改请求参数。

6. 数据不足，不能测试。

。。。。。。

总之，很是麻烦，谁经历谁知道。因此我作了一个中间mock服务器，前端不须要向后端要数据了。mock服务器会按照约定的格式生成数据，同时作了一个接口服务器，用来展现项目中全部的接口。 而且接口发生变化会自动通知mock服务器并重启，新的接口就能够在mock上访问了。    而且支持json schema 验证。 能够解决以上全部问题。

整个流程是这样的：

开发人员在文档服务器编写接口文档，接口服务器将接口信息保存到mongo数据库。

接口服务器向mock服务器发送请求通知它接口发生变化，mock服务重启。 

开发环境向mock 发请求，mock 根据配置的restapi 动态生成路由拦截请求，并根据配置文mock template 作数据校验，并返回结果。若是数据不符合接口规范，会做为出错信息提示出来。

 

二 同端团队协做

因为一些缘由，最近在改别人的代码时候，会有一些问题。就是代码风格，思想不一致致使的。 我以为团队中应该有一套规范。这个规范要从两个方面来下手。

第一，代码书写规范，推荐airbnb

第二，代码结构规范，简单讲就是分层。 分几层，每一层作什么，什么样的逻辑放在什么样的地方。

第三，数据库尽可能保持一致。 同一个功能我相信你有一万种实现方式。但理解并正确修改别人的代码每每是困难的。数据传递的方式应该尽量规范一下。  如今个人代码是根容器嵌套自子容器，子容器嵌套子组件。容器之间以及容器与组件经过prop传递数据（容器以前传递的属性一个是config 传递数据对象，一个是getStoreState函数获取父容器数据，还有一个setStoreState修改父容器数据，这样子组件不须要引用，解耦）。容器从store  获取数据，而后经过config顺着往下流。 数据在组件中进行修改，若是须要通知其余组件就setStoreState  若是不须要直接将数据发送出去。

还有一点是尽可能不要让函数直接处理你的数据，更不要写死代码。  也就是说dont speak out your data 。 这样能够极大提升程序的可维护性和扩展性。

 

写须要写死的封装到配置，将数据获取封装到纯函数以外。 

三 组件封装

目前咱们团队就两个前端，彼此写的组件对方尚且不清楚到底怎么用。 都在想有没有什么玄机呢？另外就是其余团队写的好的组件咱们并不知道，更别说拿来主义了。

基于此，我作了一个组件平台。这个组件平台主要有如下几个做用：

1. 让人看到你有哪些组件，有哪些功能，怎么用

2. 每个组件均可以做为独立发布单元，发布到npm上。

3. 组件和项目分离。这样拼积木式的开发省去不少重复代码，也就意味着代码出bug，不须要逐一修改。

 

在这里能够看到全部的组件

 能够看到组件的api文档。

 能够在线实验这些组件api。

能够直接粘贴代码拿过去用。

四 部署问题

测试环境， uat，生产都须要发布，每个配置都不尽相同。若是手工发布麻烦，容易出错，若是发布的人不在，不熟悉发布流程的也不肯意去抗这个锅。 进一步考虑shell 发布，这种的问题在于不一样的发布执行不一样的脚本，对于不熟悉的人来讲仍是不直观。在这里建议使用web管理工具好比pyledo，只要作一些配置，就能够自动打包部署。既发挥了图形界面的直观，又发挥了shell的灵活。