什么是好代码

好代码要符合基本的编码原则

1.KISS

KISS: Keep It Simple and Straight 保持简单和直接, 适当隐藏复杂性

或者

KISS: Keep It Simple and Stupid 保持简单, 象傻瓜一样, 不要让别人多加思考

软件接口或 API 的设计要让人一看就明白, 一看就知道作者的意图和想法, 如何使用它, 有什么结果和可能的异常及副作用. 看过很多代码， 踩过许多坑， 大多是作者或者我自己使用了出乎意料的实现， 不做好必要的抽象和封装， 复杂的判断和算法到处都是

2.DRY – Don't Repeat Yourself

别重复你自己, 如有重复代码, 请抽象或重用

3.SRP - Single Responsibility Principle

单一职责原则: 就一类而言, 应该仅有一个引起它变化的原因

也有一个别称 DOTADIW - Do One Thing and Do It Well 就做一件事并做好它

4.OCP - Open Close Principle

开放封闭原则: 软件实体(类,模块,函数等)应该是可以扩展的, 但是不可修改

5.LSP

LSP替换基类原则: 子类型应该可以替换掉它们的基类型

6.DIP

DIP依赖倒置原则: 抽象不应该依赖于细节, 细节应该依赖于抽象

7.ISP

ISP接口隔离原则: 不应该强迫客户依赖于它们不用的方法, 接口属于客户, 不属于它所在的类层次结构

8.REP

REP重用发布等价原则: 重用的粒度就是发布的粒度

9.CCP

CCP共同封闭原则: 包中的所有类对于同一类性质的变化应该是共同封闭的. 一个变化若对一个包产生影响, 则将对包中所有的类产生影响, 而对于其他的包不造成任何影响

10.CRP

CRP共同重用原则: 一个包中的所有类应该是共同重用的. 如果重用了包中的一个类, 那么就要重用包中的所有类

11.ADP

ADP无环依赖原则: 在包的依赖关系图不允许存在环

12.SDP

SDP稳定依赖原则: 朝着稳定的方向进行依赖.

13.SAP

SAP稳定抽象原则: 包的抽象程度应该和其稳定程度一致

好代码要易于理解，测试和修改

封装好复杂性，区分开经常变化与基本不变的代码, 适当抽取易变参数作为配置

还是书里那句话，高内聚，低耦合，依赖倒置

例如最常用的 MVC 模式，为什么我们要分成模型，视图和控制器三块，原因之一就在于分开易变的与不易变的，分开不会在一起变化的部分，减小每次修改的范围。

如果某个方面的功能需要修改，最好是改个配置， 其次是加几行代码或传个不同参数，最差的就是改多个地方，加多个判断， 作霰弹式修改。

 

 

 

转载于:https://www.cnblogs.com/ZJOE80/p/10114252.html