整洁代码的艺术
整洁代码的艺术的笔记。少即是多！
参考：
复杂性
选择语言、项目、库、技术、编辑器等等，都带来了复杂性，造成了巨大的混乱。我如何开始 成了初学者的常见问题。
最好的方式是找个实际代码项目，边做边学，而不是先学后做。不要给自己增加复杂性，让自己陷入了无穷无尽的混乱中。
复杂性无处不在，常常带来隐性成本，让人望而却步。在编程的各个阶段都追求简单和专注，来简化事项。
复杂性损坏生产力，降低注意力。
以下方法：
- 梳理一天的工作，少做一些事，把精力集中在重要的任务上。
- 对于单个项目，摒弃所有非必要特性，专注于最小可行产品。完成并发布它，高效、快速地验证。
- 尽量编写简单精炼的代码。
- 少花时间与精力在过早优化上。
- 锁定用于编程的大块时间，避免分心。
- 实践 Unix 哲学，代码功能只针对一个目标（做好一件事）。
- 在设计方案中贯彻简化原则。
八二原则
80/20 原则，大部分效果出自少数起因。
最小可行产品
最小可行产品只做最必要的特性，剥离其他所有特性，快速测试和验证假设，而不会浪费大量时间来实现用户最终可能不会使用的特性。
少即是多，与其着急于动手实现每个特性，不如花时间想清楚要实现什么特性。
不写非必要的代码是写出整洁和简单代码的最牢靠手段。
编写整洁和简单的代码
整洁代码易于阅读、理解和修改。
程序员为了写新代码，得花费大部分时间阅读旧代码。如果旧代码易于阅读，则将大大加快阅读进程。
太长的代码会导致许多其他复杂性问题。
改进代码、减少复杂度就是所谓的 重构。
一些原则：
- 所有文件和模块都是必需的吗？能否做强其中一些，减少代码中的相互依赖关系？
- 可以将巨大、复杂的文件切分为两个简单的文件吗？
- 可以采用既有库，从而移除多行代码吗？
- 可以利用缓存机制来避免重复计算同一个结果吗？
- 站在巨人的肩膀上，避免重复造轮子。
- 为人写代码，而不是为机器。
- 正确命名。
- 遵循标准。
- 使用注释。
- 避免非必要注释。
- 避免编写重复的代码。
- 单一权责原则，每个函数都应该承担一件主要工作。
- 测试。
- 小即是美。
- 应当尽量减少代码对象之间的依赖关系。
- 不需要的代码就应该删掉。
- 不要使用太多的缩进层级。
避免过早优化
优化没有问题，但过早优化会将宝贵的资源（时间、精力、代码行）投入到非必要的代码优化上。
心流
心流体验是一种完全沉浸于手头工作的状态：专注。你忘记时间，进入超意识状态。
做好一件事
Unix 哲学：
- 编写只做一件事，并且把那件事做好的程序；
- 编写能一起工作的程序；
- 编写处理文本流的程序，因为文本流是通用接口。
Unix 是一种设计哲学，它启发了包括 Linux 和 macOS 在内的流行操作系统。
只做一件事，做好这件事（do one thing and do it well）。
Unix 哲学的基本概念是打造易于扩展和维护的简明、精炼、模块化代码。
通过让每个函数聚焦于只实现一个目的，改进了代码的可维护性和可扩展性。
对然单个子程序看上去太小甚至太细碎，但你能将这些子程序组合起来，创建更为复杂却易于调试的程序。
有用的Unix原则
一些有用的 Unix 原则：
- 每个函数做好一件事
- 简单胜于复杂
- 小即是美
- 降低复杂度
- 改进可维护性
- 改进可测试性
- 尽快打造原型
- 可移植性胜于效率
- 在纯文本中保存数据
- 如常见的 CSV 文件
- 使用软件杠杆获得优势
- 避免使用强制式用户界面
- 把每个程序都写成过滤器
- 在有限资源限制的世界中，先发布差的一些东西，常常更有效率。
- 整洁代码胜于机灵代码
- 将程序设计成能与其他程序相连接
- 编写健壮的代码：让代码不易被破坏。
- 使用版本控制系统，保证能恢复之前的代码
- 定期备份数据，使其可恢复
- 使用分布式，避免单点故障
- 尽量修复——但尽早暴露失败
- 避免手工操作——尽量编写能写程序的程序
设计中的少即是多
如何实现极简设计：
- 留白
- 去除设计元素
- 移除特性
- 减少字体和颜色
- 一以贯之
专注
熵在热力学和信息论等领域中广为人知。熵定义了系统中随机性、无序性和不确定性的程度。熵增意味着增加了随机性和混乱，熵减意味着秩序和可预测性。
热力学第二定律，系统的熵随时间推移而增加，从而导致高熵状态。