简简单单几条原则：
- 模块的用户永远也不应该被模块的行为所迷惑
- 模块要尽可能小，但又不能太小
- 代码应该被重用，而不是被拷贝
- 模块之间的依赖性应该尽可能降到最小
- 错误应该尽早被检测出来，最好是在编译时刻
重点讲两个。
模块的用户永远也不应该被模块的行为所迷惑
最简单的方式是写下多且准确的注释，不过我相信大部分很难做到“准确”。我习惯引用涛神的话，将该条规则表述为要求“代码能够自解释”。
看起来简单做起来难。对于Java程序猿，有几种必要的方式可以帮助你尽可能的做到这一点：
- 除了对外公布的API和部分重要模块，要求自己不加任何注释
- 使用清晰明确的命名，包括变量、函数、类
- 被确定命名的类、函数、变量，其功能应单一、确定
- 使用的时候再声明/创建，并尽可能进行显示的初始化
- 严格明确对外保证的边界，将精力放在保证公开接口，而不是私有实现
- 恰当的使用异常和日志，不要用日志代替所有异常，但或许很多ERROR级别的日志都可以用异常来代替
- 虽然与原则2相悖，但如果合并模块不会使系统变的难以理解，为了简化系统结构我们建议合并部分模块
- 除非对外发布后不可更改（比如java.util.Set接口），否则，在能保持良好系统结构的前提下，不要面向未来开发（这一点可能很难接受，不过想想什么时候才应该应用设计模式呢？什么时候时候才应该优化性能呢？有需要的时候。如果现在不需要，就不要面向未来开发。）
上述方式并不是充分的，我可能会在以后的开发中继续补充重要的方式，也可能不会。因为你需要掌握的是如何思考，而不是记住这些死知识。
上述原则部分参考自Google Java Style Guide，建议二者结合阅读。
错误应该尽早被检测出来，最好是在编译时刻
刷题的时候要时刻牢记：
如果可能，尽早的处理边界条件。
对于工程开发，可以改编如下：
如果可能，尽早的发现并处理错误。
这里的错误包括异常、逻辑错误等。分为两个方面，发现、处理：
- 发现：要求我们尽早的发现错误，最好是编译期；如果在运行期，就要在处理正常逻辑之前，尽早的检测出错误。特别的，在开发期间，编写完备的测试用例，尽早发现逻辑错误。
- 处理：发现错误还不够，我们要处理错误。如果是编译或开发期间发生的错误，修改代码即可；如果是运行期发生的错误，记录日志、提前退出、抛出异常都是值得考虑的选择，选择当前保证和当前场景下最合适的。
该原则要和原则1结合起来（任何原则都要和原则1结合），所以记得让你发现、处理错误的代码也是自解释的。
