经济的代码 编程规范笔记，代码精进之路学习笔记

经济的代码

学习了范学雷的代码精进之路，链接：https://geek.youkuaiyun.com/educolumn/1a6591fa7f78787ce6defcb634881bbf
对第二部分的学习记录，对于安全性的学习，有待更新。

1.什么是代码的性能：如何管理各种计算机资源
2.学习性能的必要性：学习性能，才能让我们里技术更进，实际的工作中编写代码的性能也是潜在的考核要求。
3.代码性能的必要性：代码的质量是网络安全防护的根本，越早考虑性能问题，支付的成本就越小，带来的价值就越大。

考虑性能问题的时间点：

在第一时间将事情做正确
性能工程思维通过流程“左移”，把性能问题从一个一次性的测试行为，变成一个贯穿软件开发周期的持续性行为；从被动地接受问题审查，变成主动地管理质量。

高效的代码的标准

用户体验：

等待时间短

Apdex = (1 × 满意样本数 ＋ 0.5 × 容忍样本数 + 0 × 挫败样本数) / 样本总数

体验一致

不一致的服务，会导致更多的操作，会导致更多的风险与负担。比如网页卡顿是不必要的刷新行为。

代码的资源消耗：

1.把资源使用得更有效率
2.能够使用好更多的资源
3.控制算法的复杂程度

避免过度设计

避免需求膨胀：

1.识别最核心的需求

什么是必须要做的功能
只有从最终用户的眼里看需求，才能够识别什么是最核心的需求，什么是衍生的需求，什么是无效的需求。这样，我们才能找到一个最小的子集，那就是现在就必须满足的需求。

2.不要一步到位

永远不要考虑不重要的需求。
迭代演化的过程中，会有新的需求产生，会有原本看起来重要的需求变得不必要。

3.避免过度设计

过度设计导致过度复杂，过度复杂导致效率降低、危险加剧、性能降低。如果保持简单而不是复杂化，大多数系统都能发挥最佳作用。这就是“少就是多”的魅力。

简单与直观

简洁是智慧的灵魂，我们要充分理解这一点。

简洁是需要有一个基本认识，并在编程中遵守的原则。

简单直观是快速行动的唯一办法

简洁是方法，轻松快速的行动是目的。
整体的快速行动，需要每个部分的简单直观作为支撑。

简单直观减轻沟通成本

事情越简单，理解的门槛越低。

简单直观降低软件风险

复杂意味着理解、实现、测量、实施、维护的困难。

如何做到简单直观

1.使用小的代码块：一个代码块只做一件事情
2.遵守约定的惯例：代码小块易于使用
3.花时间做设计：在拆解问题和验证代码的循环中，设计自己的代码。
4.借助有效的工具：纸笔、插件、思维导图。利用方便好用的工具理清代码的逻辑。

简单又直观的接口

一个接口一件事情

	1.一件事就是一件事，不是两件事，也不是三件事。

	2.这件事是独立的。

	3.这件事是完整的。

减少依赖关系

接口规范里交待清楚严格的调用顺序要求

使用方式要“傻”

方便、皮实的接口，才是好用的接口。

减少内存使用，减轻内存管理负担

这个部分受限于我的经验不足不做进一步解释。抱歉。

使用更少的内存
减少实例数量
避免不必要的实例
避免使用原始数据类
使用单实例模式
减小实例的尺寸
不可变的类
无法修改的对象

黑白灰，理解延迟分配的两面性

同上

使用有序的代码，调动异步的事件

异步编程的必要性

为了更有效地利用计算资源，我们使用有序的代码，调动起独立的事件。

从过程到事件

从事件的角度来编写和理解代码。

实现异步的方法

没涉及到暂时没法理解

有哪些招惹麻烦的性能陷阱

同上

编写可持续发展的代码的方法

增长对软件的要求，就是要有处理越来越多工作和越来越大规模的能力或者潜力。这种能力，通常称之为可伸缩性（Scalability）
可扩张性包括：规模扩张能力（Scalability）和功能扩展能力（Extensibility）。

两种规模扩张方式

规模垂直扩张：提高同一个处理单元处理更多负载的能力。
规模水平扩张：增加更多的处理单元，来处理更多的负载。

状态数据

采用规模水平扩张时，一定要小心代码的状态数据能不能同步。另外，由于软件依赖的基础设施问题，还要测试软件的运行平台是否能够很好地支持规模水平扩张。

无状态数据

无状态的数据，可以降低规模水平扩张的技术复杂性，在技术上有了更多的改进空间。

分离无状态数据

设计一个具有规模扩张能力的软件架构，分离无状态数据和状态数据，既可以提高规模水平能力，也可以提高规模垂直扩张能力。

怎么尽量“不写”代码？

最有效率的编码就是少编写代码，甚至不编写代码。

不要重新发明轮子

复用
一般来说，当我们使用类似的代码或者类似的功能超过两次时，就应该考虑这样的代码是不是可以复用了。

推动轮子的改进

不要重复多个轮子

一个软件产品中，一个单一功能，只应该有一个轮子。

该放手时就放手

能跑就行！
我们每个人都会写很多烂代码，过去写过，未来可能还会再写。这些烂代码，如果运行得很好，没有出现明显的问题，我们就放手吧。

编写经济代码的检查清单

需求评审

• 需求是真实的客户需求吗？
• 要解决的问题真实存在吗？
• 需求具有普遍的意义吗？
• 这个需求到底有多重要？
• 需求能不能分解、简化？
• 需求的最小要求是什么？
• 这个需求能不能在下一个版本再实现？

设计评审

• 能使用现存的接口吗？
• 设计是不是简单、直观？
• 一个接口是不是只表示一件事情？
• 接口之间的依赖关系是不是明确？
• 接口的调用方式是不是方便、皮实？
• 接口的实现可以做到不可变吗？
• 接口是多线程安全的吗？
• 可以使用异步编程吗？
• 接口需不需要频繁地拷贝数据？
• 无状态数据和有状态数据需不需要分离？
• 有状态数据的处理是否支持规模水平扩张？

代码评审

• 有没有可以重用的代码？

• 新的代码是不是可以重用？

• 有没有使用不必要的实例？

• 原始数据类的使用是否恰当？

• 集合的操作是不是多线程安全？

• 集合是不是可以禁止修改？

• 实例的尺寸还有改进的空间吗？

• 需要使用延迟分配方案吗？

• 线程同步是不是必须的？

• 线程同步的阻塞时间可以更短吗？

• 多状态同步会不会引起死锁？

• 是不是可以避免频繁的对象创建、销毁？

• 是不是可以减少内存的分配、拷贝和释放频率？

• 静态的集合是否会造成内存泄漏？

• 长时间的缓存能不能及时清理？

• 系统的资源能不能安全地释放？

• 依赖哈希值的集合，储存的对象有没有实现hashCode()和equals()方法？

• hashCode()的实现，会不会产生撞车的哈希值？

• 代码的清理，有没有变更代码的逻辑？