周明耀：软件研发的流程问题（四）

菏泽炫佑科技

周明耀：软件研发的流程问题（四）

作者｜周明耀

编辑| 小智

本文是周明耀技术管理专栏的第四篇文章。 今天我们主要讲一下软件开发的流程。

写在前面

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

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

说到软件开发流程，有些同学可能会看不起这个标准化的流程。 他们认为无论情况如何，立即开始编码才是正确的方法。 需求可以稍后再明确，设计是完全不必要的步骤，否则会感觉很快。 太慢了，他们称之为互联网软件开发的精神。 互联网软件开发的精神是什么？ 开源共享，模块化编程，极客精神，而不是野蛮开发。

我在读《Let’s Talk 》这本书时，写了一篇读后评论。 我感叹终于有一本可以读很久的建筑书了，而不是所谓的1、2小时就能读完的牛逼建筑书。 。 我们经常遇到这样的面试官。 如果你让他画一个整体架构图，他可能根本没有听说过。 如果你换个问题问他用什么框架，他会立刻告诉你SSH、Spark、Mesos。 ，很多，但是当你让他画架构图时，他就会不知所措。 当然，你别指望他会思考为什么并行计算模型在Map和之间使用Pull模式，而不是Push模式？ 为什么会出现Spark等等？ 我将在后续文章中讨论这些问题。 这里我只想说，其实这些框架的出现，源于研发过程中架构设计过程中发现的问题以及逐渐积累的解决方案。

以基线产品开发流程为例

一般情况下，企业在开发软件时，会以两种并行的方式进行项目开发工作：基线和定制。 无论什么公司，都需要遵循成熟的产品开发流程体系，才能生产出更优质的产品。 因此，如果项目较多，应合理安排定制前的基线和里程碑，使基线产品能够收集尽可能多的用户通用需求，为定制项目的进展提供技术支持，减少大量的定制工作。定制项目中的代码更改。 ，需要添加新模块。 另外，产品开发流程体系也需要根据业务的实际时间要求进行改变。 不要拘泥于瀑布方法或敏捷方法。 一切都需要以适合您的方式进行管理。 鞋子合不合脚，只有你的脚知道。

这里我们使用基线产品开发流程作为流程解释的基础。 需要注意的是，对于下面描述的每个阶段，在项目执行之前，必须明确每个阶段的目标，明确计划，及时沟通，并确保每个阶段的所有成员都充分了解该项目。 一致的理解。

启动会议

项目启动会议的目标是明确产品开发项目的目标。 目标并不是孤立存在的。 目标和计划是相辅相成的。 目标指导计划，计划的有效性影响目标的实现。 因此，在执行目标的时候，要清楚地思考自己的行动计划，以及如何更有效地完成目标。 这是一个大家必须详细清楚的问题。 否则，目标不明确或过高都会影响项目的实际绩效。 结果。

项目启动会需要对项目目标、阶段划分、组织架构、管理流程等关键事项进行说明，并将这些内容写成PPT（*好有固定格式和样本文本，以便团队或项目方公司可共同遵守该标准）。 每个人都需要同意。 对于关键角色的任命，还需要事先听取相关领导和项目关键利益相关者的意见。

用户需求

在开始开发软件之前app开发，需要确定成本与获得的价值之间的比较，即ROI（On）。 一旦确定需要创建，就需要安排一系列资源来支持软件的生存。 这是*原始的需求描述。

为什么我们既需要用户需求又需要产品需求？ 因为两者是有区别的，用户需求是用户提出的，一般不描述技术，只描述产品目标。 产品需求是由用户需求转化而来的技术实现需求。 需要对用户提出的产品目标进行细分，总结每个具体的功能点，然后将每个功能点细分为各个操作流程。 从技术上定义每个操作流程。

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

产品需求

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

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

产品需求写好后，需要进行审查。 在需求评审会上，产品和技术详细评审要求是否完成？ 产品功能的正常场景有哪些？ 是否形成闭环？ 有哪些不寻常的场景？ 是否深思熟虑？

需求评审后，开发和测试负责人分别编写技术方案和测试用例。 在技​​术方案评审过程中，开发负责人召集其他系统涉及的负责人一起讨论技术方案。 技术计划必须包括业务流程图和序列图。 业务流程图是为了梳理开发对业务的理解，看看是否与需求一致。 序列图就是为了梳理这个需求所涉及到的系统交互。 技术方案审核通过后，确定工作量和交付时间并反馈给产品。

总体设计

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

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

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

总体设计分为三个阶段：

外形设计

概要设计的目的是描述系统各模块的内部设计，作为总体设计和详细设计的纽带。

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

在概要设计阶段，将软件按照一定的原则分解为模块层次，赋予每个模块一定的任务，并确定模块之间的调用关系和接口。

在这个阶段，设计者通常会考虑和照顾模块的内部实现，但不会太纠结。 主要是划分模块、分配任务、定义调用关系。 这个阶段模块之间的接口和参数传递必须做得非常详细和清晰，并且需要编写严格的数据字典，以避免后续设计中的混乱或误解。 轮廓设计一般不是一次性完成的，而是需要反复进行结构调整。 典型的调整是合并具有重复功能的模块或进一步将其分解为可以重复使用的模块。 在概要设计阶段，应*大限度地提取可复用模块，建立合理的结构体系，节省后续环节的工作量。

概要设计文件*重要的部分是分层数据流图、结构图、数据字典和相应的文字描述。 在概要设计文件的基础上，可以并行进行各模块的详细设计。

详细设计

详细设计阶段在概要设计阶段分解的基础上，设计各个模块内部的算法和流程，并对各个模块完成的功能进行具体描述周明耀：软件研发的流程问题（四），将功能描述转化为精确的、结构化的流程描述。

在详细设计阶段，每个模块可以分配给不同的人进行并行设计。 设计者的工作对象是模块。 设计者根据概要设计分配的本地任务和外部接口，对模块的算法、流程、状态转换等进行设计和表达。这里需要注意的是，如果发现需要进行结构调整（如如分解子模块等），必须回到概要设计阶段，将调整反映到概要设计文档中，不能不打招呼就当场解决。 详细设计文档*重要的部分是模块的流程图、状态图、局部变量以及相应的文字描述等。一个模块对应一份详细设计文档。

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

编写代码

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

首先做核心模块的压力测试：很多程序员习惯把事情做完然后等到快上线才做性能测试。 如果之前的设计有问题的话，这会是一件很头疼的事。 当然，后面快上线的时候也会做性能测试，但是我觉得前期还是很重要的。 当然，要做好这件事，你需要了解一些业务。 你需要知道业务压力在哪里，业务请求的重点在哪里。 很多时候，产品经理不解释，你就得问清楚。

确保过程可控：代码执行时必须维护中间输出。 例如，每处理10万条日志，就会写入一个状态日志，记录处理的日志条目数和当前执行时间。

日志更多：很多时候，我对自己写的代码不是很满意。 比如某个处理效率不够优化，某个处理方法不够简洁，或者可扩展性比较差。 代码写得很迟钝，但是短时间内可能没有解决办法。 思考*合理的解决方案。 考虑到这不是上线初期的重点，所以我不会刻意优化。 不过，在这种情况下，我往往会留下注释，解释下一步优化可能的思路。 或者想到什么可能的解决方案。

简单易懂的逻辑：不要让自己卷入其中。 久而久之，没有人能够理解你的逻辑。 如果函数内的逻辑确实很难完成，可以尝试拆分。

不要沉迷于框架：框架*大的问题是什么？ 嵌套太麻烦了。 为什么我总是对框架感到恼火？ 因为我们经常会遇到每秒需要数千个请求的处理场景，所以在调优时，我们必须从无数框架中寻找数据处理逻辑和性能卡点。 我们可能只改两行代码，但是发现问题却需要两天时间。 程序员记住，你的技术能力一定不能受到框架的限制。

使用熟悉且成熟的技术：很多人根本不了解自己的障碍和问题在哪里，也不知道相关技术产品的优点和缺点是什么。 在阅读了一堆第三方数据评估后，他们感到兴奋并学到了新东西。 那么技术就掉进了坑里，出不来了。 如果是创业公司，项目可能会死在里面。 在使用一项新技术之前，建议充分了解该技术的特点、适用范围、不适用范围。

代码审查

众所周知，在团队中进行代码审查（Code）可以提高代码质量、共享项目知识、明确职责，*终构建更好的软件和更好的团队。

代码审查极其重要。 一般来说，每周应该进行一次代码审查。 首先，代码审查可以帮助您跟踪项目的进度。 我们可以真正看到我们手下的人进展如何，并尽早发现他们是否误入歧途。 有时，人们会说“快完成了！”，而你查看代码，发现什么都没有或者只是一堆垃圾等等，但它还远远没有完成。 在管理中，这种情况是*烦人的，所以我认为代码审查是避免这种麻烦的*好方法。

单元测试

要理解单元测试，首先必须理解什么是“单元”。 所谓“单元”是指代码调用的*小单元，实际上指的是功能块（）或方法（）。 所以单元测试是指测试调用这些代码的单元。

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

需要单元测试的代码实际上是开发人员自己编写的逻辑。 测试逻辑所依赖的环境是否正常并不是单元测试的目的。 在环境访问代码中引入逻辑只会使逻辑更加难以测试，使逻辑代码无法进行单元测试。 因此，可单元测试的代码可以进行单元测试。 确定可测试代码的另一种方法是查看该方法是否可以使用 main 函数直接运行。 如果是这样，那么它就是可单元测试的代码。 可测试代码的另一个特点是方法单元的参数可以由开发人员自由模拟，而不依赖于外部环境。

集成测试

集成测试也称为组装测试或联合测试。 在单元测试的基础上，根据设计要求将所有模块组装成子系统或系统进行集成测试。 实践表明，有些模块虽然可以独立工作，但并不能保证连接后也能正常工作。 一些无法在本地反映出来的问题，很可能会在全球范围内暴露出来。

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

系统测试

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

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

功能测试一般由独立的测试团队采用黑盒方式进行，主要测试系统是否符合“需求规范”。 经过以上阶段的测试和确认后，系统完全模拟客户环境进行测试。 系统测试是结合已确认的软件、计算机硬件、外设、网络等要素，对信息系统进行各种组装测试和确认测试。 目的是通过将开发的功能与系统需求进行比较来发现它们。 当系统与用户需求不匹配或矛盾时，可以提出更完整的解决方案。

性能测试验证系统的稳定性和效率，检查系统是否满足指定的性能要求。 性能测试通常会选择一些典型的功能来检查系统在大量用户同时使用系统时是否稳定。 性能测试是测试人员的责任。 可以在系统测试完成后进行，也可以先进行重要模块的性能测试。 它可以贯穿整个测试周期。 目的是尽早发现系统性能瓶颈并尽早解决。

稳定性测试和性能测试必须等到系统基本良好稳定后才有效。 否则，就很难顺利测试，也无法判断异常是系统架构问题还是功能缺陷。

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

产品发布

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

产品发布前，需要召开产品发布说明会，追溯从项目立项到产品开发的整个流程，指出整个过程中的不足，总结经验，为下一步的项目提供经验案例。 本次会议可以采取正式会议的形式召开。 需要召集产品经理、主要开发人员、测试人员、上级领导等参加。 他们必须做好充分的准备，并尽力解释产品发布后的效果和好处，以便评估产品发布后的价值。 准备。 这个链接是不可或缺的。 即使在迭代速度很快的互联网公司，这个环节仍然需要满足。

开发流程回顾

其实这个流程在开发流程体系中是不存在的，但是我个人认为非常重要。

所有的总结只有带着问题去思考才能得到。 这是回顾。 不管我说多少，如果没有类似的经历，很难产生强烈的共鸣。 我认为看清问题的*好方法是你在同一问题上扮演过两个不同的角色。

总结项目经验教训的目的是总结问题，分析原因，避免以后再犯同样的错误，而不是追究任何人的责任。

假设需求理解存在缺陷。 如果在需求阶段就发现了，修改起来可能只需要一个小时。 然而，如果在设计完成时发现缺陷，由于涉及的人员和文件增加，预计需要一天的时间。 而如果等到代码写出来的话，可能需要十、八天的时间才能发现这个缺陷。 如果缺陷没有被发现并直接进入生产系统怎么办？ 这已经不是工作量的问题了，估计损失也很难估计。 在质量管理理论中，每晚发现一个缺陷，修复的成本就会成倍增加。

写在*后

敏捷开发、极限开发等模式旨在解决需求不明确、时间紧张时的快速迭代，而不是从根本上否定研发流程。 设计还是要设计的，但是划分了生命周期，将流程横向划分为若干个周期。 软件开发是一门具有严格工程要求的学科。 让我们坚持以严谨的态度和高效的工作方法打造高可用、高品质的软件产品。

关于作者

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

做个广告

2017年，有哪些运维技术热点值得关注？ 智能运维，...全球运维技术大会将于9月在上海召开，12位专家联合出品，揭示*前沿的运维技术，推荐学习！ 点击“阅读原文”抢先看！

今天的推荐

点击下图阅读

使用体验

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