总体研发流程图

首先这是我们研发类项目的标准流程图，基本上所有项目从开始到完成都要经历这4个阶段，当然，有标准的地方就有人违反标准，大家在实际工作过程中难免会遇到赶工期而压缩流程的情况，以什么样的心态来面对这个问题将是你们未来道路上要做出的无数选择。

一、产品阶段

这个阶段产品汪牵头，程序猿尽量参与，了解需求。

需求调研

调研需求背景，分析原始需求，与客户沟通，制定整体方案的过程

其实就是产品汪去搞清楚为什么要做这件事，能不能做，投入产出是否有价值，这里有两点必须强调：

1.产品经理不要关起门来YY，一定要和客户接触，要拿真实数据说话（没有数据就先做数据采集），运营类的产品一定要站在使用者的立场上亲自把运营流程走一遍，要把自己当成第一个用户
2.一定不要客户说什么就做什么，更不要把客户说的话和邮件作为事后推脱的证据（你当初就是这么说的所以我才做成这屎样），大部分客户只能从片面的直观感受的角度提要求，产品经理要有独立分析和说服客户的能力，否则那不叫产品经理，叫复读机

如果项目规模足够大，这一阶段需要产出需求分析文档；对于大部分的普通项目，以邮件形式记录需求沟通结果即可。

产品设计

产品的详细设计过程，包括产品流程，功能描述，界面设计

产品设计的产出物为产品设计文档，全新产品或已有产品添加新功能时必须有界面原型设计

产品设计文档以产品为单位，每个产品一份，功能变更时在原有文档上维护

现实情况是公司大部分的产品都缺少文档，有的也是零碎和过期的片段，后续工期紧也没有时间补文档，导致大家对文档不重视，尽管如此，还是要求各位产品经理尽可能的写设计文档，因为产品设计是所有设计的起源，研发文档、测试文档、项目进度文档等即使没有或者遗失了都可以从产品设计来追溯。

传统软件工程的产品设计文档早已经不适合这个时代了，复杂的格式和繁琐的变更流程是扼杀写文档动力的最大凶手，希产品汪们能够以写有用的产品文档为目标，在设计过程中继续精简模板和流程，在XXX的产品史上留下你们的爪印。

二、研发阶段

概要设计

“概要”是针对产出文档而言，这一阶段应该把模块划分、实体和状态、服务接口、接口调用时序、核心流程都确定下来，文档尽量精简，遵循少即是多的原则，只写重要的部分，这样也易于变更维护

产出文档以子系统为单位，每个子系统写一份概设文档，一些复杂的系统群可以合并成一份概要设计，以后的变更都在原文档上维护。

有人觉得写技术设计文档的目的就是为了符合公司流程，报有这种想法的同学，我代表月亮批准你可以不写任何设计文档，把全部时间和精力都放在代码上吧，因为穷尽你所有的智慧努力到虚脱抽搐可能都写不出一段漂亮的代码

写设计文档最大的目的在于**提升自身设计能力，**有人估计会说你骗谁啊为了忽悠我们写文档居然编出这种没水准的理由，好吧我承认这里有忽悠的成分，但这也是爱的忽悠，你们看别人的代码（或者自己年轻时的代码）是不是经常有“这写的什么鬼”的感觉，实现一个功能和优雅的实现一个功能是两码事，遗憾的是计算机还没有进化出审美能力，就算你写的代码恶心的像坨屎它也只会照单全收，但是人不一样，当你把屎一样的代码通过设计文档用人类自然语言表达出来的时候，你会先恶心到你自己，再恶心到你的同事。设计的过程就是强迫你不断提炼和精简编码逻辑的过程，设计文档的好坏体现的不是文档能力而是设计能力，能否把你的设计清晰有条理的表达出来，决定了你能否说服团队按你的思路作战，这是迈向老鸟大神的必经之路。

最后，关于设计，再强调两点

1.不要想着一次设计充分到位，在一些模棱两可的方案上快速尝试，不要害怕尝试和返工所浪费的时间，它比反复纠结所浪费的时间要少的多和有价值的多

2.不要急着动手，想明白了再写，甚至可以先写注释再写代码，这些都是很好的习惯，不要写到哪儿想到哪儿，正常情况下思考所用的时间应该是敲代码的两倍以上，不要写完了代码在事后补设计文档，这一条和上一条不冲突

编码

编码对程序猿来说就像吃香蕉一样简单，没什么可说的，列一些相关规范文档吧

单元测试

使用junit或其他类似工具对类方法进行测试，单元测试最大的价值是“可重用”和“自动化”，考虑到时间精力有限大家还要回去撸啊撸就不对覆盖率提要求了，只测service层吧

“不要在单元测试上偷懒”请跟我把这句话念10遍，当你一口气改完几十个类文件然后执行一个测试命令几秒内跑完所有用例，满屏的绿条给你带来的快感会让你瞬间升入天堂

有人说我不写单元测试在集成环境上一样能测，你能够忍受频繁的“修改-》发布-》重启-》测试”我表示佩服你的耐心，但我绝对不相信你会把可能被影响的相关功能也回归测一遍，估计你连哪些地方被影响都想不到 ，眼光放远一点点，在全面回归上，单元测试的性价比绝对值得回票

还有人说我艺高人胆大从来不测试直接上QA，呵呵，千万不要被我逮到，我保证不打死你

集成测试

别问我，我也不知道为什么叫“集成”，可能是因为这个测试环境是集各子系统之大成吧

其实就是把代码部署到tomcat上测试，因为三代的SOA架构下可能需要部署多个子系统相互调用才能测，所以就单独开辟了一个环境，这套环境配置齐全设施完善，各子系统和组件都有，用的舒心测的放心，称之为“集成环境”，其他独立上线的项目也可以自己搭建集成环境

另外，不一定所有服务都要在集成环境上调试，你把修改的代码部署到自己机器上的tomcat，把其他接口调用指向集成环境也行

集成测试目前还只能手工测，谁有想法做一套自动化工具的请联系我。

三、QA阶段

XXX技术中心有个传说，程序猿最幸福的时刻就是上QA，但没有人知道QA是谁~

上QA其实是场心理战，技术说我的代码没问题了可以提QA，测试说你确定没问题（升调高8度带鄙视属性的疑问句），一般的程序猿就会败下阵来说那我再回去测测，二班的就会说绝逼没问题尽管放马过来

写到这里我突然发觉画风有点凌乱有必要修正一下，QA测试是由质量人员对研发交付的代码进行验收测试的过程，验收过程中发现的BUG将作为对研发结果的考核因素之一，只有验收通过才允许上线

所有项目进入QA阶段前，需要先提交OP工作单：xxxx

技术负责人和研发人员提单前先要了解流程并申请相应权限。

QA部署

新项目进入QA阶段前，技术负责人需要提前和测试或配置人员沟通确定部署方案（放在哪台机器、哪个tomcat）

QA测试

测试人员在QA环境对项目进行验收测试，通过后才能上线

测试人员在开始QA测试前应先写用例文档，以产品为单位，每个产品维护一份测试用例文档

四、上线阶段

上线是整个研发过程中最让人兴奋的环节，所有的努力，所有的灵感都将在这一刻登上舞台；上线也是整个研发过程中最危险的环节，所有缺陷，所有隐患，也将在这一刻面临真实世界的考验，当你迈出上线这一步时，永远不知道落脚的是天堂还是地狱。

装逼结束，下面开始说人话，为确保上线稳定，需严格执行以下流程：

1.上线评审

邀请各路诸侯做为评委共聚一堂，上线人依次描述上线内容，评委确认是否存在风险，通过后方可上线，未通过的项目按要求打回整改再评；
在正常规定时间以外上线，需要提紧急上线申请，CTO以邮件或电话等形式审批通过后方可上线

2.发布内测

所谓内测即是在生产环境中划分出一块公司测试人员可访问的区域，每次上线把最新的代码先发布到这个区域，让测试人员在正式发布前先在生产环境测试内测环境也是生产环境的一部分，共用相同的数据库，所有功能与最终发布的效果完全一致，这里是测试的最后一道关卡，是项目质量的诺曼底防线

内测发现BUG，属于QA阶段测试疏忽，原则上应退回到QA阶段重测（汉语里面出现‘原则上’这三个字的时候就意味着会有很多违背‘原则’的情况），实际上根据项目的紧急程度，会允许项目组二次上线，修改代码后重新发布到QA和内测
有些项目负责人灰常不负责，赶进度压缩QA时间，把内测当QA，随意要求二次上线，哥还是那句话，保证不打死你
还有些项目情况特殊，QA环境无法测试，只能等上了内测验证，例如依赖银行网络专线的系统，提前举手报告老师，美丽姐会尽量通融
通常每周三上午发布内测，根据项目数量，内测时间将持续到傍晚甚至夜间
紧急上线项目也需要先发布内测
有些项目附带数据库变更，例如加个表扩个字段、插入初始化数据，默认情况下，数据库变更操作在代码发布内测前执行，如果有特殊要求一定记得在上线单里写明白，比如要求全部代码都对外了再执行初始化数据SQL

3.正式对外

内测通过以后，代码统一发布到正式环境，所有用户将访问到我们产品的最新版本
正式对外的时间通常安排在周四上午9点，虽然经历了单元测试、集成测试、QA测试、生产内测等重重把关，但意外在所难免，隐藏在代码深处的BUG总能在最后时刻发起致命一击，为了应对这种情况，所有上线的技术负责人必须在正式对外前到达公司，摆好正确的姿势预备可能发生的任何意外。
对外后的4小时内为上线警戒期，期间发生监控报警或客户投诉优先考虑回滚。