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年，读完依然能有许多感悟，我认为是很值得看的。

本书的推荐语为：“看过《代码整洁之道》之后，不妨再看看《好代码·坏代码》。这两本书相辅相成，它们都专注于提升我们的编程技能，使我们写出更易懂的代码。”

最后，我摘抄书中两段简单代码作为结尾，让我们看看好代码与坏代码的区别：

// 坏代码
class T {
    Set<String> pns = new Set();
    Int s = 0;

    Boolean f(String n) {
        return pns.contains(n);
    }

    Int getS() {
        return s;
    }
}

Int? s(List<T> ts, String n) {
    for (T t in ts) {
        return t.getS();
    }
    return null;
}

// 好代码
// 此处主要体现在命名准确性上，更多的对比，请翻阅原书
class Team {
    Set<String> playerNames = new Set();
    Int Score = 0;

    Boolean containsPlayer(String playerName) {
        return playerNames.contains(playerName);
    }

    Int getScore() {
        return score;
    }
}

Int? getTeamScoreForPlayer(List<Team> teams, String playerName) {
    for(Team in teams) {
        if(team.containsPlayer(playerName)) {
            return team.getScore();
        }
    }

    return null;
}

↓↓↓欢迎关注