- mmexport1728395341799.d

最近花时间读了clean code，有些代码例子没看，十几页没高亮挺难受的，这是个遗憾。书里总结了若干的建议，都是鲍勃大叔几十年的最佳实践，并且解释了为啥要这样做。我并不分享这些最佳实践，想了解这块的可以直接看原著17章，算是做了一个总结。

这里分享一些勾画的句子。

2024-09-14
代码质量与其整洁度成正比。

2024-09-14
在Scrum和敏捷（Agile）的日子里，人们关注的是快速将产品推向市场。我们要求工厂全速运转、生产软件。

2024-09-14
供职于贝尔软件生产研究实验室（Bell Labs Software Production Research）——没错，就是生产！——时，我们有些不太严密的发现，认为前后一致的缩进风格明显标志了较低的缺陷率。

2024-09-14
在Scrum中，我们使一切可见。我们晾出脏衣服。我们坦承代码状态，因为它永不完美。我们日渐成为完整的人，配得起神的眷顾，也越来越接近细节中的伟大之处。

2024-09-14
扯淡！我们永远抛不掉代码，因为代码呈现了需求的细节。在某些层面上，这些细节无法被忽略或抽象，必须明确之。将需求明确到机器可以执行的细节程度，就是编程要做的事。而这种规约正是代码。
2024-09-14
我们都曾经瞟一眼自己亲手造成的混乱，决定弃之而不顾，走向新一天。我们都曾经看到自己的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日再回头清理。当然，在那些日子里，我们都没听过勒布朗（LeBlanc）法则：稍后等于永不（Later equals never）。

2024-09-14
Bjarne Stroustrup，C++语言发明者，C++Programming Language（中译版《C++程序设计语言》）一书作者。
我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。

2024-09-14
消除重复和提高表达力让我在整洁代码方面获益良多，只要铭记这两点，改进脏代码时就会大有不同。

2024-09-14
减少重复代码，提高表达力，提早构建简单抽象。这就是我写整洁代码的方法。

2024-09-17
取好名字最难的地方在于需要良好的描述技巧和共有文化背景。与其说这是一种技术、商业或管理问题，还不如说是一种教学问题。其结果是，这个领域内的许多人都没能学会做得很好。

2024-09-17
函数应该做一件事。做好这件事。只做这一件事。

2024-09-17
要确保函数只做一件事，函数中的语句都要在同一抽象层级上。

2024-09-17
函数中混杂不同抽象层级，往往让人迷惑。读者可能无法判断某个表达式是基础概念还是细节。更恶劣的是，就像破损的窗户，一旦细节与基础概念混杂，更多的细节就会在函数中纠结起来。
自顶向下读代码：向下规则
我们想要让代码拥有自顶向下的阅读顺序。\[5\]我们想要让每个函数后面都跟着位于下一抽象层级的函数，这样一来，在查看函数列表时，就能偱抽象层级向下阅读了。我把这叫做向下规则。
换一种说法。我们想要这样读程序：程序就像是一系列 TO起头的段落，每一段都描述当前抽象层级，并引用位于下一抽象层级的后续TO起头段落。

2024-09-17
有足够特殊的理由才能用三个以上参数（多参数函数）——所以无论如何也不要这么做。

2024-09-17
向函数传入布尔值简直就是骇人听闻的做法。

2024-09-17
把指令与询问分隔开来，防止混淆的发生：

2024-09-17
重复可能是软件中一切邪恶的根源。许多原则与实践规则都是为控制与消除重复而创建。

2024-09-17
很多时候，简单到只需要创建一个描述与注释所言同一事物的函数即可。

2024-09-17
所谓每个函数都要有 Javadoc 或每个变量都要有注释的规矩全然是愚蠢可笑的。

2024-09-17
直接把代码注释掉是讨厌的做法。别这么干！

2024-09-18
实体变量应该在类的顶部声明。这应该不会增加变量的垂直距离，因为在设计良好的类中，它们如果不是被该类的所有方法也是被大多数方法所用。

2024-09-18
概念相关。概念相关的代码应该放到一起。相关性越强，彼此之间的距离就该越短。

2024-09-18
看看这些等式读起来多舒服。乘法因子之间没加空格，因为它们具有较高优先级。加减法运算项之间用空格隔开，因为加法和减法优先级较低。
不幸的是，多数代码格式化工具都会漠视运算符优先级，从头到尾采用同样的空格方式。在重新格式化代码后，以上这些微妙的空格用法就消失殆尽了。

2024-09-18
隐藏实现并非只是在变量之间放上一个函数层那么简单。隐藏实现关乎抽象！类并不简单地用取值器和赋值器将其变量推向外间，而是曝露抽象接口，以便用户无需了解数据的实现就能操作数据本体。

2024-09-18
过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。面向对象代码便于在不改动既有函数的前提下添加新类。

2024-09-18
反过来讲也说得通：
过程式代码难以添加新数据结构，因为必须修改所有函数。面向对象代码难以添加新函数，因为必须修改所有类。
所以，对于面向对象较难的事，对于过程式代码却较容易，反之亦然！

2024-09-18
著名的得墨忒耳律（The Law of Demeter）\[2\]认为，模块不应了解它所操作对象的内部情形。如上节所见，对象隐藏数据，曝露操作。这意味着对象不应通过存取器曝露其内部结构，因为这样更像是曝露而非隐藏其内部结构。

2024-09-21
谁都知道TDD要求我们在编写生产代码前先编写单元测试。但这条规则只是冰山之巅。看看下列三定律\[2\]：
定律一 在编写不能通过的单元测试前，不可编写生产代码。
定律二 只可编写刚好无法通过的单元测试，不能编译也算不通过。
定律三 只可编写刚好足以通过当前失败测试的生产代码。

2024-09-21
测试代码和生产代码一样重要。它可不是二等公民。它需要被思考、被设计和被照料。它该像生产代码一般保持整洁。

2024-09-21
这些测试显然呈现了构造-操作-检验（BUILD-OPERATE-CHECK）\[3\]模式。每个测试都清晰地拆分为三个环节。第一个环节构造测试数据，第二个环节操作测试数据，第三个部分检验操作是否得到期望的结果。

2024-09-21
我认为，单个断言是个好准则\[8\]。

2024-09-21
单元测试应该恰好在使其通过的生产代码之前编写。如果在编写生产代码之后编写测试，你会发现生产代码难以测试。

2024-09-21
单一权责原则（SRP）\[2\]认为，类或模块应有且只有一条加以修改的理由。该原则既给出了权责的定义，又是关于类的长度的指导方针。类只应有一个权责——只有一条修改的理由

2024-09-21
当类丧失了内聚性，就拆分它！

2024-10-01
据Kent所述，只要遵循以下规则，设计就能变得“简单”：
运行所有测试；
不可重复；
表达了程序员的意图；
尽可能减少类和方法的数量；
以上规则按其重要程度排列。

2024-10-01
遵循SRP的类，测试起来较为简单。测试编写得越多，就越能持续走向编写较易测试的代码。

2024-10-01
在重构过程中，可以应用有关优秀软件设计的一切知识。提升内聚性，降低耦合度，切分关注面，模块化系统性关注面，缩小函数和类的尺寸，选用更好的名称，如此等等。这也是应用简单设计后三条规则的地方：消除重复，保证表达力，尽可能减少类和方法的数量。

2024-10-01
“对象是过程的抽象。线程是调度的抽象。”
——James O Coplien\[1\]

2024-10-01
并发常常需要对设计策略的根本性修改。

2024-10-07
当然，糟糕的代码可以清理。不过成本高昂。随着代码腐败下去，模块之间互相渗透，出现大量隐藏纠结的依赖关系。找到和破除陈旧的依赖关系又费时间又费劲。另一方面，保持代码整洁却相对容易。早晨在模块中制造出一堆混乱，下午就能轻易清理掉。更好的情况是，5分钟之前制造出混乱，马上就能很容易地清理掉。
所以，解决之道就是保持代码持续整洁和简单。永不让腐坏有机会开始。

贴一个不错得总结文章，原自知乎。

豆瓣评分8.6！将近400页的《代码整洁之道》，其实重点就5个点 - 关于编程哪些事的文章 - 知乎
https://zhuanlan.zhihu.com/p/131375705