阅读建议
一些关于如何设计的原则和建议
逐条记录
Simple，but not simpler！
应该追求简洁而不是过于简单。
不考虑设计的快速开发会形成技术债务。
设计是对未来的投入，但不是越多越好。
好的封装可以减少依赖，简单的接口可以避免晦涩。也就是减少了复杂性。
依赖和晦涩就是复杂性。
软件是分层的，复杂性应该下移。
具有通用功能的模块更具深度，更通用的接口在面对需求变化的时候，更容易使用。
设计的艺术在于决定需求和接口应该抽象到哪个层次。
如果你发现不同的层具有相同的抽象，那也许你的分层有问题。
模块不是越多越好：
复杂性可能来源于系统模块的数量
更多的模块也许意味着需要额外的代码来管理和协调
更多的模块可能带来许多依赖
更多的模块可能带来重复的代码，而重复的代码是恶魔
在以下的情况下，需要考虑合并模块：
模块之间共享信息
合并后的接口更简单
合并后减少了重复的代码
过度防御性的编程是无意义的。
而很多时候，程序员捕获了异常并不知道该如何处理，干脆往上层扔，这就违背了封装原则。
降低复杂度的一个原则就是尽可能减少需要处理的异常可能性。
而最佳实践就是确保错误终结，例如删除一个并不存在的文件，与其上报文件不存在的异常，不如什么都不做。
注释的原则：
好的代码是自解释的，优先保证良好的代码风格
注释应该和代码同步更新
注释是给人阅读的，应该是有意义的信息
软件要保持一致性，入乡随俗，不要随便改变命名约定
系统开发是测试先行
软件设计是注释先行
性能优化需要先找到影响性能的核心单元
面向对象，对于继承，基于接口的继承要优于基于实现的继承
单元测试是必要的
测试驱动，测试驱动的问题是关注功能，而非找到最佳设计
设计模式，设计模式的问题可能导致过度应用
Getter/Setter， 这个模式可能是冗余的，也许不如直接暴露成员更简单