对于后端来讲，一个项目究竟应该怎么作

引子

做为一个程序员，平时的工做是与项目来挂钩的，可是有的时候会发现有些项目作得风生水起，有的则作得浑身难受，那么一个项目究竟应该怎么作？

一个后端接到项目的主要流程

1. 需求咨询
2. 需求评审
3. 项目估期
4. 技术评审
5. 跟上游约定 api
6. 开发
7. 联调测试
8. 产品验收
9. 上线
10. 整理必要的文档

需求咨询

这个阶段是后端最初接触某项目的初始阶段，此时产品会给出最初的需求文档（线框图此时可能没有），甚至是人肉来咨询后端作最初的评估，已肯定某些需求的可能性。

讨论结束后产品会根据讨论获得的结果回去开脑洞，项目可能夭折或者继续进行。

需求评审

产品通过他们本身的讨论设计，给出需求文档线框图（此时设计稿通常没有），召集先后端等项目成员进行需求评审。此时后端同窗须要根据需求的合理性、项目的开发周期进行讨论（砍需求）。

砍需求的目的不是为了砍需求而砍需求，须要根据手上已有系统的功能以及新需求作出综合考虑，尽可能在相对简单的状况下实现产品的需求。

简单的说就是难的我也能作，可是要花时间，砍需求的目的就在于在项目的 deadline 内可以完成这个项目。实在不行这个需求放在二期，太多的所谓二期需求就没有二期的项目了（可见有时候产品的需求...）

注意，产品会接受开发砍需求，可是开发请对确认后的需求认真估期，保证 deadline。不然又砍需求时间到了又作不完，呵呵。

项目估期

根据需求评审获得的需求，后端会先作初步的技术调研，需求拆分，在评审结束的1~2天内给出估期。

估期时须要注意，估期很难一次性估准，一个开发对于大于一周以上的估期就能够认为是凭感受瞎估了，这里有个估期的经验：将需求拆细后拆到开发级别的力度创建对应的 task，对于每一个 task 来作估期，当发现一个 task 的时间大于5后（单位为天），则须要拆分子 task，估期时采用斐波那契数列的评估方式: 1 2 3 5 8 13 21，对应于1天 2天 半周 1周 1.5周 2周 3周，能够上下加减0.5。而后根据子任务的时间合估计主任务的时间。

须要注意的是，估期时须要估计先后端联调时间，上线时间，资源申请时间，幺蛾子时间。幺蛾子时间为处理非此项目事件所花费的时间，这个跟开发自己所处的环境有关，能够在总估期的基础上乘以 1.2 ~ 1.5。

技术评审

复琐事情须要技术评审，尤为是本身作的事情内心也没有底气，须要其余开发一块儿讨论的时候。技术评审是保证复琐事情能够顺利完成，减小后期返工可能性的一个重要环节。

技术评审开发自己本身须要给出评审文档，包括项目背景，技术选型，主要的技术约束，本身想到的设计实现。

跟上游约定 api

通常一个项目会由多个部门并行开发，例如 数据、后端、前端、客户端，并行的过程当中若是某个端开发比较慢，会致使卡另外一个端的开发进度，因此须要开发前跟本身的上游约定 api，并给出文档，各个端遵循接口文档进行开发。

开发

根据技术评审后（简单的事情没有评审，本身内心有数）获得的方案以及以前创建的任务进行开发。

开发过程当中须要仔细研究设计稿的细节，有任何存疑问的点去找产品确认，确认后的需求记录在某个文档上。开发前几分钟的几句话，会大大下降返工的可能性。

记录后@产品画押，开发和产品的记性都不好，画押很是必要。后期甩锅有用。

开发时注意把某些流程繁琐的事情放在前面作，例如申请某些资源可能须要其余部门同窗支持，有额外等候时间。

开发过程当中遇到难点及时向其余开发求助，不要憋着。

若是可能遇到延期风险，请及时通知产品，deadline 请尽可能遵循（这句话的意思很明显）。

联调测试

先后端开发完后作总体的联调测试，在扔个产品测试前，请本身测过本身开发的 feature。不然气死产品事小，被产品打死事大。

产品验收

迎接可能的返工。

上线

上线注意各类细节，例如数据库变动，是否须要热缓存，灰度或者预发布后是否须要 cms 添加某些基础数据等等。

上线前请提供回滚方案。

整理必要的文档

文档记录下各类连接（需求文档、技术评审、 api），主要的实现，需求的变动便可。

正常状况下，上完线就结束了，也没有人会作这一步，可是若是后端作掉这一步的话，以后维护起来就会节省不少看代码思考逻辑的时间。

后记

请尊重项目的 deadline。