初创技术团队的准备工作

初创的技术团队，一切从0开始，一切看似那么美好，前景如此令人向往。市场不等人，需要快速的抢占先机，所以产品如果能够早点面市，就比别人多了一丝活下去的希望。但是磨刀不误砍柴工，如果不做好基础的技术准备工作，就一头扎进业务代码中，看似如火如荼，实际会带来各种各样的隐患（当初创团队的团队成员并非是那种并肩在其他平台很长时间形成默契的战友的话，问题会更多）。在此，把我们的经验总结一下，避免踩坑。

总结下来，一个团队的建设要包括以下几个大的方面：

• 在团队协作方面，要搭建或者使用一些有利于团队协作的业务平台，减少大家之间沟通等带来的成本。
• 建立一系列良好的规范和制度并保证执行下去，包括编码规范、命名规范、晨会制度、周报制度等。
• 建立一套良好的研发流程
• 搭建一些基础的研发平台，以保证快速迭代，持续交付
• 如果不是土豪和专家，我们的建议是都用云服务，比如阿里云的ECS，RDS，开放搜索，Quick BI，redis，OSS，SLS等。

下面会从协作，规范，流程以及持续交付这四个方面来讲讲，我们在动手开干之前，技术团队要做好哪些准备。

搭建团队协作基础设施

开篇提到团队协作的基础设施能够减少团队协作间沟通等成本，下面从一些我们认为必须要有的基础设施来讲讲他们的用处。

私有gitlab的搭建

现在有很多的免费或者收费的平台能够提供相关的代码托管服务，那为什么一定要自己来搭建呢？

最早，我们团队使用过一家云代码托管服务，一周内好几次无法提交或者拉取代码，导致大家工作受到了影响。GITHUB也老不稳定，说不定哪天就被墙。再加上自己搭一个Gitlab并不麻烦，所以就自己搭建了。

maven私库的搭建

团队很大程度上会沉淀一些公用的jar，加上采用微服务架构，每个服务定义的接口都以jar包的形式给到调用方。这些jar包放置在团队私有的maven库上再合适不过。

共享文档库

大家可以把一些需求的理解以及设计方案放在这个地方，以便于其他人快速了解，也为了沉淀知识，比如团队扩张或者新人进来之后，能有地方让他们快速的学习和上手。

在这里推荐一款SaaS产品，叫语雀。目前是免费使用阶段，支持markdown，写起文档来感觉很爽。

项目、测试用例、缺陷管理工具

现在大多数初创团队都会采用敏捷的开发模式，以MVP的思路，快速迭代，不断完善产品。在一个迭代中，需要能够清晰的看到每天每个人有什么任务，每个任务处于什么阶段，是需求阶段，开发阶段，测试阶段还是已完成？类似Scrum中的看板的那种。还有测试的用例和缺陷也需要有一个系统能够进行维护和管理。目前我们团队正在用云效。当然云效能做的不只是这些，但是我们只是用了云效最基础的项目管理和缺陷以及用例管理的功能。

建立规范

一个团队如果没有规范，大家按照各自的习惯写代码，那么相互之间理解对方的代码的成本就会变高。规范就是为了把这种大家沟通，理解上的门槛和成本降低。让研发的同学关注在开心的写业务代码上。

编码规范

后端编码规范

幸运的是我们用的是java，我们完全按照阿里巴巴的规范进行后台代码的编写。也不用费劲脑子和嘴皮子来统一大家的语言规范了。按照阿里巴巴的规范来就好。

https://yq.aliyun.com/attachment/download/?spm=a2c4e.11153959.blogcont69327.7.506b2b13RgSAsi&id=4942

IDEA插件下载： https://github.com/alibaba/p3c

前端编码规范

命名规范

变量

表结构

表字段

数据库相关的规范，可以看看58沈剑的 58的数据库军规

项目结构规范

在之前，都是单体应用，大家定义好包的层级结构就好了。比如我们经常用的

-Controller

- Service

- Dao

- Model

- Common

这种分package的模式，后来演进成采用不同的module来表达不同的职责。

随着服务化的思路，我们的项目数量增多。那么每个项目要是有不同的这种结构，其实大家理解起来还是比较费劲的。所以，我们对每个项目的module都有约定（比如在哪写仓储代码，哪里写DAO代码各个层是如何依赖的），我们定义了一套自己的maven骨架，大家都用它来生成服务项目。这些大家在相互了解别人的代码的时候，即使不知道业务，也能很清晰的知道比如它定义的接口应该在哪个module里面，它引用别人的服务是在哪个module中定义的。

统一开发工具

团队最好是用一种开发工具，但是不强求。

建立研发流程

一套好的研发流程，能够让研发的效率以及质量提升数倍。虽然看起来，好像不是那么回事儿。但是经过实践对比后，有流程控制的项目确实从进度和质量上要超出没有流程的项目好几倍。

我们团队流程如下：

需求和设计评审

需求由PD产出后，一定要经过几轮的讨论（包括跟业务方，UED等），需要最终定稿，确定范围，并且研发的同学已经充分的理解要做什么。

在需求评审完成后，需要进行设计评审。主要是设计上是否逻辑完成，满足交互需求，并且定义好交互页面的规范和样式。

这两个评审是必须要有且不能随便的。

我们经历过开发到一半，需求推翻重来的情况，也经历过开发某个流程，发现PRD上遗漏了一种场景，又需要跟PD，业务方进行沟通，而且有些时候，这种未考虑到的场景在重新进行设计思考的时候还影响到了之前的代码架构设计，不得不修改之前的架构设计或者表结构等，造成大量的人力浪费。

我们也经历过前端的同学按照原型开发出来的页面，却并非是了产品和设计的想要的界面。很多原型工具并不是那么完整的表达出PD和UED脑子里的东西。 那么需要把这些规范，比如字体，字号，边距等都进行标注，来减少大家对同一个事物的理解不一致的情况发生。

系统设计

需求和设计确定后，基本上整个产品的形态都已经出现在我们研发的脑子中了。

系统设计阶段，需要研发对用例进行分析，确定自己脑子中的那个理解与定稿的需求是一致的。同时，研发还需要花点时间在对domain以及流程的设计上，尽可能的把一个业务场景考虑得周全。

系统设计阶段，就是让研发尽可能的推迟写代码的冲动，先把一个需求一个功能如何用代码实现，思考得深刻一点，把各种情况思考得全面一些，避免来回来去的返工。

我自己曾经也经历过，不做设计直接写代码。当初认为这个需求简单，所以就没有设计。后来代码写着写着，发现需求没有想象的简单，还要考虑一些场景，于是把写好的代码删了重写，反复好几次，每次都是发现了新的需要考虑的场景导致设计推倒重来。 后来索性，停下来，利用半天的时间，把问题思考全面了，再开始写代码，后面就是一气呵成了。

系统设计中，需要定义好两种接口。

1. 与前端的接口 （包括入参，返回值，错误码）
2. 与其他服务系统的接口（包括入参，返回值，错误码）

编码

按照规范编码，不要施展奇技淫巧。尽可能的抽象和收敛。

CR

CR一定要做，CR是团队成员之间相互了解对方的编码习惯和思路的一个很好的过程。

单元测试

利用mockito来进行单元测试的编写。研发的同学要考虑一个功能的正常和异常场景。 异常场景又需要根据各种情景来编写不同的测试用例。比如DB异常，RPC超时，下游返回调用错误等等。

为持续交付搭建基础设施

服务化之后，系统拆分得很小。每个系统上线需要能做到，随时随地，自动化。借助之前的经验，我们搭建了一套如下的环境

JENKINS + MESOS+MARATHON+DOCKER，来保证我们的系统能够快速上线，研发只需要点击下一个按钮即可。

后续我们会针对如何搭建持续交付的基础设施，如何使用阿里云的服务等等进行专题分享。