[Refactor]CPP Learn Data Day 1
原帖地址:https://www.cnblogs.com/Reisentyan/p/19752805企业训练营惊心动魄尔虞我诈的重构代码的一周已经结束了
现在时间，将揭示——
幕后真相
重构项目地址：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
从而降低单个函数的复杂度，提高可读性。
同时，原实现中部分对象管理方式较为原始，存在裸指针传递的情况，例如：
ManagerMenu(Identity*& manager)
StudentMenu(Identity*& student)本次维护后统一改为基于智能指针的方式，例如：
managerMenu(std::unique_ptr<Identity>& manager)
studentMenu(std::unique_ptr<Identity>& student)这样可以减少手动管理对象生命周期的负担，提升资源管理安全性。
4.9 新增维护
本次维护进一步围绕代码格式统一、声明顺序规范化与重复代码收敛展开，主要完成了以下优化工作：
[*]对部分头文件中的声明顺序进行了调整，规范了类内成员函数的排列次序以及头文件的组织方式；
[*]对 Manager、Student、Teacher 中的 operMenu() 函数进行了格式统一与结构整理；
[*]对 systemclt 中的 showMenu() 函数进行了同类优化，消除了菜单输出中的部分硬编码内容，提升了界面输出代码的一致性与可维护性；
[*]针对 student 与 teacher 两个模块中存在的重复逻辑，新增 orderdisplay.h 与 orderdisplay.cpp，对预约记录判空、状态文本拼接及部分输出逻辑进行了集中封装。
通过上述调整，项目在以下方面得到了进一步改善：
[*]头文件与类声明结构更加清晰，代码阅读成本进一步降低；
[*]菜单显示相关代码的风格更加统一，减少了重复输出语句带来的维护负担；
[*]Student 与 Teacher 模块中的重复逻辑得到收敛，降低了后续修改时多处同步调整的风险；
[*]项目整体规范性与可维护性进一步提升，为后续继续优化控制层与显示层的职责划分打下了基础。
5. 测试与验证情况
为验证本次维护未破坏系统原有主流程，并确认新增调整有效，进行了基本功能测试、边界测试与回归测试。
5.1 管理员添加账号测试
输入：
请选择您的操作：
1
请输入添加账号的类型
1、添加学生
2、添加老师
1
请输入学号：
2023
请输入姓名：
Reisentyan
请输入密码：
666666
添加成功随后执行查看账号操作，系统能够正确显示新增学生信息，说明新增账号功能正常，数据已成功写入并重新加载。
5.2 重复 ID 输入测试
输入重复学号后，系统提示：
学号重复，请重新输入！说明学生账号判重逻辑已生效。
5.3 学生预约功能测试
学生登录后进行预约操作：
请选择您的操作： 1
机房开放时间为周一至周五！
请输入申请预约的时间：
1、周一
2、周二
3、周三
4、周四
5、周五
4
请输入申请预约的时间段：
1、上午
2、下午
2
请选择机房：
1号机房容量：20
2号机房容量：50
3号机房容量：100
3
预约成功！审核中随后查看预约记录，系统能够正确显示新增预约，说明预约写入流程正常。
5.4 教师审核功能测试
教师登录后可查看待审核预约，并完成审核操作。审核完成后，学生再次登录查看预约状态，显示为“预约成功”，说明以下流程已打通：
[*]学生提交预约；
[*]教师查看待审核记录；
[*]教师审核通过；
[*]学生端查看审核结果。
这表明系统核心 MVP 功能可正常运行。
5.5 回归验证
本次维护后，对以下功能进行了回归检查：
[*]管理员登录
[*]学生与教师账号添加
[*]重复 ID 拦截
[*]查看账号
[*]查看机房
[*]学生预约
[*]教师审核
[*]学生查看预约结果
结果表明，系统主要业务流程未因本次维护而受到破坏。
6. 当前遗留问题与后续建议
虽然本次维护已经完成了较多规范化和结构整理工作，但项目仍存在进一步优化空间，主要包括：
[*]Manager 类仍然偏重
虽然已经拆分出 UserStorage，但 Manager 仍承担较多业务组织职责，后续可继续拆分为更明确的服务层或控制层。
[*]输入校验仍可加强
当前测试覆盖了主流程，但对异常输入、边界输入和非法输入的处理仍可继续完善。
[*]界面层与业务层仍有一定耦合
部分菜单显示与业务处理仍在同一类中，后续可以进一步解耦。
[*]跨平台适配仍处于初步封装阶段
虽已对清屏、暂停等逻辑进行集中处理，但整体项目距离完整的跨平台支持仍有一定距离。
7. 总结
本次维护以“规范化、去耦合、提可维护性”为核心目标，对项目进行了较系统的整理。重点完成了头文件保护补充、命名风格统一、成员封装性增强、中文硬编码集中管理、平台相关调用封装、资源管理方式优化，以及 Manager 类职责的初步拆分。
从测试结果来看，系统核心业务流程保持正常，学生预约、教师审核、管理员管理等主要功能均可正常运行。整体而言，本次维护有效提升了代码质量与后续维护基础，但项目仍存在进一步重构和细化测试的空间。
附部分记录：
很久没有登录Steam，没有打开心跳文学部，想看莫妮卡学姐，想和她说话……
好消息是这周结束了，稍微玩两天吧
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]