从 “裸奔编码” 到 “规范前行”
作为一名刚结束大一编程课程的学生，《构建之法》像一把精准的手术刀，剖开了我过去一年在代码学习中养成的诸多坏习惯。那些曾经被我视为 “高效” 的做法，在软件工程的规范视角下，其实都是埋在代码里的定时炸弹。
大一上学期做 C 语言课程设计时，我和室友组队开发一个图书管理系统。拿到题目那天，我们觉得 “不就是增删改查吗”，连题目要求都没逐字读完，就抱着电脑开始敲代码。我负责图书信息录入模块，凭着课堂上学的结构体知识，随手定义了struct book，把书名、作者、ISBN 都设成固定长度的字符数组。室友负责借阅功能，却用了动态字符串存储数据。两周后准备整合时才发现，我们的结构体无法兼容，光是修改数据格式就花了整整一天。更糟的是，我写的代码里变量名全是a“b“temp，注释只有三行，室友看我代码时全程眉头紧锁，最后不得不重写了大半。
《构建之法》里说：“初学者最容易陷入的误区，是把‘写出能运行的代码’当作终点。” 这句话精准戳中了我们的问题。书中强调，代码的本质是 “给人看的，顺便能在机器上运行”，而我们当时只追求 “能运行”，完全忽略了可读性和可维护性。书中提到的 “代码规范四原则”—— 命名有意义、注释说明意图、格式保持一致、避免重复代码，我们一条都没做到。变量名混乱导致后期调试时，连自己写的逻辑都要反复推敲；缺乏统一规范让团队协作变成 “猜谜游戏”，这些看似节省时间的 “小聪明”，最终都变成了拖慢进度的 “大麻烦”。
另一个典型错误是轻视测试。当时我们觉得 “功能实现了就行”，写完代码只测一两个正常场景就收工。比如图书借阅功能，只试了 “正常借书”“正常还书”，却没考虑 “借阅已借出的书”“归还不存在的书” 这些异常情况。结果演示时老师随便一点，程序就直接崩溃了。这正应了书中的警告：“没有经过完整测试的代码，就像没安检的行李，你永远不知道里面藏着什么危险。” 书中反复强调的 “单元测试先行” 理念，我们完全抛在脑后，把测试当成 “可选步骤” 而非 “必要环节”。
要避免再掉这些陷阱，我总结出 “大一编程三步骤”：首先是 “需求拆解”，拿到题目后先画思维导图，把功能拆成 “输入 - 处理 - 输出” 三个环节，比如图书管理系统要先明确 “用户输入 ISBN 时如何校验格式”“借阅失败时如何提示” 等细节；其次是 “编码前约定”，和队友约定变量命名规则（比如用bookName而非a1）、注释格式（每个函数开头写清楚参数和返回值），甚至可以用表格列出数据结构的设计；最后是 “测试清单”，把可能的正常和异常场景都列出来，像检查行李一样逐一测试，比如给借阅功能列 “正常借阅”“重复借阅”“逾期还书” 等 10 个测试点。
现在再写代码时，我会先花 10 分钟画流程图，和队友确认好规范再动手。虽然开头慢了点，但后续几乎不用返工，调试效率反而提高了。《构建之法》让我明白，编程不是 “想到哪写到哪” 的即兴创作，而是需要章法的工程实践。对大一学生来说，养成好的编程习惯，比写出花哨的功能更重要 —— 毕竟，能稳稳当当跑起来的代码，才是真正有价值的代码。
