《软件工程——实践者的研究方法》读书笔记02

一、过往实践回顾（结合书中理论对照）

1. 需求分析阶段
   过去开展项目时，我更倾向于口头沟通 + 简单文档记录需求：与客户初步访谈后，仅整理核心功能清单，未形成结构化的需求规格说明书（SRS）；对于需求的优先级划分，依赖个人经验判断，未引入 stakeholder 共同评审，也未使用用例图、场景描述等工具具象化需求。
2. 设计与开发阶段
   设计环节：跳过详细设计步骤，直接从概要设计进入编码，未绘制类图、时序图等设计文档，仅靠脑海中的逻辑框架开发；
   开发实践：采用 “瀑布式” 线性开发，前期投入大量编码工作，中途发现需求偏差或设计漏洞时，只能临时修改代码，缺乏迭代意识；
   团队协作：使用基础版本控制工具（如 Git），但未制定分支管理规范，多人协作时频繁出现代码冲突，且缺乏代码评审环节。
3. 测试与维护阶段
   测试方式：以 “手动黑盒测试” 为主，仅验证核心功能是否可用，未设计测试用例、未开展单元测试和集成测试，忽略边界条件、异常场景的验证；
   维护工作：项目交付后，仅被动响应客户反馈的 bug，未建立缺陷跟踪系统，也未对常见问题进行归纳总结，导致同类问题重复出现。
   二、过往实践的有限优势（辩证看待）
   快速启动项目：口头沟通 + 简化文档的方式，减少了前期需求梳理的时间成本，能快速进入编码阶段，适合小型、需求简单且变更少的项目；
   灵活调整方向：未受严格流程约束，当客户临时提出小范围需求变更时，可快速修改代码响应，短期灵活性较高；
   降低入门门槛：无需掌握复杂的设计工具、测试方法和流程规范，对于经验不足的团队或个人，初期执行难度较低。
   三、基于书籍理论的改进方向
4. 需求工程：从 “模糊沟通” 到 “结构化管理”
   学习书中 “需求获取 - 分析 - 规格说明 - 验证 - 管理” 全流程，采用访谈、问卷调查、场景分析等多种方式收集需求，避免遗漏隐性需求；
   按照书籍要求编写规范的 SRS 文档，使用用例图、数据流图等可视化工具描述需求，确保开发团队与客户对需求的理解一致；
   建立需求优先级评估机制（如 MoSCoW 方法：Must have/Should have/Could have/Won’t have），联合客户、产品、开发团队共同评审，明确开发重点。
5. 设计与开发：从 “无序编码” 到 “工程化实践”
   重视设计环节：遵循书中 “模块化、高内聚低耦合、复用性” 等设计原则，先完成概要设计（架构设计）和详细设计（类设计、接口设计），绘制设计文档后再编码，避免 “边想边写”；
   引入迭代开发模型：参考书中增量模型或敏捷模型，将项目拆分为多个小迭代，每个迭代完成部分功能并进行评审，及时发现设计或需求问题，降低后期返工风险；
   规范团队协作：制定 Git 分支管理规范（如 master/develop/feature/bugfix 分支），执行强制代码评审流程，结合书中 “代码规范” 要求，统一代码风格，提高代码可读性和可维护性。