近期两个外包项目的总结

背景

从大三上学期临近期末开始，陆陆续续的做了两个外包项目的后台开发，另外还参与了与甲方的对接、以及部分的产品工作。分别是：

探宝猎人小程序，已上线，古币鉴定类小程序。涉及鉴定管理端和用户端。
wefarm小程序，由于涉及视频这一敏感内容，还未上线，但开发已基本完成。是一款以短视频为卖点的C2C商城。涉及商家端和用户端。

技术选型

我主要负责这两款小程序的后台开发。技术栈采用nodejs生态，主要涉及express、mysql（存储业务数据）、mongodb（存储与核心业务关联不大但高频访问的数据，例如session）、sequelize(orm)。

我之前从没有用过nodejs，之前自己独立写的一些小项目也都是基于python flask作为后台web框架，突然转向nodejs也是因为实验室师兄的要求。一路用下来，比flask确实好用很多。

上手简单，开发速度快。
异步模式使得性能比python好多了。
生态完善，npm很好用。

初期学习过程

由于都是低预算的外包，所以我们的开发速度必须很快，毫无疑问，这是动态语言的优势。之前用过flask框架，大致上套路都是MVC（Model 、 View 、 Controller），数据库设计好之后，其余就是CRUD，业务逻辑也并不复杂。先从菜鸟教程的基本语法看起，然后看看阮一峰的es6教程，总体上，花一两天时间基本上可以上手写代码了。不过JavaScript最难理解的地方我觉得有两个：

原型链
异步

大二学习的Java给我留下了很深刻的映像：完全oo，严格的继承。Python在复杂工程下也差不多，先定义class，然后实例化调用。但是JavaScript完全不同，它是通过原型链来实现继承。整体上我觉得比常规的理解起来要复杂很多。

然后是异步，JavaScript的单线程模型通过异步的方式来取得超越Python的性能表现。之前写同步的代码写多了，初次接触异步还是十分有难度的。为了解决回调地狱，两个项目都使用了es2017的async和await关键字。

其实这两点完全可以单独写一篇博文，鉴于我寒假也在看红宝书，看完之后，我估计也会写一篇系统的、深入的博文来单独讲。

开发流程

两个项目的开发流程大体上类似。团队总共四个人，分工有：

PM（我师兄，我也承担了一部分工作）
后端（我）
设计（设计相关专业的学姐）
前端（软件学院的一个学姐）

工作流程主要分为以下几个步骤：

PM和甲方对接确定需求
需求评审会议，团队所有成员和PM讨论需求的实现。
PM出原型图，我们使用的是Axure RP。
同甲方讨论修改原型。反复修改一段时间。
原型交设计出设计图。后端的工作也正式开始了。 1. 对照原型图理清业务逻辑，编写model，设计数据库。
在理清业务逻辑时，如果发现原型存在的问题，马上汇报讨论修改原型。如果遇到原型表述不清的情况，同PM沟通确定
设计API，文档我们使用携程的YAPI，通过生成符合swagger文档规范的json文件导入。
一个接着一个实现每一个API，并测试。
设计图出来后交给前端写静态页面。
前端与后端对接口，对完之后，进行最后的整体测试。确认无误后就可以上线了。

几点遗憾

没有编写测试样例，进行自动化测试

在写api的过程中，我是用postman进行手动的测试。在开始本次项目之前，原本计划使用jest等框架编写测试样例，进行全自动化的测试，但是由于时间比较紧，偷懒没有使用。

争取在以后的项目中使用，甚至可以更激进一点，采用TPP的开发模式。

代码利用率不高

主要体现在鉴权模块，部分api接口在调用时，需要使用session对用户进行鉴权，为了图省事，这次我把鉴权的代码写在了每个Controller的前面。导致这部分代码出现了很多的重复。以后吸取教训，采用中间件的方式，减少代码的重复。

由于开发过程不规范，造成了很多问题

举个列子，在写探宝项目时，由于人员不足，并没有进行code review，导致在前期数据库model设计时就出现了的错误被忽视，上线之后，积累了一定量的用户数据后才发现，导致需要进行数据迁移，浪费了很多时间。

其实错误也很简单，在设计用户表时，我使用了用户的openId作为主键，而没有使用自增主键。由于Mysql的innodb采用的B+树索引，较长的openId带来了较大的索引碎片，会拖慢查找速度。

几点收获

规范的编码才能提高开发速度

在此次编码的过程中，使用了高强度的jshint来保证编码质量，并且为git添加了hook确保每次提交都符合规范。一开始我是很抵触的，认为这样不自由，但是开发到了后面，发现强制性的静态检查避免了很多不必要的错误，人总会犯错误，对于写代码这种高智力要求的活动，任何一个字符的错误就有可能导致出现严重的bug，而lint毫无疑问能够解决很多问题。

前期多点沟通，后期就能少点修改

在确定原型的过程中，出现了很多改动，后端还好一点，前端超级惨，第一个正式版上线前，大的页面改动就有四五次，小的改动更是不计其数。一方面是因为这两个项目的甲方都不是很懂互联网，还有就是前期的沟通不是很足，而且很多时候都是在微信上面进行沟通，造成了很多的误解。