5.29和读书笔记（代码大全2）

今天上了毛概课程 并且进行了概率论期中考试
读完《代码大全 2》第十一章到第二十三章，我承接前十章建立的工程化思维，对代码精细化打磨、后期迭代维护有了全新的理解。如果说前十章教会我写代码前要做好顶层思考、夯实变量与基础逻辑，那么这十三章则补齐了代码编写、优化、纠错、协作的全流程细节，让我明白高质量代码从来不是依靠灵光一现，而是依靠统一、克制、严谨的编码习惯，把细碎的规范融入每一行代码之中。这部分内容不再探讨宏观的开发思路，全部聚焦于编码落地的微观细节，覆盖语句结构、代码排版、注释编写、错误处理、代码重构、系统测试、团队编程规范等开发者日常高频接触的内容，戳中了绝大多数人写代码时重功能、轻观感、重实现、轻容错的通病。
在语句与代码排版相关章节中，我推翻了以往 “只要程序能运行，格式无关紧要” 的错误想法。过去编写判断、循环语句时，我常常随意嵌套 if-else，为了少写几行代码使用多层三元表达式，追求代码简短却极大降低可读性，书中明确提出，代码首要目标是让人读懂，其次才是让机器运行。过深的逻辑嵌套会大幅提升人脑的理解成本，三层以上的分支嵌套就应当通过卫语句、抽取子程序拆解优化。同时代码空白行、缩进、语句排布这类看似无关功能的格式规范，并非死板的教条，而是为了划分代码逻辑区块，让阅读者顺着视觉逻辑快速梳理业务脉络。很多时候团队沟通的时间损耗，不是业务逻辑难懂，而是杂乱无章的代码布局浪费了大量阅读时间。
以往我对代码注释也存在两极化误区，要么冗余堆砌，把代码已经表达的逻辑再复述一遍，要么完全不写注释，默认自己永远记得代码思路。书中点明了注释的本质：注释是弥补代码表达能力不足的补充说明，不能替代清晰的变量命名、合理的代码拆分。好的注释只解释为什么这么做，而非做了什么，比如特殊边界的取舍原因、兼容历史 bug 的处理逻辑，而循环、赋值这类基础操作完全无需额外注释。同时书中提醒要及时维护注释，代码修改后不同步更新注释，错误的注释远比没有注释危害更大，这也是我翻看旧代码时最头疼的问题，过时的注释会直接误导后续维护者。
错误处理、防御性编程的进阶内容让我改观了异常处理的思维。此前我习惯笼统捕获所有异常，直接返回错误提示，不区分异常类型，也不记录详细日志，一旦线上报错，根本无法定位根因。书中区分了返回错误码、抛出异常、断言、静默容错四种错误处理方式，明确了各自适用场景：断言用于内部开发校验，上线后关闭；异常用于处理外部不可控错误；静默容错只适用于用户无感的次要功能。同时杜绝盲目容错，对于不可逆的严重错误，及时终止程序远比强行运行、产生脏数据更稳妥，这让我意识到容错不是掩盖漏洞，而是合理管控风险。
最让我受益匪浅的是代码重构相关章节。此前我误以为重构就是重写代码、优化性能，甚至觉得重构是多余的工作量。实际上重构是不改变程序外部功能，仅优化内部结构，消除代码异味，比如冗余代码、重复逻辑、过大的类、耦合过高的模块。书中强调重构要碎片化进行，不要等待代码彻底腐烂再大规模重写，每次修改功能时顺带优化周边冗余逻辑，小步迭代、持续优化，远比后期一次性重构风险更低。同时性能优化的理念也刷新了我的认知：不要过早优化，90% 的代码都不会成为性能瓶颈，优先保证代码可读性、稳定性，再通过日志、监控定位真正的瓶颈针对性优化，盲目提前优化只会让代码晦涩难懂。
最后的测试、个人与团队编码章节，打通了个人编码到团队协作的闭环。我此前一直认为测试是测试人员的工作，开发者只需完成功能编写即可，而书中提出开发者单元测试是质量第一道防线，单元测试的核心不是验证功能正确，而是提前覆盖边界值、异常输入、极端场景，把低级 bug 扼杀在编码阶段。而团队协作层面，统一编码规范、代码评审不是形式主义，是为了抹平开发者个人编码习惯的差异，让团队代码看起来如同一人所写，降低交接、维护成本。
通读 11 至 23 章，我总结出贯穿始终的核心：软件开发是长久的协作工作，代码要面向未来的维护者、面向团队伙伴，而非只面向当下的自己。前期重规划、中期重细节、后期重重构，三者缺一不可。结合前后二十三章的学习，我彻底摆脱了新手只追求功能实现的短视思维，往后编码会始终遵循可读性优先、容错前置、持续小范围重构的原则，拒绝潦草交付能运行但难以维护的劣质代码，养成完整闭环的专业编程素养。