理论与实践的碰撞：“校园二手物品复活系统”开发总结

1. 引言：软件的本质与项目初衷

在开发“校园二手物品复活系统”的过程中，我深刻体会到了软件工程中关于软件（Software）的定义——它不仅仅是代码（Program），更是数据（Data）和相关文档（Document）的集合。

本项目旨在解决校园内闲置物品流转的痛点。从软件的核心特点来看，这是一个典型的逻辑产品，具有系统性（涉及用户、管理员、物品、分类等多个关联要素）和驻留性（依赖Python环境和数据库运行）。在开发过程中，如何应对需求易变和系统复杂的特性，是我应用软件工程知识的主要挑战。

2. 需求工程：从模糊到具体的规约

软件工程强调在开发前进行充分的需求分析。在本项目中，我首先明确了系统的涉干人员（Stakeholders）：

• 普通用户：需要发布、搜索、查看物品。
• 管理员：需要审核用户、管理物品分类。

这对应了需求工程中的功能性需求。通过识别用例（Use Case），我定义了清晰的边界：

• 注册流程：不仅是简单的插入数据，还引入了“待审核（Pending）”状态，这体现了业务逻辑对数据流转的约束。
• 物品发布：为了适应不同物品（如书籍vs食品）的差异，需求中包含了“动态属性”的要求，这对后续的数据设计提出了挑战。

3. 系统设计：MVC 架构模式的实践

在设计阶段，为了降低系统的耦合度，我采用了经典的 MVC (Model-View-Controller) 架构模式。这与软件设计中追求的“高内聚、低耦合”原则相一致。

• 模型层 (Model)：

• 在 model/ 目录下，ItemManager、UserManager 和 Database 类负责数据的持久化和业务规则。

• 数据库设计：使用了 SQLite。为了处理“不同类别有不同属性”这一复杂需求，我在 item_types 表中设计了 custom_attributes 字段，在 items 表中设计了 custom_values 字段（均存储 JSON 数据）。这是一种在关系型数据库中处理非结构化数据的权衡设计，体现了设计中的灵活性。

• 视图层 (View)：

• views/ 目录下的 MainWindow、LoginDialog 等只负责界面的展示和用户交互，不直接操作数据库。例如，MainWindow 通过信号（Signal）将用户的操作（如点击搜索）传递出去，自身不包含搜索逻辑。

• 控制层 (Controller)：

• controllers/ 目录下的 MainController 充当协调者。它接收视图的信号，调用模型的方法，再更新视图。例如，当 RegisterDialog 发出 register_requested 信号时，AuthController 会先进行密码强度校验（业务逻辑），再调用 UserManager 写入数据库。

这种分层架构极大地提高了代码的可维护性。如果未来需要更换数据库或修改界面库，只需修改特定层，而不会牵一发而动全身。

4. 版本控制：Git 的应用

在开发过程中，我使用了 Git 进行版本控制。正如复习资料中所述，Git 是目前最先进的分布式版本控制系统。

• 工作流：我遵循了标准的 Git 操作流：在工作区（Workspace）编写代码 -> git add 提交到暂存区（Stage） -> git commit 提交到本地仓库。
• 忽略文件：通过配置 .gitignore 文件（如忽略 __pycache__ 和 .db 文件），保持了仓库的整洁，避免了不必要的二进制文件污染版本历史。这体现了对 Git 原理中“仓库构成”的理解。

5. 软件测试：V模型的微型实践

虽然本项目规模较小，但我依然应用了软件测试的基本策略来保证质量。

• 黑盒测试 (Black-box Testing)：

• 在开发登录和注册功能时，我采用了等价类划分和边界值分析。

• 案例：测试注册时，输入空用户名（无效等价类）、密码长度小于6位（边界值）、两次密码输入不一致。程序通过 AuthController 中的校验逻辑成功拦截了这些异常输入，并弹窗提示，验证了功能的正确性。

• 集成测试 (Integration Testing)：

• 在 AddItemDialog（发布物品弹窗）中，测试了视图层与模型层的交互。当用户选择“书籍”类型时，界面动态生成“作者”输入框，并成功保存到数据库。这验证了各模块（View, Controller, Model）之间的接口交互是否协同工作。

6. 总结与反思

通过“校园闲鱼”系统的开发，我将软件工程的抽象概念转化为了具体的代码实践。

1. 架构的重要性：MVC 架构让我在后期添加“管理员审核”功能时，几乎没有修改现有的 UI 代码，只需增加 Controller 逻辑，证明了良好设计带来的扩展性。
2. 数据的严谨性：数据库外键约束（如 FOREIGN KEY (owner_id) REFERENCES users(id)）保证了数据的完整性，防止了“孤儿数据”的产生。
3. 未来的改进：对照软件维护的知识，目前的系统在“可测试性”上还有欠缺（缺乏自动化的单元测试脚本）。在未来的迭代中，可以引入 unittest 框架进行自动化的白盒测试，进一步提升代码质量。

这次开发经历不仅锻炼了编程能力，更让我理解了软件工程作为一门“工程”学科的严谨性——即通过科学的方法和工具，在成本、时间和质量之间寻找最优解。