[Refactor]CPP Learn Data Day 1

原帖地址:https://www.cnblogs.com/Reisentyan/p/19752805
企业训练营惊心动魄尔虞我诈的重构代码的一周已经结束了
现在时间[2026/03/22]，将揭示——
幕后真相

重构项目地址：Guoyanzeng/Computer-room-reservation-system: 机房预约系统
这个机房预约系统是一份来自六年前（2020年）的老代码。以现在的眼光来看，它的逻辑或许有些混乱，代码质量也有些堪忧，但它却奇迹般地跑通了所有功能。这800多行的代码量，作为大一新生的 C 语言大作业其实恰到好处，也许正因如此，原作者才没有对其进行深度的细节优化。
我还是挺佩服他的，能在 2020 年写出这样完整的项目，当时肯定也是同届中的佼佼者！
毕竟我也在大一写过上千行的项目，对这种“能跑就行”的成就感深有体会。
说回正题。
本周的作业要求是：严格对照给定的代码规范，找出并优化项目中的不合规之处。
这份规范文档非常长，全靠肉眼排查极易遗漏，这时候就考验个人的视力了（）
感觉这更像是在考验我们使用 AI 的技巧。毕竟在一周时间内，纯手工优化完这些代码几乎是不可能完成的任务。
AI实在是太坏了，如果不是ai的存在，周作业的难度得小很多。
虽然说企业对代码规范的要求很高，但这可能仅仅是针对学生初学者而言的。
这次的代码规范主要还是局限在语法和格式层面，甚至没有触及多线程相关的复杂场景。
为什么这样说呢？
因为甚至没有触碰到多线程相关的东西，就连我都知道，说明不是很高级！
重构任务结束，这里将稍作讲述重构过程中遇到的一系列问题：

• 代码量很大，并且逻辑奇怪，稍微动一点点东西，就要改一大堆代码。
  典序的就是 m_id(学号)。在代码中居然是一个 int 类型的变量。连我真实的学号都无法输入，输进去就死循环报错。
  你还不能轻易的改动它，因为后面有一连串奇葩的操作：先把字符串用 C 风格函数转成 char*，再调用古老的字符串转数字函数，最后才跟学号进行比较。简直是构思。
  
• 代码复用 这个词很常见，但实际动手提取时却步履维艰。几段看似相似的代码片段，总有那么几处细微的逻辑差异。
  不好改！
  一般来说，但如何优雅地拆分和传参，本身就是一件极具挑战且繁琐的事。
  
• 类的使用比我想象中的要危险，手动进行内存管理实在是太恐怖。
  更重要的是，写代码时必须时刻考虑：如果系统在执行某段代码的过程中突然崩溃，该怎样写才能尽量兜底、减少破坏？
  这不禁让我联想到了传说中 MySQL 底层那些为了处理异常而堆砌的“屎山”代码。
  

就算是ai，也很难考虑到这么多，很多时候也还是需要人工去挑刺。时代在发展，垃圾代码尽量少点吧！
但是就现在的安卓机的代码而言，感觉还是很难做到的
以下为作业的报告，仅供参考：
项目维护报告
1. 基本信息

• 项目名称： 机房预约系统
  
• 维护者： Reisentyan
  
• 维护日期： 2026-03-20
  
• 涉及核心文件：
  computerroom.h、globalfile.h、globalui.h、identity.h、manager.h、orderfile.h、student.h、systemclt.h、teacher.h、userstorage.h、computerroom.cpp、globalfile.cpp、identity.cpp、main.cpp、manager.cpp、orderfile.cpp、student.cpp、systemclt.cpp、teacher.cpp、userstorage.cpp、orderdisplay.h、orderdisplay.cpp
  

2. 维护背景与目标

本次维护主要围绕代码规范整改、结构优化、风险修复与可维护性提升展开。
原项目在功能层面已经具备基本的机房预约流程，但在代码实现上仍存在以下问题：

• 头文件保护缺失，存在重复包含风险；
  
• 命名风格不统一，部分成员变量和函数命名不符合规范；
  
• 存在 using namespace std 的滥用现象；
  
• 部分成员变量直接暴露为 public，封装性较弱；
  
• Manager 等类职责过多，存在界面交互、业务逻辑、数据持久化耦合的问题；
  
• 项目中存在中文硬编码、魔法数字、重复代码及平台相关调用分散等情况；
  
• 部分资源管理方式不够安全，存在后续维护风险。
  

基于以上问题，本次维护的目标如下：

• 按统一编码规范整理头文件与实现文件；
  
• 提升类封装性与命名规范性；
  
• 对职责过重的模块进行初步拆分；
  
• 清理重复代码和无效代码；
  
• 提升程序在输入处理、资源管理和跨平台兼容性方面的可维护性；
  
• 为后续进一步重构打下基础。
  

3. 本次维护内容概述

本次维护主要完成了以下工作：

• 为全部头文件补充头文件保护，降低重复包含风险；
  
• 删除项目中大量 using namespace std 的写法，统一补全 std:: 命名空间；
  
• 统一文件命名风格，将不规范文件名调整为小写英文命名；
  
• 为 Identity 基类补充虚析构函数，完善继承层次下的析构行为；
  
• 为派生类重写的虚函数统一补充 override；
  
• 规范成员变量命名，并将原先暴露在 public 区域的成员变量调整为 private；
  
• 增加访问接口，统一通过成员函数读写对象状态；
  
• 统一构造函数初始化方式，使用初始化列表优化构造逻辑；
  
• 拆分界面文本与全局常量：
  
  
  
  • globalui.h 用于集中管理界面文案；
    
  • globalfile.h 用于集中管理文件路径、符号常量及部分全局配置；
    
  
  
• 新增 PauseSystem() 与 ClearSystem()，替代直接分散使用 system("pause")、system("cls")；
  
• 将用户读写及判重逻辑从 Manager 中拆分，新增 UserStorage 类；
  
• 对 Manager 类进行初步瘦身，补充 init()、reloadUsers()、reloadComputerRooms()、addStudentAccount()、addTeacherAccount()、hasStudentId()、hasTeacherId() 等接口；
  
• 对登录验证逻辑进行拆分，降低 systemclt.cpp 中登录函数的复杂度；
  
• 优化部分文件读取与数据初始化流程，提高安全性与可读性。
  

4. 详细修改说明

4.1 头文件与命名规范整理

原项目头文件未统一添加保护宏，存在重复包含的潜在风险。本次已为所有头文件补充 #ifndef、#define、#endif 保护。
同时，原项目中存在以下命名问题：

• 文件名大小写风格不统一；
  
• 存在中文文件名；
  
• 成员变量命名风格不一致；
  
• 部分函数命名不规范。
  

本次维护中，已将相关文件统一为小写英文文件名，并对成员变量进行规范化处理。例如：

• m_Name 调整为 m_name
  
• vStu 调整为 m_students
  

此类修改有助于统一代码风格，提升可读性与维护效率。
4.2 命名空间与标准库使用规范化

原项目中多个文件直接使用 using namespace std，这会扩大命名污染范围，并增加大型项目中的冲突风险。
本次维护已删除相关写法，统一显式补充 std:: 前缀，例如 std::string、std::vector、std::cout 等，以提高代码可读性和命名安全性。
4.3 面向对象封装性增强

原项目中部分成员变量直接定义为 public，虽然短期使用方便，但会削弱类的封装性，并增加后续维护风险。
本次维护中，已将相关成员变量统一调整为 private，并通过接口函数暴露必要访问能力。例如：

• 学生学号 m_id 通过 id() 接口访问；
  
• 其他业务代码中原本直接访问成员变量的逻辑，统一改为通过成员函数获取。
  

这一调整提升了类的封装性，也使后续修改内部实现时对外部代码的影响更小。
4.4 构造函数与继承层次修正

原项目中存在以下问题：

• 构造函数参数传递方式不统一；
  
• 部分构造函数未使用初始化列表；
  
• 基类 Identity 存在虚函数，但未显式提供虚析构函数；
  
• 派生类重写虚函数时，未统一使用 override。
  

本次维护中已完成以下修正：

• 复杂类型参数统一采用 const T& 传递；
  
• 构造函数统一使用初始化列表；
  
• 为 Identity 增加虚析构函数；
  
• 为派生类重写函数补充 override 说明。
  

其中，虚析构函数的补充有助于保证在基类指针指向派生类对象时，析构过程能够完整执行，降低资源释放不完整的风险。
4.5 中文硬编码与魔法数字整理

原项目中存在较多中文硬编码、路径字符串散落和魔法数字问题，导致维护成本较高。
本次维护中进行了集中整理：

• 新增 globalui.h，集中管理界面相关文本；
  
• 新增 globalfile.h，集中管理文件路径、符号常量和部分通用配置；
  
• 通过 static constexpr const char* 等方式集中定义常量，便于统一维护和后续修改。
  

这一调整使界面文案、路径和常量从业务逻辑代码中分离出来，降低了硬编码分散带来的维护负担。
4.6 平台相关调用集中封装

原项目中多处直接调用：

• system("cls")
  
• system("pause")
  

这类调用与平台耦合较强，也不利于统一维护。
本次维护中新增 ClearSystem() 与 PauseSystem() 两个封装函数，将相关平台逻辑集中处理。这样做的好处包括：

• 避免平台相关代码分散在多个源文件中；
  
• 便于后续统一修改或替换实现；
  
• 提高代码整体可维护性。
  

4.7 Manager 类职责拆分与结构优化

原项目中，Manager 类同时承担了以下职责：

• 管理员业务操作；
  
• 用户数据读取；
  
• 判重逻辑；
  
• 机房信息初始化；
  
• 容器刷新与状态维护。
  

这使得类职责过重，成员函数体积偏大，且存在一定重复逻辑。
本次维护中进行了初步拆分：

• 新增 UserStorage 类，用于负责用户信息读取、写入及判重；
  
• 为 Manager 增加 init() 初始化接口；
  
• 增加 reloadUsers()、reloadComputerRooms()、addStudentAccount()、addTeacherAccount()、hasStudentId()、hasTeacherId() 等成员函数。
  

通过以上拆分，Manager 的职责边界更加清晰，也为后续继续拆分类与模块提供了更好的基础。
4.8 登录逻辑与资源管理方式优化

原项目中，登录模块逻辑较为集中，loginIn 函数内部承担了较多分支判断和验证职责，代码较为臃肿。
本次维护中，针对不同角色补充了独立验证函数，例如：

• validateStudent
  
• validateTeacher
  
• validateAdmin
  

从而降低单个函数的复杂度，提高可读性。
同时，原实现中部分对象管理方式较为原始，存在裸指针传递的情况，例如：

1. ManagerMenu(Identity*& manager)
2. StudentMenu(Identity*& student)

复制代码

本次维护后统一改为基于智能指针的方式，例如：

1. managerMenu(std::unique_ptr<Identity>& manager)
2. studentMenu(std::unique_ptr<Identity>& student)

复制代码

这样可以减少手动管理对象生命周期的负担，提升资源管理安全性。
4.9 [2026-03-22]新增维护

本次维护进一步围绕代码格式统一、声明顺序规范化与重复代码收敛展开，主要完成了以下优化工作：

• 对部分头文件中的声明顺序进行了调整，规范了类内成员函数的排列次序以及头文件的组织方式；
  
• 对 Manager、Student、Teacher 中的 operMenu() 函数进行了格式统一与结构整理；
  
• 对 systemclt 中的 showMenu() 函数进行了同类优化，消除了菜单输出中的部分硬编码内容，提升了界面输出代码的一致性与可维护性；
  
• 针对 student 与 teacher 两个模块中存在的重复逻辑，新增 orderdisplay.h 与 orderdisplay.cpp，对预约记录判空、状态文本拼接及部分输出逻辑进行了集中封装。
  

通过上述调整，项目在以下方面得到了进一步改善：

• 头文件与类声明结构更加清晰，代码阅读成本进一步降低；
  
• 菜单显示相关代码的风格更加统一，减少了重复输出语句带来的维护负担；
  
• Student 与 Teacher 模块中的重复逻辑得到收敛，降低了后续修改时多处同步调整的风险；
  
• 项目整体规范性与可维护性进一步提升，为后续继续优化控制层与显示层的职责划分打下了基础。
  

5. 测试与验证情况

为验证本次维护未破坏系统原有主流程，并确认新增调整有效，进行了基本功能测试、边界测试与回归测试。
5.1 管理员添加账号测试

输入：

1. 请选择您的操作：
2. 1
3. 请输入添加账号的类型
4. 1、添加学生
5. 2、添加老师
6. 1
7. 请输入学号：
8. 2023
9. 请输入姓名：
10. Reisentyan
11. 请输入密码：
12. 666666
13. 添加成功

复制代码

随后执行查看账号操作，系统能够正确显示新增学生信息，说明新增账号功能正常，数据已成功写入并重新加载。
5.2 重复 ID 输入测试

输入重复学号后，系统提示：

1. 学号重复，请重新输入！

复制代码

说明学生账号判重逻辑已生效。
5.3 学生预约功能测试

学生登录后进行预约操作：

1. 请选择您的操作： 1
2. 机房开放时间为周一至周五！
3. 请输入申请预约的时间：
4. 1、周一
5. 2、周二
6. 3、周三
7. 4、周四
8. 5、周五
9. 4
10. 请输入申请预约的时间段：
11. 1、上午
12. 2、下午
13. 2
14. 请选择机房：
15. 1号机房容量：20
16. 2号机房容量：50
17. 3号机房容量：100
18. 3
19. 预约成功！审核中

复制代码

随后查看预约记录，系统能够正确显示新增预约，说明预约写入流程正常。
5.4 教师审核功能测试

教师登录后可查看待审核预约，并完成审核操作。审核完成后，学生再次登录查看预约状态，显示为“预约成功”，说明以下流程已打通：

• 学生提交预约；
  
• 教师查看待审核记录；
  
• 教师审核通过；
  
• 学生端查看审核结果。
  

这表明系统核心 MVP 功能可正常运行。
5.5 回归验证

本次维护后，对以下功能进行了回归检查：

• 管理员登录
  
• 学生与教师账号添加
  
• 重复 ID 拦截
  
• 查看账号
  
• 查看机房
  
• 学生预约
  
• 教师审核
  
• 学生查看预约结果
  

结果表明，系统主要业务流程未因本次维护而受到破坏。
6. 当前遗留问题与后续建议

虽然本次维护已经完成了较多规范化和结构整理工作，但项目仍存在进一步优化空间，主要包括：

• Manager 类仍然偏重
  虽然已经拆分出 UserStorage，但 Manager 仍承担较多业务组织职责，后续可继续拆分为更明确的服务层或控制层。
  
• 输入校验仍可加强
  当前测试覆盖了主流程，但对异常输入、边界输入和非法输入的处理仍可继续完善。
  
• 界面层与业务层仍有一定耦合
  部分菜单显示与业务处理仍在同一类中，后续可以进一步解耦。
  
• 跨平台适配仍处于初步封装阶段
  虽已对清屏、暂停等逻辑进行集中处理，但整体项目距离完整的跨平台支持仍有一定距离。
  

7. 总结

本次维护以“规范化、去耦合、提可维护性”为核心目标，对项目进行了较系统的整理。重点完成了头文件保护补充、命名风格统一、成员封装性增强、中文硬编码集中管理、平台相关调用封装、资源管理方式优化，以及 Manager 类职责的初步拆分。
从测试结果来看，系统核心业务流程保持正常，学生预约、教师审核、管理员管理等主要功能均可正常运行。整体而言，本次维护有效提升了代码质量与后续维护基础，但项目仍存在进一步重构和细化测试的空间。
附部分记录：

很久没有登录Steam，没有打开心跳文学部，想看莫妮卡学姐，想和她说话……
好消息是这周结束了，稍微玩两天吧

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！