原则
Danger
最根本的原则是:将总是一起变化的东西放在一块儿。
所有超类都应该是抽象(abstract)的。
小步前进,情况越复杂,步子就要越小。
性能优化的一般指导方针,不用过早担心性能问题。
短函数常常能让编译器的优化功能运转更良好,因为短函数可以更容易地被缓存
营地法则:保证你离开时的代码库一定比来时更健康
命令与查询分离(Command-Query Separation)
- 应该去追求编写人能够读懂的而不是仅机器能够读懂的代码
- 重构过程的精髓所在:小步修改,每次修改后就运行测试
- 如果重构引入了性能损耗,先完成重构,再做性能优化。
- 请保持代码永远处于可工作状态
- 添加新功能时,我不应该修改既有代码,只管添加新功能;重构时我就不能再添加功能,只管调整代码的结构。
- 如果一种灵活性会增加软件复杂度,就必须先证明自己值得被引入
要判断是否应该为未来的变化添加灵活性,我会评估"如果以后再重构有多困难",只有当未来重构会很困难时,我才考虑现在就添加灵活性机制。 YAGNI(you arenʼt going to need it)你不会需要它
- 尽量控制作用域
- 代码分层,单向调用
- "对象组合优于类继承"("组合"跟"委托"是同一回事),这句话更确切的表述可能应该是"审慎地组合使用对象组合与类继承,优于单独使用其中任何一种
- 封装,继承 消除重复代码
- 多态 消除 switch
- 数据查询、数据更新 区分开 (入参校验,数据查询,数据入库,日志,事件触发)
- 里氏代换原则:任何基类可以出现的地方,子类一定可以出现。(子类不重写父类方法)
- 如果你的某个抽象类其实没有太大作用,请运用折叠继承体系
- 每当感觉需要以注释来说明点什么的时候,我们就把需要说明的东西写进一个独立函数中,并以其用途(而非实现手法)命名。
- 即便只是少量的数据,我们也愿意将它封装起来,这是在软件演进过程中应对变化的关键所在。
- 依恋去情节:判断哪个模块拥有的此函数使用的数据最多,然后就把这个函数和那些数据摆在一起
一个函数跟另一个模块中的函数或者数据交流格外频繁,远胜于在自己所处模块内部的交流,这就是依恋情结的典型情况。