半年工作总结

原创
2016/05/11 22:15
阅读数 416

一 前后端沟通

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

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的灵活。

image

展开阅读全文
打赏
3
13 收藏
分享
加载中
lucifer210博主
几年后过来看,我竟然用的公司的wiki图片。 看来还是用自己爹图床比较好啊
2019/09/25 18:29
回复
举报
更多评论
打赏
1 评论
13 收藏
3
分享
返回顶部
顶部