### 图书管理系统里的“补锅匠”：我的修改部分心得

组队做C语言课程设计，我分到的活儿听起来最轻松，组长的原话是：“你负责修改部分，就是改改。” 当时我天真地以为，写系统的人才牛，改别人的代码不就是挑挑错、调调格式，没什么技术含量。真上手才发现，这“修改”两个字，里面全是水，深得很。

我们组的图书管理系统是一个标准的“学生作品”，功能挺全，菜单循环、结构体数组存书、链表存借阅记录，甚至还有模糊查询。但跑起来之后，问题像地鼠一样往外冒。我干的活，就是从组长手里接过那个满是警告的压栈工程，开始当“补锅匠”。

第一件让我头疼的事，是借书日期的计算。原代码是拿系统当前时间减去一个固定的起始日期，然后除以86400得天数，用来判断是否超期。这思路没问题，但问题出在“当前时间”上。原代码用的是`time(NULL)`返回的秒数，然后直接打印。有次演示，组长提前一天把系统日期改了模拟超期场景，结果改回来后，所有借阅记录的“剩余天数”全乱了。我改成在每次借书操作时，把借书当天的日期字符串存进结构体，逾期判断时再解析当前日期去比较。这活儿不重，但要把原代码里的时间戳、格式化输出、比较函数全部串起来，牵一发动全身。

最崩溃的是逻辑漏洞。原管理系统在还书时，只检查书是否存在，不检查这本书是不是被当前用户借的。说白了，张三借了《C Primer Plus》，李四去还，系统照样“还书成功”，甚至能在没借过的情况下“归还”一本库存为零的书，把馆藏数量变成负数。我加了一个双重校验，先查链表里有没有这条借阅记录，再查借阅者ID是否匹配。那段代码改完，组员测试时直接卡在“借阅记录不存在”的提示上，说明校验生效了，我才松了口气。

体力活也不少。原系统的图书信息是用固定数组存的，上限一百本，注释里写着“够用了”。但演示时老师随机抽了本《算法导论》，编号是107，系统直接崩溃。我把数组改成动态链表，涉及到的函数全部得动：增删改查的遍历逻辑从`for(i=0;i

不过，最磨人的是对“修改”本身的认知。组长说：“你负责改，意味着你要保证改完还得像原来的系统。”这句话直到最后才明白。补丁打多了，代码风格会变得混乱。我把修改过的每个函数都加上了注释，注明改了哪里、为什么改。比如在借阅函数开头写下：“修改点：增加借阅者存根，防止他人代还。”这样三天后再看，自己也能秒懂。

经历这次课程设计，我算是摸到了一点做项目的门道：写新代码是创造，改旧代码是考古。要在别人留下的逻辑里，分辨出哪些是设计意图，哪些是疏忽大意。那时候没有Github，代码全靠U盘拷贝，版本管理就是文件名后面加`_final`、`_final2`，有一次同事给我的还是“_真最终版”。现在想想，这大概就是团队协作里最原始的“代码管理”。

最后演示那天，系统跑得很顺。老师提问修改的难点，我说：“难点不在改，在于知道什么时候不该改。”这倒不是藏私，原代码的核心框架确实没问题，我修的都是边界情况和不严谨的判断。那些看似繁琐的修改，成了我这学期最有收获的实践。补锅补多了，也会修锅了。