要想尽办法减少依赖性。
高德纳——Hoare的至理名言：不成熟的优化是万恶之源。
第5条 一个实体（变量、类、函数、名称空间、模块和库）应该只有一个紧凑的职责。
摘要：一次只解决一个问题。随着实体的变大，其职责范围自然也会扩大，但是职责不应该发散。
第6条 正确、简单和清晰第一
摘要： KISS :(Keep it simple software) : 正确优于速度，简单优于复杂，清晰优于机巧，安全优于不安全。
第7条 编程中应知道何时和如何考虑可伸缩性
摘要： 如能证明优化的必要，则应该集中精力改善算法的O(N)复杂性，而不是进行小型的优化，比如节省一个多余的加法算法。
第8条 不要进行不成熟的优化
不成熟的优化： 以性能为名，使设计或代码更复杂，从而导致可读性更差。毫无必要的预测及无法度量的优化行为其实根本不能使程序运行得更快，这种情况简直太常见了。
第9条 不要进行不成熟的劣化
摘要：
第25条：尽量使用引用传递而非值传递。
第28条：尽量使用前缀 ++i，而非后缀（减少了一次拷贝操作）。
第48条： 在构造函数中使用赋值操作而不是初始化列表。
第10条 尽量减少全局和共享数据
初始化顺序规则是非常难于掌握的，应该尽量避免使用。如果不得不用的，则应充分了解编译的顺序，小心使用。
命名空间作用域中的对象，静态成员对象，或者跨线程或跨进程 共享的对象，会减少多线程和多处理器环境中的并行性， 往往造成瓶颈。 用通信方式（如消息队列）代替数据共享。
应该尽量减少类之间的耦合，减少交互。
第11条 隐藏信息
隐藏内部的信息。
第12条 懂得何时和如何进行并发性编程。
确保线程安全。C++标准中并没有多线程，因此，若要使用多线程，应考虑：
（1） 参考目标平台（Windows\Linux\solaris等）的文档，了解该平台的同步化原语：典型的原语包括 从轻量级的 原子整数操作 到 内存障栅（memory barrier），再到 进程内 和 跨进程的互斥体。
（2）最好将平台的原语用自己设计的抽象包装起来。 pthread 库。
（3）确保正在使用的类型在多线程程序中使用是安全的。
（3.1） 保证非共享的对象是相互独立的。
（3.2）记载调用者在不同线程中使用该类型的同一个对象需要做什么。
第13条