笔记：
- 时间与空间
- 时间换空间。对于可能被重用的中间计算结果，不存储、下次需要时重新计算。
- 空间换时间。对于可能被重用的中间计算结果，存储、下次需要时不重新计算。
- 应用与底层
- 举两个例子：
- 应用型：学会使用 JSON 解析库；
- 底层型：优化 JSON 解析库的效率；
- 以目前我的状态，更适合向应用型发展。可以说是堆业务，这可以快速解决实际问题，由此带来的成就感，大于把搜索效率提高一倍这样的成果。
- 当然，如果效率优化成为业务的核心时，还是会用户去优化底层。
- 另外，感觉目前大多数产品、大多数开发者都处于应用型、堆业务的状态。这没什么不好，虽然应用型是建立在底层的基础上，但如果没有应用的失去，底层也不会自动发展的。
- 举两个例子：
书摘
- 在节省空间方面无计可施时，将自己从代码中解脱出来，退回起点并集中心力研究数据，常常能有奇效。（数据的）表示形式是程序设计的根本。
- 使用数组重新编写重复代码。
- 封装复杂结构。当需要非常复杂的数据结构时，使用抽象术语进行定义，并将操作表示为类。
- 尽可能使用高级工具。超文本、名字—值对、电子表格、数据库、编程语言等都是特定问题领域中的强大的工具。
- 编码。对于比较难写的函数，我发现最容易的方法是使用方便的高级伪代码来构建程序框架，然后将伪代码翻译成要实现的语言。
- 代码调优
- 首先确定程序中开销较大的部分，然后进行少量的修改，以提高其运行速度。“代码调优”并不总是恰当的方法，也不太有趣，但是有时候它确实可以使程序的性能大为改观。
- 代码调优的最重要原理就是尽量少用它。
- 不成熟的优化是大量编程灾害的根源，它会危及程序的正确性、功能性以及可维护性。当可能的危害影响较大时，请考虑适当将效率放一放。
- 软件的其他许多性质和效率一样重要，甚至更重要。
- 性能
- 对程序进行性能监视的结果通常类似：多数的时间都消耗在少量的热点代码上，而余下的代码则很少执行。
- 性能监视可以帮助我们找到程序中的关键区域；对于其他区域，我们遵循有名的格言“没有坏的话就不要修”。
- 效率问题可以由多种方法来解决。只有在确信没有更好的解决方案时才考虑进行代码调优。
- 正确理解所遇到的问题。与用户讨论问题产生的背景。问题的陈述通常就包含了与解决方案有关的想法；
- 提炼出抽象问题。简洁、明确的问题陈述不仅可以帮助我们解决当前遇到的问题，还有助于我们把解决方案应用到其他问题中。
- 考虑尽可能多的解法。很多程序员很快就发现了问题的“解决方案”，他们只愿意花1分钟的时间思考，然后花一天的时间来写代码，而不是先花1个小时来思考，再用一个小时来写代码。
- 对程序员的10条建议：
- 解决正确的问题
- 探索所有可能的解决方案
- 观察数据
- 使用粗略估算
- 利用对称性
- 利用组件做设计
- 建立原型
- 必要时进行权衡
- 保持简单
- 追求优美