构建之法阅读笔记02

1、我过去是怎么做的（或者我过去看见谁是怎么做的）

在我过去的学习和项目实践中，编写代码时往往只关注功能的实现，而忽略了代码的可维护性和团队协作的规范性。例如，在大一的团队项目中，我和小组成员分工开发一个简单的学生管理系统。当时，我们几乎没有进行需求分析和设计讨论，直接开始写代码。每个人按照自己的想法随意命名变量、函数，代码风格混乱，甚至没有注释。最终在整合代码时，出现了大量冲突和难以理解的逻辑，导致项目延期，甚至部分功能不得不重写。

此外，在调试和测试方面，我们通常只进行简单的手动测试，比如输入几个样例数据，如果结果看起来正确，就认为代码没问题。没有系统化的测试方法，更没有单元测试或自动化测试的概念。结果在演示时，程序频繁崩溃，暴露出许多未发现的边界问题。

2、结合书中所讲，说明为什么这样不好

在《构建之法》中，邹欣老师强调了软件工程的核心思想：编程不仅仅是写代码，而是一个系统的工程过程。书中提到，良好的代码规范和设计模式是团队协作的基础，而测试是保证软件质量的关键环节。

• 代码规范与可维护性：书中指出，混乱的代码风格和缺乏注释会导致“代码债”（Technical Debt），增加后期维护的难度。我们的项目正是因为缺乏统一的命名规则和文档，导致整合时花费了大量时间理解彼此的代码。
• 测试的重要性：书中强调，没有系统化的测试就像“蒙着眼睛走路”，无法保证软件的可靠性。我们的手动测试方法显然不足以覆盖所有场景，最终导致演示时的尴尬局面。
• 需求分析与设计：书中提到，跳过需求分析和设计阶段直接编码，往往会导致后期频繁修改，甚至推倒重来。我们的项目正是因为没有明确的需求文档和设计图，导致开发过程中不断调整功能，浪费了大量时间。

3、提出一个解决办法，避免再次掉入陷阱

为了避免类似问题，我计划在未来的项目中采取以下改进措施：

• 制定代码规范：在项目开始前，团队统一代码风格（如命名规则、注释格式），并使用工具（如ESLint、Prettier）自动化检查。同时，编写清晰的README和模块文档，方便后续维护。
• 引入版本控制和协作流程：使用Git进行版本管理，并采用分支开发模式（如Git Flow），避免直接修改主分支。每次提交代码前进行团队审核（Code Review），确保代码质量。
• 系统化测试：
  • 单元测试：对每个函数或模块编写测试用例（如JUnit、Pytest）。
  • 集成测试：确保模块之间的交互正常。
  • 自动化测试：使用CI/CD工具（如GitHub Actions）在每次提交时自动运行测试。
• 重视需求分析与设计：
  • 在编码前，与团队成员和客户明确需求，并撰写需求文档。
  • 使用UML图或原型工具（如Figma）设计系统架构和界面，避免后期频繁修改。

通过以上方法，我希望能够提高代码质量、减少不必要的返工，并培养更专业的软件工程思维。