我花了两天把接外包的血泪写了出来

这篇文章是对一次失败的外包项目的反思。

（周五 v2 上有个哥们说周末要全身心做点事情。嗯......我本来想说睡觉，然而最后写了篇长文。至于为啥拖了半年，你看文章长度就知道了，写文章真心累人而且纯粹是信仰）

背景

半年前非常非常缺钱花，因此接了个来自学院老师的外包项目，负责沟通的甲方是一位想转行的学校老师，另外还有投资人，偶尔露脸。而我们这边的主要负责人是我们的老师。和另一位同学商量了一下，直接实践前后端分离，后端以类似 RESTful 的风格设计 api，我负责前端，工作内容是写与公众号绑定的 Web App。然而第一次接外包，踩了很多坑，下面分章节说明。

需求不确定

学校项目往往没有文档。一般来说，这些项目在外面都是没人肯接，因为这些项目往往没有明确的需求，就算有也会常常变，稍微有点软件工程常识都知道这是大忌。当然，作为学生练手，也没啥关系，就是做得很累（就是 9/12/7 这样工作）。具体到这个项目中，文档是一个已经上线某 app 作为参考，甲方与负责人的口头说明，UI 设计是自由发挥，技术选型也是自由发挥。

首先是沟通问题。其实需求变动不多，直接抄某 app 就可以，比较麻烦的是与 app 不同的内容，这种需求问题其实需要反复与甲方沟通、确认的，然而我这里采取的方法是快速出原型，做完一部分就给甲方看，然后沟通。这里最大的错误是我高估了自己的能力，对一个新手来说，写出健壮、高复用的代码实在太难，结果是，甲方要改的时候，我感觉很为难，修改常常意味着重写。其实在与甲方见面的时候应该认真把这部分给描述清楚，而不是三言两语。有一次功能都做完了，然后甲方提出了异议，表示与说好的不一样，后来发现是负责人与甲方意见不一，我们做的是负责人的要求。这种问题在会议上本可以沟通明白的。

UI 设计中消耗了大量时间。让程序员自由发挥设计 UI，叫程序员边写代码边做好 PM 实在是耍流氓。UI 实在是一种见仁见智的东西，IOS7 刚出来的时候也有人大骂库克毁了苹果，扁平化丑。所以是我的 git 分支里面有：indexV6、circleV3......事实上这些问题都应该避免的。厚着脸皮叫甲方搞定设计的问题，或者是自己找好人，让甲方付钱，一般这种情况，我推荐猪八戒随便找一个。不解决这个接下来会非常辛苦，比如说，甲方完全不懂移动 app 的设计规则，死活让你按照上个世纪的网页设计方法---把内容尽可能得塞进一个屏幕中。嗯，我觉得丑，甲方也这么觉得，然后让我改......我......我下次让甲方把 UI 找人弄好了再写前端。

技术选型

作为一个外包项目其实我是有私心的，希望将新技术用于实践中，然而这是非常鲁莽的，特别是在使用前没有提前进行详细的调查研究。

（不想引战，反驳请就事论事。我认为脱离场景讨论框架、语言、编辑器类似的信仰问题纯粹浪费时间。）

这个项目中使用 vue 是一个错误。在 2016 年 12 月时，vue2 刚出不久，整个生态还不完善，那时候很多 UI 库还只能用于 1.x 的版本中，插件也不完善，这对开发非常不利。

首先是 UI 库，我的标准是文档要完善，至少能快速上手，作者还在活跃地维护，满足这些标准的只有 mint-ui 和 element-ui，但是这两个 ui 库还是不够好，幸好有源码，自己研究了下代码，再改了改总算满足甲方需求，但是拖了挺长时间。其次 vue 的生态问题，比如头像裁剪插件，可用的库只有 PC 版，需要使用类似的功能需要自己想办法将类似的插件整合进 vue 中，也花了不少力气。（事实上外包项目应该怎么简单怎么来，最好抄起 jq 就是干。甲方在项目后期苦恼地和我说找不到会 vue 的人。）然后就是因为不熟悉 vue 而踩到的许多坑，这无法避免。

当然在以后项目的技术选型我会保持慎重，不是新技术差，至少使用前要：1.对自己项目的需求有个详细的规划，需要什么功能，研究该框架的生态，什么插件需要自己写，什么功能有现成库，估摸新框架对项目的影响。2.选用前至少在其他小型项目使用过，对其中的坑有所了解，不要被新框架影响项目进度。比如那时候 vue 严格限制子组件不能直接将信息传递给父组件，设法绕过限制反而使代码更难以维护，后来改需求花了不少时间（现在已经重新加上双向绑定功能，不需要 eventhub 了）。

技术上的问题

技术上的问题远比人的问题简单。

mock server 搭建

内容很简单，只是刚接触确实要推敲，还很麻烦。

项目中使用的是json-server，这个一个非常优秀的 mock 服务器，只需要写 json 就可以生成所需要的 mock 服务，但是 json 的问题是，不够灵活。折中的方法是写 js 文件，下文称这个文件为 db.js ，定义方法看 json-server 的文档。使用 js 文件设定 mock 服务的另一个好处是，这样可以将faker也集成进来，生成随机数据会非常简单。

但是这样也有问题。对需要传参的 api，比如说/album/:uid, 那么我们需要模拟多个用户的相册，然而一下子弄出成百上千的用户数据是会严重拖慢json-server的速度的，而且我们也并不需要那么多的数据，我们只是希望通过不同的uid可以返回一个相册数据就可以了。那利用route就可以解决这个问题。

在json-server中定义 route 的方法之一是写 json 文件，我们这里可以将不同uid的请求都指向同一个 api：

album/:id": "/album"

那么，我们只需要在db.js中定义一个album就可以访问任意 id 的相册。

另外，还有偷懒的方法：比如说有两个不同路径的 api，但是他们返回的数据相同，或者是某些需要 api 方法是 POST，而且提交的数据并不需要在页面中使用，那完全可以在db.js中导出一个空数组，然后用路由将所需要的路径指向这个空数组的路径：

// db.js
module.exports = function() {
	data.album = {...}
	data.fakePost = []
	return data
}

// route.json
{
	"/postAct": "/fakePost"
}

这样就引出了另一个问题，一般来说，我们想 api 发送一个 post 请求，服务端通常会返回数据或者是响应码，而json-server只会把 post 请求中的数据发送回来。那么 mock 返回值就需要另一样东西：中间件。其实写一个json-server中间没多复杂，比如：

module.exports = function (req, res, next) {
  if (req.method === 'POST' && req._parsedUrl.pathname === '/userDetail') {
    req.method = 'GET'
  }
  next()
}

这段代码走的事情是，将所有对/userDetail路径的 post 请求拦截，改为 get 方法，然后运行下一个中间件。加了这样一个中间件之后，post /userDetail 请求就相当于 get /userDetail，因此，只需要在db.js中定义/userDetail的返回值，就可以实现 post 请求后返回响应码或者指定数据。

关于 vue 的坑坑洼洼

v-model

非常好用的一个功能，本质上是一个语法糖，vue 的文档已经详细说明了原理，我在这里举一个例子。v-model 应用范围不仅仅是在<input>中，比如说我们需要做一个弹出层的提示框，用户在提示框中输入文字，点击确定后，输入的内容要出现在页面上。我们将弹出层组件命名为popup，正常来说，我们在父组件中需要添加代码监控confirm事件，然后在popup中，点击确认按钮时触发confirm:

// index.vue
// template 
	<div>content in the popup: {{content}}
	<popup @confirm="onConfirm"></popup>
// script
	...
	methods: {
		onConfirm(payload) {
			this.content = payload
		}
	}
	
// popup.vue
// template
	<input v-model="text">
	<button @click="onClick">Confirm</button>
// script
	methods: {
		onClick() {
			this.$emit('confirm', this.text)
		}
	}

那如果使用 v-model 的话，那代码可以简化，应该说，使用这个组件的人会很舒服，因为现在只要需要向组件传入一个 data 就可以了：

// index.vue
// template 
	<div>content in the popup: {{content}}
	<popup v-model="content"></popup>
	
// popup.vue
// template
	<input v-model="inputText">
	<button @click="onClick">Confirm</button>
// script
	props: {
		value: String
	},
	data: {
		...{
			inputText: ''
		}
	}
	methods: {
		onClick() {
			this.$emit('input', this.inputText)
		}
	}

可以看出，在index中，使用popup组件变得非常简单，只需要将content传入v-model即可。

这里需要注意的是，popup中必须添加一个名为value的参数，父组件的 content 将会传到 value 中；另外popup中还添加了inputText的属性，原因是，vue 不允许直接修改传入的props。完整代码，请点击。

当然这个例子只是为了说明v-model可以减少代码量，事实上这个例子并不合理，有很多改进的地方。事实上组件确认后应该返回一个 promise，让父组件随意处理输入的数据，这些就不展开说了，这又会是一篇文章。

操作 DOM 的问题

vue 虽然提供了数据绑定，但他也允许你直接修改 dom，但是！自行修改 DOM 导致的风险 vue 可不管，你自己改了渲染结果，vue 不知道，因此不推荐修改 DOM。

然而现实是残酷的，vue 不是万能，总有绕不过的坎，比如说，动画、移植插件等。下面是几条操作 DOM 的小规则。

在 vue 的生命周期里面，要到mount才能开始操作 DOM，vue 提供了this.$el，通过这个就能使用原生的 js 代码操作已经生成的 DOM。

如果你所操作的 DOM 依赖 data 中的某些属性，当 data 变化时，你的 DOM 是不会自动变化的，你需要在updated钩子函数中手动更新 DOM。

手动生成的 DOM 不会被组件内的 scoped css 影响，你需要自己在全局，或者是在 js 内写需要的样式。

为什么不允许直接修改 props

'Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "ifLiked"

上文关于v-model的章节中我们提到 vue 不允许直接修改传入的props，vue 的警告信息已经清晰地说明了为什么，然而我们可以简单地通过新建一个data属性的方式绕过，然而绕过并没有解决问题。比如说，有这样一个场景：朋友圈点赞，然后设计如下：

1. Card 表示一条朋友圈，其data中有一个属性为ifLiked，表示是否被当前用户点过赞
2. 点赞按钮 Thumb，其props中有一个属性ifPink，用户点赞后，ifPink变为true，按钮变为粉红色。
3. Card 是 Thumb 的父组件，加载时，Card 通过从服务端获取用户的点赞数据，然后将ifLiked传入 Thumb 的 ifPink中。

看出这样设计的问题了吗？

用户点赞时，Thumb 只修改了作为props的ifPink！虽然 UI 看起来是正常的，然而父组件中的 ifLiked 却并不知道用户已经点了赞，因为 vue 禁止子组件直接修改父组件的属性，如果用户通过路由进入了其他页面，然后重新返回朋友圈会发现，自己点的赞全变成了灰色。

解决方法有三个：

1. 通过事件监听将子组件的数据返回给父组件。然而这是一个糟糕的办法，原因很简单，如果你的票圈层级改为 Card-> Handlers -> Thumbs，Thumbs 并不是 Card 的直接父组件时，代码量急剧上升，因为 Handler 不仅要代理ifLiked，还要代理点赞事件！因为 Card 是无法直接监听 Thumbs 所发出的事件的。

2. 发出点赞后，重新向服务器获取已点赞信息。

3. 使用 eventhub 或者是 vuex ”修改“父组件内容(当然不是直接修改啦)。

不得不说，无论哪个方案都非常折磨人，于是：

在 2017 年 4 月底发布的 vue 2.3.0 中，被删掉的.sync回归。日。

一定要进行错误处理

菜鸡代码的死穴是：脆弱。特别是移动端的前端，如果不做好错误处理，肯定要被老板和客户骂死。

程序逻辑的错误其实问题不大，大部分 vue 都给挡住了，大不了就是点击没反应，反正不至于白屏，这里重点说网络错误。

这个项目中的前端做成了 SPA----大量 AJAX，那问题就是，如果有任意一个 AJAX 请求出了问题，但没有对用户的指令，这样的用户体验极差，特别是移动端网络不稳定。此外，出错没有任何提示信息也不利于修复 Bug，用户就两个字：白屏，这真是没办法。项目完结后，我总结了一下必须处理的错误分为两种：

1. 页面加载时的发生的错误；
2. 加载结束后网络请求的错误。

对第一种错误，发生时应该提示错误与错误码，然后自动刷新页面。在项目初期时，这样可以快速修复 Bug，错误码可以清晰地分辨出问题出自前端还是出自后端。在项目后期，这些提示就可以全部关掉了，项目已经成熟。如果这个项目可以继续的话，我是会将加载时的错误处理变为：

1. 自动重新加载 3 次，然后提示网络错误，为用户提供手动重新加载的功能；
2. 出现手动重新加载页面时，将错误信息、用户访问的页面、发生错误的 api 发送回服务器存 log。

对第二种错误，自然提示网络错误，让用户重新点击，重新发送。当然了，如果用户发送的请求是发送已输入数据，发生错误的时候，将已输入数据保存到 LocalStroage 中，重新加载页面是将输入信息也提取出来。

最后要说明的是，在用户进行任意网络请求时，请加上反馈，比如进度条，比如提示加载成功。

至于在我的项目中，实施的方法很 low，我简单带一下。首先，网络错误会在 Promise 中抛出，在调用 API 时处理 reject 就可以了，然后是自定义错误码的处理，后端的同学会将自定义错误以 JSON 的方式返回而且 HTTP 状态码统一返回 200，以防止运营商劫持。错误 JSON 格式如下：

{
	errcode: 5001,
	errmsg: ''
}

项目的 AJAX 通过vue-resource实施，而这个库带有interceptors，又是一个中间件，具体用法可以看文档，我定义了这么一个中间件：

Vue.http.interceptors.push((request, next) => {
  request.credentials = true
  next(response => {
    // 从 response 中获取数据
    let data = utils.response2Data(response)

    if (data.errcode && data.errcode !== 0) {
      response.status = data.errcode
      response.statusText = data.errmsg
      response.ok = false
    }
  })
})

这个中间件会将全部返回的请求都拦截检查一遍，如果发现数据中同时有errcode与errmsg的字段，就自动将响应的status、statusText与ok替换，这样就能触发 Promise 的 reject 了，错误便可以在组件中统一处理。

关于 API 设计

因为缺乏文档的关系，在 API 设计上我与后端一起设计，首先说明我写一个组件的工作流程：

确定数据结构 - 设计 API - 写 setting - 写文档 - 写 api 实现 - 组件设计 - 写页面

• 确定数据结构：确定该组件所需要的数据，设计字段，以及该字段应该使用什么方式保存；

• 设计 API：事实上我只是设计数据传输的字段，至于 API 的路径我不需要关心；

• 写 setting：由于前后端工作不同步、需求文档缺乏，API 也只能边做边设计，这样就导致后端不知道需要提供什么字段，至于路径的设计更无从谈起。我提出的解决方法是，我与后端一起维护一个setting.js，其大致结构如下：

  var dev = true
  var apiPrefix = dev ? 'http://localhost:3000' : 'http://api.server.com'
  
  let devApis = {
    'circlesApi': apiPrefix + '/circles',
    ...
  }
  
  let apis = {
    'circlesApi': apiPrefix + '/circles', 
    ...
  }
  
  let api = dev ? devApis : apis
  

  这个setting.js中将开发的 mock API 与生产环境的 API 路径分离，这样我开时的 mock API 便的路径可以随便定义，写完后将setting.js的字段与定义告诉后端，后端在根据我提供的 API 行为文档自己去实现即可。需要说明的是由于setting.js是外部文件不用直接当做 ES6 模块导入，因此会存在缓存问题，即setting.js更新不及时，所以在请求时后 url 后加上一个随机的参数以强制刷新缓存，如url?timestamp=hash()

• 组件设计：拆组件，哪些可以复用，如何高复用 blablab，数据流 blablabla

• 写页面：写啊。

然后，我们两都是第一次搞前后端分离，在 API 设计上存在一些问题，经验总结如下：

• 客户端知道尽量少的信息就可以使用 API，尽量精简 POST 请求中 JSON 数据的字段数，可以算的绝对不传。

• 很多文章说应该使用 HTTP 方法作为一个动词，路径中充满名词，然而我们实践下来发现，HTTP 方法的动词要么不够用，要么不够直观，另外，不同人对 HTTP 方法的意义有不同的理解（比如 PATCH 与 PUT ），虽然翻文档可以解决问题，然而文档如果不更新(比如我们)，API 就变的非常难以理解，到项目中期，我们将 API 的风格变为：

  	POST /moments => POST /moments/add
  	PATCH /moments/:id => POST /moments/:id/like
  	PATCH /moments/:id => POST /moments/:id/unlike
  	GET /moments 不变，不影响理解
  	POST /moments/:id/comment
  	POST /moments/:id/edit
  

  可以看出我们只使用 POST 与 GET 方法，路径的构成为名词 + 路径末尾动词，这样 API 所表达的意思直观得多。（这部分其实见仁见智，因为 RESTful API 设计没有统一的标准）

• 如果响应的某个字段为空, 空数据请用''(空字符串), 这次项目中后端使用 null 表示空数据，而我的 mock 服务使用空字符串，因此上线后各种姿势的错误，然后花了非常多时间过滤响应的 null。请各位后端手下留情，空数据一定一定要用空字符串。

CSS

• 开发前要订好全局样式, 即标题文字大小, 描述文字大小, 颜色, 全局背景颜色，统一修改，不然散落各处那个酸爽；

• 移动端慎重使用 overflow-y:scroll, 手机滑动会卡顿，iphone 也不例外；

• 使用rem别用px，鬼知道甲方要不要你适配 ipad。

其他

• 用 vue-cli 的话，看看这个文档会让你少走许多弯路。这个文档详细说明了vue-cli的 webpack 模板设置与常见问题，包括静态文件处理、css 处理器添加、环境变量、单元测试问题等；

• yarn 很棒，简单好用；

有空也可以去学学 react 和 angular，这两位老大哥的社区里面关于设计模式的内容非常值得看；

• mint-ui 的源码很值得看，他们的设计非常棒，比如 MessageBox 的回调处理，看得我目瞪口呆，还有这种操作。有空再写写 mint-ui 源码分析；

• 发包含 id 的数据考虑是否要先 parseInt，可能后端只接受id: 1而不接受id: "1"，说多都是泪；

• this.$route 和 this.$router 是两个完全不一样的东西；

• 再说一次：如果后端发 null 和 undefined 给前端, 毫不犹豫地拿刀去见他。

PS

1. 其实感觉甲方也挺惨，遇到我这种坑货，中间出了一堆坑全要耐着性子等我处理完。而且甲方人也很好，提前给尾款，过年还发红包，简直良心。但愿以后也能遇到良心老板。

2. 哎，有耐性写这种文章的也就我这种有信仰的失业人员了。

3. 这篇文章让我回想起了写硕士论文的恐惧，哎，网上分享干货与教程的大大真是伟大得不行，另外开源项目中负责写文档的哥们也是条汉子。

4. 啊，失业也不是坏事，终于把这几千字憋了出来。