原则

Danger

最根本的原则是：将总是一起变化的东西放在一块儿。

所有超类都应该是抽象（abstract）的。

小步前进，情况越复杂，步子就要越小。

性能优化的一般指导方针，不用过早担心性能问题。

短函数常常能让编译器的优化功能运转更良好，因为短函数可以更容易地被缓存

营地法则：保证你离开时的代码库一定比来时更健康

命令与查询分离（Command-Query Separation）

  • 应该去追求编写人能够读懂的而不是仅机器能够读懂的代码
  • 重构过程的精髓所在：小步修改，每次修改后就运行测试
  • 如果重构引入了性能损耗，先完成重构，再做性能优化。
  • 请保持代码永远处于可工作状态
  • 添加新功能时，我不应该修改既有代码，只管添加新功能；重构时我就不能再添加功能，只管调整代码的结构。
  • 如果一种灵活性会增加软件复杂度，就必须先证明自己值得被引入

    要判断是否应该为未来的变化添加灵活性，我会评估"如果以后再重构有多困难"，只有当未来重构会很困难时，我才考虑现在就添加灵活性机制。 YAGNI(you arenʼt going to need it)你不会需要它

  • 尽量控制作用域
  • 代码分层，单向调用
  • "对象组合优于类继承"（"组合"跟"委托"是同一回事）,这句话更确切的表述可能应该是"审慎地组合使用对象组合与类继承，优于单独使用其中任何一种
  • 封装，继承 消除重复代码
  • 多态 消除 switch
  • 数据查询、数据更新 区分开 (入参校验，数据查询，数据入库，日志，事件触发)
  • 里氏代换原则：任何基类可以出现的地方，子类一定可以出现。(子类不重写父类方法)
  • 如果你的某个抽象类其实没有太大作用，请运用折叠继承体系
  • 每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。
  • 即便只是少量的数据，我们也愿意将它封装起来，这是在软件演进过程中应对变化的关键所在。
  • 依恋去情节：判断哪个模块拥有的此函数使用的数据最多，然后就把这个函数和那些数据摆在一起

    一个函数跟另一个模块中的函数或者数据交流格外频繁，远胜于在自己所处模块内部的交流，这就是依恋情结的典型情况。