软件研发流程：标准化与互联网精神的平衡之道

菏泽炫佑科技

软件研发流程：标准化与互联网精神的平衡之道

写在前面

*近我写了两篇关于技术管理工作的文章，分别是《》和《》，另外还通过一篇文章《》回复了网友们提出的问题。

今天我们回归主题，继续技术管理工作第三篇，主要讲一下软件开发流程。

说到软件开发流程，有些同学可能会看不起这种标准化流程，认为直接开始写代码就是*好的，需求可以放在后面再明确，设计是完全没必要的步骤，不然会感觉太慢。他们把这叫做互联网软件开发的精神。互联网软件开发的精神是什么？开源共享、模块化编程、极客精神，而不是野蛮开发。

我在看《我们来聊聊架构》这本书的时候，写过一篇评论，感叹终于有一本可以看很久的架构书了，而不是那些1、2个小时就能看完的所谓**牛逼的架构书。我们经常会遇到这样的面试官，如果你让他画一下整体的架构图，他很可能连听都没听说过。如果你换个问法，问他用了哪些框架，他立马会告诉你SSH、Spark、Mesos，一大堆，但是你让他画架构图的时候，他就会很迷茫。当然你更别指望他去思考为什么并行计算模型在Map和Pull之间采用Pull模式，而不是Push模式？为什么会出现Spark？这些问题我会在后续的文章中讨论。这里我只想说，其实这些框架的出现，都是源于研发过程中发现架构设计环节的问题，以及逐渐积累的解决方案。

以基线产品开发流程为例

一般来说，企业在开发软件时，会以基线和定制两种方式并行开展项目开发工作。无论是什么公司，都需要遵循成熟的产品开发流程体系，才能做出优质的产品。因此，如果项目较多，应该合理安排基线和定制之前的里程碑，让基线产品尽可能多地收集用户的共同需求，为定制项目的进度提供技术支持，减少定制项目出现大规模代码变更和需要增加新模块的情况。另外，产品开发流程体系也需要根据业务的实际时间要求而变化。管理上不要拘泥于瀑布法，也不要拘泥于敏捷法，凡事都要找到适合自己的方法，鞋子合不合脚，只有脚才知道。

我们以一个基线产品开发流程作为流程阐述的基础。需要注意的是，对于下文描述的每一个阶段，在项目执行前，需要明确每个阶段的目标，明确计划，及时沟通，确保所有成员对每个阶段的项目有一致的理解。

启动会议

项目启动会的目的是明确产品开发项目的目标。目标并不是孤立存在的，目标和计划是相辅相成的，目标引导计划，计划的有效性影响目标的实现。所以在执行目标的时候，大家一定要考虑自己的行动方案，如何更有效地实现目标。否则，目标越不明确或者太高，越会影响项目的实际结果。

项目启动会需要对项目目标、阶段划分、组织架构、管理流程等关键问题进行阐述，将这些内容写成PPT（*好有固定的格式和模板，以便团队或公司能一起遵循标准），大家需要达成共识。对于关键角色的任命，也需要提前听取相关领导和关键项目干系人的意见。

用户需求

在开始软件开发之前，需要确定所付出的成本和获得的价值，也就是ROI(On)。一旦确定需要创建，就需要安排一系列的资源来支撑软件的生存。这是对需求*原始的描述。

为什么既需要用户需求，又需要产品需求？因为这两者是有区别的。用户需求是用户提出的，一般不描述技术，只描述产品目标。产品需求是用户需求转化成的技术实现需求。需要将用户提出的产品目标进行细分，归纳出每一个具体的功能点，再将每一个功能点细分成各种不同的操作流程，并对每一个操作流程进行技术上的定义。

用户需求和产品需求很容易出现差异，这是因为虽然大家都在谈需求，但出发点可能不一样，导致双方的关注点和思维方式也不同。用户需求关注系统如何支持业务流程，底层需求是“实现业务目标”。技术人员关注的是合理的技术方案，底层需求是“工作量”、“实现难度”、“系统性能”。

产品需求

我们要搞清楚产品经理或者项目需求提出者为什么要做这个项目，这个是*本质的业务需求，需求分析确定的业务需求都是源于业务需求，必须服务于业务需求。

产品需求一般包括产品需求说明书和产品需求矩阵，产品需求矩阵一般按照子系统、功能集、执行单元的结构列出所有功能需求，每列对应每个功能的工作步骤及每步的工作量。

产品需求写好之后，需要进行需求评审。需求评审会上，产品和技术部门会详细评审需求是否完备。产品功能的正常场景是怎样的？是否形成闭环？异常场景是怎样的？是否考虑周全？

需求评审后，开发和测试负责人会分别撰写技术方案和测试用例。技术方案评审时，开发负责人会和涉及的其他系统负责人进行讨论。技术方案必须包含业务流程图和时序图，业务流程图是为了理清开发对业务的理解，是否和需求一致，时序图是为了理清这个需求涉及到的系统交互。技术方案评审通过后，确认工作量和交付时间，并反馈给产品。

总体设计

设计阶段的目标主要是分析和设计所要开发的系统的架构，建立系统架构的基线，为后续的实施工作提供稳定的基础。

设计阶段包括系统架构的输出，好的系统架构设计可以帮助人梳理业务逻辑、把握核心需求，设计出稳定、可扩展的业务系统，评估业务开发周期和开发成本，有效规避风险。比如盖房子，需要建筑图纸，有了图纸才能算出施工周期。

总体设计是整个系统的框架设计，意义重大，一般情况下不能省略（只有维护项目可以省略总体设计，因为基准项目已经设计好了）。所有产品开发项目都需要先进行总体设计，这是设计的首要步骤，绝对不能本末倒置，不能先编码后设计。这是软件开发的第二大痛点（**是需求不明确，随意更改需求）。

总体设计分为三个阶段：

摘要设计

概要设计的目的是描述系统各个模块的内部设计，它起着总体设计和详细设计的承接作用。

概要设计是按照结构化设计方法进行设计的。结构化设计方法的基本思想是：根据问题域，将软件逐步细化，分解成不需要进一步分解的模块。每个模块完成一定的功能，服务于一个或多个父模块（即接受调用），同时也接受一个或多个子模块的服务（即调用子模块）。模块的概念对应于编程语言中的子程序或函数。

在概要设计阶段，将软件按照一定的原则分解成模块级，给每个模块分配一定的任务，并确定模块间的调用关系和接口。

此阶段设计人员会粗略考虑并处理模块的内部实现，但不会过多地纠缠于此。重点主要放在模块划分、任务分配、调用关系定义上。模块间的接口和参数传递在此阶段必须制定得非常仔细和清晰，并需要编制严谨的数据字典，以免在后续设计中产生混淆或误解。概要设计一般不是一蹴而就的，而是需要反复进行结构调整。典型的调整是合并功能重复的模块，或者进一步分解可重用模块。在概要设计阶段，应尽可能地提取可重用模块，建立合理的结构体系，节省后续环节的工作量。

概要设计书*重要的部分是分层的数据流图、结构图、数据字典以及相应的文字说明等。基于概要设计书，可以并行进行各个模块的详细设计。

详细设计

详细设计阶段是在概要设计阶段分解的基础上，对各个模块内的算法、流程进行设计，并对各个模块所实现的功能给出具体的描述，以便将功能描述转化为精确的、结构化的过程描述。

在详细设计阶段，可以将各个模块分配给不同的人进行并行设计。设计人员的工作对象是模块，按照概要设计分配的局部任务和对外接口，设计并表达模块的算法、流程、状态变迁等内容。这里要注意的是，如果发现有需要进行结构调整的地方（如分解子模块等），需要回到概要设计阶段，在概要设计文档中反映调整情况，不能不经通知就当场解决。详细设计文档中*重要的部分是模块的流程图、状态图、局部变量及相应的文字说明。一个模块对应一份详细设计文档。

软件结构图通常在概要设计阶段得到，详细设计阶段常用的描述方法有：流程图、NS图、PAD图、伪代码等。详细设计的目的是描述一个模块内的处理流程、开发方法和编码技巧。一般来说，详细设计由项目介绍、模块描述（具体描述每个模块内部的流程、功能、逻辑、消耗、未解决的问题）、接口设计（包括内部接口和外部接口）、数据结构设计（包括物理结构和逻辑结构）、特殊处理等几部分组成。软件的详细设计*终将软件系统各部分的具体设计方法、逻辑和功能以文字表达出来。这样，在实现过程中，编码人员就可以严格按照这个原则来实现代码。

编写代码

编写代码时可以遵循以下原则：

先做核心模块的压力测试：很多程序员习惯在快上线的时候把事情做完再做性能测试，如果之前的设计有问题，这个就很头疼了。当然产品快上线的时候也要做性能测试，但是我觉得前期还是很重要的。当然要做好这个事情需要懂一些业务，要知道业务压力在哪里，业务请求的重点在哪里，很多时候就算产品经理不告诉你，你也要问清楚。 确保流程可控：代码执行的时候，一定要保留中间的输出，比如每处理10万条日志，写一条状态日志，记录处理的日志条数和当前执行的时间。 多日志：很多时候，自己对自己写的代码并不是很满意，比如某个处理的效率优化的不够，某个处理的方法不够简洁，或者扩展性比较差。 代码写得很蠢，但是可能短时间内没有办法想到*合理的解决方案，考虑到这不是上线之初的重点，所以我不会刻意去优化，但是这种情况下我经常会留下评论，说明下一步优化的可能思路是什么，或者我想到哪些可行的方案。简单易懂的逻辑：不要把自己搞得一头雾水，时间长了，没人能看懂你的逻辑。如果逻辑确实很难在一个函数内完成，那就试着拆分一下。不要迷恋框架：框架*大的问题是什么？嵌套太繁琐。我为什么总是被框架烦到？因为我经常会遇到每秒需要上千个请求的处理场景，调优的时候要从无数的框架中寻找数据处理逻辑和性能瓶颈。可能只改了两行代码，却要花两天时间才能找到问题所在。程序员记住，你的技术能力一定不能被框架束缚。 使用熟悉且成熟的技术：很多人完全不了解自己的阻碍和问题，也不知道相关技术产品的优缺点，看了一堆第三方数据评测，兴奋不已，就去学新技术。然后，掉进坑里出不来。如果是创业公司，项目可能死在里面。在使用新技术前，建议充分了解该技术的特点，适用范围，不适用范围。代码审查

众所周知，团队中的代码审查可以提高代码质量，共享项目知识，明确职责，*终打造更好的软件和更好的团队。

Code 极其重要，一般每周做一次就行。首先，Code 可以帮你跟踪项目的进度，我们可以真正看到手下的人进展如何，更早发现他们是否误入歧途。有时候，手下的人会说“快完成了！”，但是当你看代码的时候，却发现什么都没有或者只是一堆垃圾等等。总之，还远远没有完成。在管理上，这种情况是*让人讨厌的，所以我觉得 Code 是避免这种麻烦的*好方法。

单元测试

要理解单元测试，首先要明白什么是“单元”。所谓“单元”，是指代码调用的*小单位，其实就是指函数块（）或者方法（）。所以单元测试就是指对这些代码调用单元的测试。

单元测试是白盒测试，也就是说必须清楚了解单元代码细节才能进行。因此，单元测试的编写和执行都是由软件工程师完成的。与单元测试相比，还有集成测试。集成测试基本是黑盒测试，主要由测试人员根据软件功能手册进行，需要专门的测试环境。集成测试又分为功能测试、回归测试等。

需要进行单元测试的代码其实是开发人员自己编写的逻辑，测试逻辑所依赖的环境是否正常并不是单元测试的目的。在环境访问代码中引入逻辑只会让逻辑更难测试，导致无法对逻辑代码进行单元测试。所以只有可单元测试的代码才可以进行单元测试。判断可测试代码的另一种方法是看方法是否能用一个main函数直接运行，如果能，那就是可单元测试的代码。可测试代码的另一个特点是方法单元的参数可以由开发人员自由模拟，不依赖外部环境。

集成测试

集成测试又称组装测试或联合测试，是在单元测试的基础上进行的。将各个模块按照设计要求组装成子系统或系统进行集成测试。实践表明，虽然有些模块单独可以工作，但连接起来后并不能保证正常工作。一些在局部无法体现的问题，很可能会暴露在全局。

集成测试是在软件系统集成过程中进行的测试，其主要目的是检查软件单元之间的接口是否正确。按照集成测试计划，在系统运行的同时，将各个模块或其他模块组合成越来越大的系统，分析所组成的系统是否正确，各个组件是否同步。集成测试的策略主要有两种：自顶向下和自底向上。也可以理解为在软件设计单元和功能模块组装集成为一个系统时，对应用系统的各个组件（软件单元、功能模块接口、链接等）进行的联合测试，以确定它们是否可以协同工作。组件可以是代码块、独立的应用程序、网络上的客户端或服务器程序。

系统测试

系统测试阶段包括系统测试计划和用例编写、功能测试、性能测试、稳定性测试。

为了验证需求分析确定的功能是否完整并正确实现，还应对安装、部署、适配性、安全性、接口等非功能性需求进行测试。系统测试也是测试人员的职责，应在需求分析完成后进行设计，在集成测试完成后实施。

功能测试一般由独立的测试团队采用黑盒测试方法进行，主要测试系统是否符合“需求规格说明书”。经过以上测试和确认阶段后，通过完全模拟客户环境对系统进行测试。系统测试结合已确认的软件、计算机硬件、外设、网络等要素，对信息系统进行各种组装测试和确认测试。其目的是通过与系统需求进行比较，发现开发的系统在哪些地方不满足或与用户需求相矛盾，从而提出更完善的解决方案。

性能测试验证系统的稳定性和效率，检查系统是否满足规定的性能要求。性能测试通常选取一些典型功能，检查系统在大量用户同时使用系统时是否稳定。性能测试是测试人员的职责软件研发流程：标准化与互联网精神的平衡之道，可以在系统测试完成后进行，也可以先对重要模块进行性能测试，可以贯穿整个测试周期，目的是尽早发现系统的性能瓶颈，并尽早解决。

无论是稳定性测试还是性能测试，都必须在系统基本没有问题、稳定的情况下进行才有效。否则，测试很难顺利进行，而且一旦出现异常也很难判断是系统架构问题还是功能缺陷。

稳定性测试（又称可靠性测试）通过给系统加载一定的业务压力，让系统连续运行一段时间（一般为7x24小时），来测试系统是否能稳定运行。

产品发布

产品发布是系统测试完成后的*后一步，通常在软件产品开发过程中，不需要进行产品试产，产品直接上线即可，系统测试人员只需要输出系统测试报告，并批准产品发布（上线）即可。

在产品发布前，需要召开产品发布会，回顾从项目启动开始的整个产品研发过程，指出整个过程中的不足，总结经验，为下一个项目提供经验案例。这个会议可以以正式会议的形式召开，需要召集产品经理、主研、测试人员、上级领导参加。需要充分准备，在发布后尽可能多地讲解产品的效果和收益，为上线后的价值评估做准备。这个环节不可或缺，即使在迭代速度很快的互联网公司，这个环节也是需要满足的。

开发过程回顾

其实在开发流程体系中是没有这个流程的，但是我个人觉得这个流程非常重要。

所有的总结都是带着问题去思考才能得到，也就是复习。不管我说了多少，如果你没有过类似的经历，很难有强烈的共鸣。我觉得看清一个问题的*好方式，就是曾经站在过这个问题的两个不同的角色中。

总结项目经验教训的目的是为了总结问题，分析原因，避免以后再犯同样的错误，而不是找人来责怪。

假设在需求阶段发现对需求理解的缺陷，可能只需要一个小时就能修改。但如果在设计完成时发现缺陷，由于涉及的人员和文档增加，可能需要一天时间。如果在写完代码后才发现缺陷，可能要十天、八天。如果缺陷没有被发现，而是直接到达生产系统怎么办？这不算工作量问题，预计损失也很难估计。在质量管理理论中，发现每延迟一个阶段，修复缺陷的成本就会增加十倍。

*后的想法

敏捷开发、极致开发等模式软件开发，都是为了解决需求不明确、时间紧迫的情况下快速迭代的问题，而不是从根本上否定研发流程。设计还是要设计，但要划分生命周期，把流程水平划分成几个循环。软件开发是一门学科，工程要求非常严谨。让我们坚持严谨的态度和高效的工作方式，打造高可用、高质量的软件产品。

关于作者

周明耀 2004 年毕业于浙江大学，获工学硕士学位。拥有 12 年外资投行工作经验、4 年分布式系统及物联网工作经验、10 年技术团队管理经验。IBM 开发者论坛专家作者、Infoq 专栏作家。出版过《Java 性能优化》、《深入理解 JVM 及 G1 GC》等书籍，即将出版《技术领导力——如何领导一个软件开发团队》一书。在分布式计算领域已提交超过 15 项发明专利。微信 ID：

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等