前言

引用文章：

• https://blog.51cto.com/u_15073468/2795253 （读后感ps：详细完整）
• https://www.cnblogs.com/Formulate0303/p/15830177.html (读后感ps：简明扼要)

本文基于某锋教育的课程以及引用文章对关于项目开发的流程进行知识的梳理和笔记，如有错漏，欢迎评论指出，以下为本文的思维导图

一、项目开发目的分析与确定

在开发商将开发项目确定下来之后，需要与需求方进行讨论，确定需求方对于软件开发需要实现的目标及其具体需要的功能等等，并进行可⾏性分析（技术、成本、法律法规），如果项目立项并进入项目启动阶段，那么代表着活儿来咯！

项目启动阶段首先需要明确项目的目标、项目开发的阶段划分、项目的组织结构等关键事项。
开会进行介绍项目是什么？这个项目的目标是什么？这个项目的具体阶段划分比如项目周期多久？这个项目谁谁谁干什么？考虑清楚每个人的行动规划，大家达成一致并记录规划。

二、需求分析

需求分析是为项目开发的正常进行确定具体思路的阶段。在项目启动后，必须要对客户需要实现的产品功能需求进行具体详细的分析。同时应当考虑在开发过程中可能出现的变化情况，制定需求变更计划随时应对特殊情况的发生，保证开发流程的顺畅进行。

需求分析主要分为用户需求和产品需求两部分。

1、用户需求

用户需求由用户提出，对技术一般不描述，只描述产品目标。
产品需求是根据用户需求转化而来的技术实现需求，需要针对用户提出的产品目标进行细分，总结出具体的每一个功能点，再针对每一个功能点细分为各种不同的操作流程，对每一个操作流程进行技术化定义。

2、产品需求

产品需求一般包括产品需求规格说明书和产品需求矩阵。
产品需求矩阵一般按照子系统、功能集、执行单元的结构列出所有的功能需求，每列则对应每项功能的工作步骤以及每个步骤的工作量。产品需求写完后，需要进行产品需求评审。
产品需求评审在需求评审会上，产品、技术详细评审需求是否完整，产品功能的正常场景是什么？是否形成闭环？异常场景是什么？是否考虑周全？需求评审后，开发和测试负责人，分别编写技术方案和测试用例,准备技术方案评审
技术方案评审开发负责人拉上涉及到其他系统的负责人一起讨论，技术方案中必须要有业务流程图和时序图，业务流程图是为了梳理开发对业务的理解，是否和需求一致。时序图是了梳理本次需求涉及的系统交互。技术方案评审通过后，确认工作量和交付时间，反馈给产品。

三、产品设计

产品设计要根据上一阶段对软件功能需求分析的结果，来设计软件系统的框架结构、功能模块和数据库等等。分为总体设计和概要设计以及详细设计三个部分

1、总体设计

总体设计的目标主要是对待开发系统的构架进行分析和设计，并建立系统构架的基线，以便为之后的实施工作提供一个稳定的基础,也就是常说的架构设计（技术选型、架构模式、项⽬搭建）

2、概要设计

概要设计的目的是描述系统的每个模块的内部设计，对总体设计和详细设计承担承上启下的作用。

3、详细设计

详细设计就是依据概要设计阶段的分解，设计每个模块内的算法、流程，为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。
产品设计阶段主要完成的任务就是：

• 架构设计
• 数据库设计
• UI设计
• 业务流程设计
• 详细设计
• 实现步骤（业务流程的实现细节）

详细设计和实现步骤这个阶段，各个模块可以分给不同的人去并行设计。设计者的工作对象是一个模块，根据概要设计赋予的局部任务和对外接口，设计并表达出模块的算法、流程、状态转换等内容。这里对接下个阶段的分组开发。

四、编程开发

根据产品设计阶段将软件系统的各个部分的具体设计方法、逻辑、功能采用文字方式进行表述的设计文档，编码人员原则上严格按此进行代码实现即可。
所以编程开发阶段是根据软件设计，将软件设计的各部分需求通计算机程序代码来实现运行，编程有统一、规范的程序编写规则，保证软件程序的易懂性、易维护性。

1、分组开发

分组开发在架构设计完成后，编程开发可以分配任务开发，由于未来可能主要做某分组中的开发工作，所以这里笔墨多一点点。编写代码可以遵循以下几点原则：

• 先做核心模块的压测：很多程序员，习惯把东西做完，然后等着快上线的时候才做性能测试，那么如果前面设计出了问题，这个就很头大了。当然，后期快上线的时候也要做性能测试，但前期的我认为还是很重要的。当然，做好这一点，需要懂一些业务，你要知道业务压力在哪里，业务请求的重心在哪里，很多时候，产品经理不讲，你也要问清楚。

• 确保过程可控：代码执行时一定要保持中间的输出，比如说，每处理 10 万条日志，写一条状态日志，记录处理的日志条目数和当前的执行时间。

• 多打日志：很多时候，代码写的自己也不是很满意，比如某个处理效率不够优化，某个处理的方法不够简洁，或者扩展性比较差，代码写的很弱智，但可能短时间没有办法想清楚最合理的解决方案，考虑到上线初期这里并不是重心所在，所以也不会特意去优化它，但这种情况下我往往会留下注释，并说明下一步优化的可能思路是什么，或者想到的可行方案是什么。

• 简单易懂的逻辑：千万不要把自己绕进去了，时间一长，谁都看不明白你的逻辑。如果逻辑真的很难在一个函数内完成，尝试切分。

• 不要沉迷于框架：框架最大的问题是什么？是过于繁冗的嵌套。为什么我一直很烦框架？因为经常遇到需要一秒钟几千次请求的处理场景，那么调优的时候，要从数不清的框架中寻找数据处理的逻辑，寻找性能卡点，可能改动代码只有两行，但是找问题需要两天。程序员记住，你的技术能力绝对不能被框架约束住。

• 使用熟悉、成熟的技术：很多人根本没搞明白自己的障碍和问题在哪里，根本不知道相关技术产品的优势和劣势在哪里，看一堆第三方的数据测评，脑子一热，去学新技术，然后，掉进坑里出不来，如果是创业公司，可能项目就死在里面了。使用新技术前，建议全面了解该技术的特征，适用范围，以及不适用的范围。

2、代码审查

代码审查随着分组开发的推进，在团队中进行代码审查(Code Review)可以提升代码质量，分享项目知识、明确责任，最终达到构建更好的软件、更好的团队，直到最终完成产品的开发。

ps:什么是“单元(Unit)”。所谓“单元”指的是代码调用的最小单位，实际上指的是一个功能块(Function)或者方法(Method)。所以单元测试指的就是对这些代码调用单元的测试。

单元测试是一种白盒测试，就是必须要对单元的代码细节很清楚才能做的测试。所以，单元测试的编写和执行都是由软件工程师来做的。这里对接下一阶段的单元测试。

五、产品测试

在根据设计将客户软件需用编程代码来实现之后，也就是软件程序完成之后，需要对编写的程序，形成整体构架、功能进行单元、组装、系统三阶段的测试，以测试程序编写的正确性，以及对客户需求功能满足的充分性，以此来确定软件是否达到开发要求，同时也是一个发现问题、纠正问题的过程。

相对于单元测试，还有集成测试。集成测试基本都是黑盒测试，主要是由测试人员根据软件的功能手册来进行测试，需要有专门的测试环境配合。集成测试又分功能测试、回归测试等。

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

六、产品发布

软件开发流程通过以上核心环节完成了软件开发，接下来就是在软件开发达到客户需求之后，开发者将软件系统交予客户，并将软件安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等产物交付给客户；

同时指导客户进行软件安装、以及安装技巧，提醒客户注意软件运行状况、环境、服务器及相关中间件的检测与注意事项，知道客户软件的实际操作方法、使用流程等等问题，实现合同规定任务。

在产品发布之后，还要对整个开发过程进行复盘，总结项目经验教训的目的，在于总结问题、分析原因，避免以后犯同样的错误。

七、项目的验收与维护

用户在接收开发商交付的软件开发结果，并进行实际操作、测试运行，实现满意结果之后，对开发出来的软件进行验收。

定制开发的软件通常都需要提供售后服务，定期对软件进行维护，或者根据用户出现的新需求，进行应用软件程序的修改，使之不断满足客户实际需求。

总结

在梳理笔记的过程中，找到自己的位置，明确自己在整个项目中的主要定位，初入职场的定位主要在于第四部分也就是编程开发，乘上的是架构的详细设计，起下的是测试的单元测试，与此同时，在项目的启动阶段和项目发布阶段以及后期的维护阶段可能参与其中。