好代码，坏代码

22年年中看完《代码整洁之道》之后，常关注着相关信息，前段时间看到一本名叫《好代码·坏代码》的书，我感觉这名字起的很是“响亮”，于是将其读了一遍。这本书我看的纸质版，每个晚上看40分钟，读完历时一个月，全书读完花费约15小时。 本书分为三个部分：理论、实践与测试。 理论阐述软件工程师在编写代码时是如何考虑与权衡的：怎样的代码算是好的代码，好代码应该拥有怎样的结构，与其他工程师交流时该用怎样的代码契约，以及在错误发生时怎样通知才能更快地定位问题。 实践则是在讲理论知识可以怎样真正运用到代码中去。只每章的标题就很能说明问题： 编写易于理解的代码； 避免意外； 编写难以被误用的代码； 实现代码模块化； 编写可重用、可推广的代码。 这是理论中所提到6个代码质量支柱的前5个，也是书中篇幅最长，讲解最详细的部分。 代码质量的最末1个支柱是“编写可测试的代码并适量测试”，这也是本书的第三部分——单元测试，这部分分为理论和实践两个章节。 本书绝大部分内容，都是成对出现的。 标题中“好代码”对“坏代码”；具体章节内容先讲坏代码的“长相”、坏代码可能会造成的影响，待讲过“坏处”之后，作者再提出可能的优化方向，展示好代码该有的样子。 本书的组织方式，给我一种“提出问题，然后解决问题”的清晰感受。 开始阅读本书时，是刚完成一个小（为确认“小”的规模，我借助VS Code Counter统计了一下代码行数，一共12k）项目后端框架搭建不久，正在往搭起来的架子中添砖加瓦。 到整理本篇读书笔记时，这小项目的主体功能已基本完成。所以，整个阅读过程，亦是我的开发过程，这理论与实践的互相印证，使得以下4点，是我认识最深刻的。 一、代码契约 代码契约在书中的定义是： 工程师将不同代码段之间的交互视为一种契约：调用者必须履行一些义务，作为回报，调用的代码将返回预期的值或修改某些状态。不应该有任何不清晰或意外的情况。因为一切都该在契约中定义。这是最完美的情况，现实世界是并不完美的。契约有明确无疑的部分，也会存在并不明确的附属细则。好代码，应该尽量将不明确的点减少到最低，不过分依赖附属细则。 细化到项目中，以函数举例，一个函数的功能，应该由它本身的输入输出准确界定，而并非由相关文档、注释来辅助说明。文档是可能过期的，真正“说话算数”的，只是代码。我们写一个函数，要尽量保证它不需要额外的依赖项。 一切都该是准确的。 二、错误处理 我还在网易做游戏的时候，项目组内有一个口口相传，传了至少十几年的规则：服务端的报错要直接报出来，客户端的报错可以做兼容处理，但也该把堆栈打到log中去。 待读到本书“显式报错、隐式报错”时，真正感受到理论是来源于实践的，作者肯定写过许多代码，他的整理与大佬们的经验一致。 书中示例“寻找松露的狗”是很形象的比喻：我们借助狗的嗅觉找松露，好狗会在找到松露时立马停下并叫出声来，坏狗找到松露随意向周围走10步后再叫；明显好狗找松露的效率更高。 当代码中有错误出现时，是该立马让这错误报出来的。这能更准确定位问题，由此，能更快地解决问题。（经过本书的再次提醒，我将代码中好几处返回空值做兼容处理的地方，改成了断言。） 三、分层和模块 书中说“如果我们能将一个问题拆分为很多的小问题，并创建抽象层次，任何一段单独的代码看起来都不会很复杂，因为一次只需要理解几个概念。” 我是从这理念中受益匪浅的。软件开发中，分层与模块处处存在，大到网络协议的分层，中到引擎与逻辑的拆分，再小到我这项目，都使用了分层结构。其它的不提，以我的小项目举例，它的分层结构来源于Django 的REST framework框架： URL层列出接口列表； View层定义接口，处理接口权限和访问频次； Serializer层处理具体的逻辑； Models层只关注数据表的形式。 每个层当中，又拆分为（尽量）各不相关的小模块。借助REST framework设计系统，我在定位问题、迭代需求时，速度是很快的。 四、可读性与防御性设计 小时候切菜，老妈经常告诉我：“切完菜，菜刀全身不要伸出灶台，以免误碰到地上，掉落过程很危险；刀口要朝里，再拿的时候不给机会划到手。”这是生活中的防御性习惯。 代码如是。 代码应该是防御性设计的，要避免编写拥有误导性的函数，要减少调用者出现误用的可能性。模块、类、函数的命名，参数、变量的作用域，都该是含义准确的。 读完本书，我很是认同作者所传达出的观点——我们每个人都是会犯错误的；作为程序员，我们写的代码是肯定会出bug的。我们能做的，是认真对待自己的代码，多花心思在代码上面；是借助前人的经验，使用良好的代码风格，避免犯前人犯过的重复错误；最终减少bug的产量。 作者在介绍许多写代码原则之外，也说到“切忌生搬硬套规则，现实世界需求多变，我们是可以根据需求做些变化的。” 作者说本书适合有0~3年软件工程师工作经验的人阅读。我想将这年限再扩大些：1~10年经验的程序员们都可以读上一读。这两个数字由我自己的经验得来，如果刚毕业的我看本书，极可能看不下去；我现在敲代码快满10年，读完依然能有许多感悟，我认为是很值得看的。 本书的推荐语为：“看过《代码整洁之道》之后，不妨再看看《好代码·坏代码》。这两本书相辅相成，它们都专注于提升我们的编程技能，使我们写出更易懂的代码。”

在一本技术书里，怎么会有一份食谱啊！好离谱

值得花时间通读的一本书，里面讲到的原则大多数老程序员都不清楚，只有在脑中有好代码的标准，才有可能写出好代码。

挺好的一本书，休息时，没事看看，收获还挺多👀

最初工作时，只想着把功能完成就好了。写代码时只考虑业务逻辑，不会考虑什么异常，扩展，复用等内容。 本书定义了什么是好代码，同时给出了一些技巧。有了些工作经验的我在阅读这些内容时，很容易联想到实际项目代码中的各种问题。 技巧中很多都是些实用的经验主义，所以要结合实际项目来运用，具体问题具体分析。 以后写代码要根据这些内容多加思考后再动手。

老生常谈，感觉像是先用 ai 写好结构，然后再用 ai 填充，很多说了很没说一样的废话，偏偏又很通顺，像极了 ai。有没有用呢？这本书如果能把最开始喂给 ai 的那篇短文章拿出来，然后给刚学编程不久的人看，确实有点用。

有过一些体验理解，看完这本算是体系化了一些，还是要多多思考实操。理解需求，明确未来，分离变化和不变，独立，抽象简化思考。

日常代码提交的peer review大多拘于形式，整个团队的code review效果更好，但需要投入更多的时间。养成更好的习惯，写更好的代码，继续研读

good code, bad code.这本书适合cpp, java开发者。新手看了升级，老手看了顿悟。全书分三个部分:理论、实践、单元测试。提出代码质量的6大支柱，并分别介绍其现象、问题所在、解决方案，以及方案的优缺点。6大支柱并不孤立，是相互交织的，书中经常提到。 注:本书属于经验性总结内容，有的地方比较抽象。因此并不适合没有经验的初学者。

《好代码坏代码》从代码编写的角度简单讲述了好代码的why、what，详细介绍了how，比如：抽象层次、代码契约、错误处理、编写易于理解的代码、避免意外、编写难以被误用的代码、实现代码模块化、编写可重用可推广的代码、单元测试原则和实践。总体读下来谈不上经典，内容丰富，是一本偏经验总结性的书，缺少一定的体系完整性，后续可供查阅使用。