【软件工程】从需求到交付：校园物品复活系统的开发复盘与反思

【软件工程】从需求到交付：校园物品复活系统的开发复盘与反思
课程: 软件工程 | 姓名: 帅哲 | 学号: 521431910032 | 指导教师: 曹健

1. 引言
   在曹健老师的《软件工程》课程中，我独立开发了“物品复活系统（Item Resurrection）”。这是一个旨在解决校园闲置物品流转问题的桌面应用程序。

回顾整个开发周期，我深刻体会到：写代码只是软件工程中很小的一部分，真正的挑战在于如何用工程化的思维去分析问题、设计架构以及管理过程。本文将对照软件工程的理论知识，总结我在本次开发中的实践与体会。

2. PSP 2.1 过程数据的分析与反思
   在项目启动前，我按照 PSP (Personal Software Process) 的标准制定了详细的时间计划。项目结束后，我对比了预估时间与实际耗时， 实际耗时比预估多出了约 32%。这验证了软件工程项目花费的时间总是比你预期的要长。
   在未来的项目中，我需要在 Coding 阶段预留更多的 Buffer（缓冲时间），特别是在使用不太熟练的 UI 框架（如 Tkinter）时。详细的 Design (设计) 阶段确实减少了后期逻辑错误的返工。如果在写代码前没有画好类图和顺序图，我在处理“动态属性”时可能会写出大量混乱的 if-else 代码。

3. 架构设计的实践：MVC 模式的落地
   在本项目中，我没有采用“一镜到底”的面条式代码，而是严格遵循了 MVC (Model-View-Controller) 设计模式，体现了软件工程中“高内聚，低耦合”的原则。

3.1 模块职责分离
Model (models.py)：这是系统的“大脑”。它只负责数据的存储（JSON读写）、业务逻辑判断（如用户是否获批、密码验证）。它完全不知道界面的存在，这使得逻辑代码非常容易测试。

View (ui.py)：这是系统的“脸面”。它负责绘制 Tkinter 窗口、按钮和表格。它只负责显示，不包含任何业务判断。

Controller (main.py)：这是系统的“神经中枢”，负责启动程序并连接 M 和 V。

这种分离带来的最大好处是可维护性。当我想修改“注册成功”的提示语时，我只需要去 ui.py；当我想修改“管理员审批”的逻辑时，我只需要动 models.py。如果未来我想把界面换成 Web 端（如 Flask），我的 models.py 几乎不需要改动就可以复用。

4. 核心难点攻克：数据驱动的动态界面
   本次作业最大的需求挑战在于：“不同类别的物品有不同的属性（如食品有保质期，书籍有作者）”。

如果采用硬编码（Hard Code），每增加一个类型我就要修改代码，这违反了 OCP (开闭原则) —— 对扩展开放，对修改关闭。

我的解决方案： 采用了元数据驱动 (Metadata-driven) 的设计思想。

管理员定义元数据：在后台配置 {'书籍': ['作者', '出版社']}。

前端动态渲染：

ui.py 中的核心逻辑片段

for attr in attributes:
entry = tk.Entry(parent)
self.dynamic_entries[attr] = entry

当用户选择分类时，程序读取元数据，循环生成输入框。

这让我理解了数据结构设计对软件复杂度的决定性影响。一个好的数据结构（在 Model 层使用字典存储动态属性）可以极大地简化控制逻辑。

5. 编码规范与质量保证
   在开发过程中，我强制自己遵守了以下工程规范：

（1）版本控制 (Git)： 抛弃了“代码_最终版_v2.zip”的原始习惯。我使用了 Git 进行版本管理，确保每一次提交（Commit）都有明确的意义（如 Feat: 完成管理员审批逻辑）。
（2）代码风格 (PEP 8)： 变量命名采用 snake_case（如 user_list），类名采用 CamelCase（如 SystemData）。清晰的命名是最好的注释。
（3）防御性编程： 在 models.py 中，我考虑了多种异常情况。例如，读取 JSON 文件时使用了 try-except 块，防止因文件损坏导致程序直接崩溃。

6. 结语与展望
   通过这次“物品复活系统”的开发，我不仅掌握了 Python GUI 编程，更重要的是完成了一次从需求分析 -> 架构设计 -> 编码实现 -> 测试交付的完整软件生命周期闭环。

待改进之处： 目前系统使用 JSON 文件存储数据，属于轻量级方案。如果用户量增大，并发读写会出现问题。下一版本计划引入 SQLite 数据库，并增加 Unit Test (单元测试) 覆盖核心业务逻辑，进一步提升系统的健壮性。