《代码大全2》观后感（一）：从“写代码”到“做工程”的思维跃迁
初读《代码大全2》时，我正处于“能实现功能就沾沾自喜”的编程阶段——总觉得代码跑通了就是终点，至于变量名是否清晰、函数是否臃肿、逻辑是否易读，都只是“锦上添花”的细节。但这本书开篇就打破了我的认知：它没有教复杂的语法技巧，也没有讲前沿的框架工具，而是把编程定义成了一项“工程”，强调“好代码的核心是支撑软件长期存活，而非短暂运行”。
这种“工程思维”最让我震撼的，是它对“人”的重视。书中说：“代码首先是写给人看的，其次才是给机器执行的”。我突然想起自己半年前写的一个学生管理系统，当时为了图快，用“s”“t”“u”当变量名，用“func1”“func2”命名函数，最近需要修改“成绩统计”功能时，盯着屏幕看了两个小时，才勉强回忆起每个符号代表的含义。而书中倡导的“用业务语义命名”，比如把“s”改成“studentScore”，把“func1”改成“calculateAverageScore”，看似多写了几个字符，却能让代码自己“说话”——后来我按照这个原则重构代码，不仅自己调试时效率翻倍，同事接手时也省去了反复询问的麻烦。
更让我深思的是，书中把“可维护性”放在了比“效率”更优先的位置。我曾为了减少几行代码，把三个功能揉进一个函数里，结果后续需要新增“成绩导出Excel”功能时，不得不拆解原函数，还意外破坏了原本的统计逻辑，导致返工两天。而书中建议“一个函数只做一件事”，看似会增加函数数量，却能让每个模块独立可控，修改时不会“牵一发而动全身”。这让我明白，编程不是“炫技”，而是“权衡”——权衡短期效率与长期成本，权衡个人习惯与团队协作，而《代码大全2》正是教会我如何做出更合理权衡的“指南”。