今天来思考下如何评价代码质量？
业界公认比较认可的七大标准：
可维护性（maintainability）、可读性（readability）、可扩展性（extensibility）、灵活性（flexibility）、简洁性（simplicity）、可复用性（reusability）、可测试性（testability）。
一、可维护性
不会因为新增功能feature或bugfix引入bug，可以比较高效地完成新功能开发和bugfix，代码易维护，维护成本和风险低
二、可读性
代码不只是需要遵循编程语言的语法规则，还需要遵循团队的编码规范约定，需要让团队内部的同学可以相互轻松看懂对方写的代码，比如是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等，一般团队都需要依靠编码规范来约束，通过代码review来检测可读性，可读性高的代码，负责review的同学比较快速读懂代码，没有疑问直击代码问题，反之，代码疑问多看不懂，review效果大打折扣，所以，代码可读性可以大大增强代码review效果，降低风险。
三、可扩展性
对内封闭修改，对外开放扩展，需要符合“高内聚低耦合”代码设计原则，扩展新增功能不会破坏修改内部代码引入不必要的风险，而是通过扩展设计，保证新增功能代码相对独立，不影响原来代码逻辑；尽量做到少修改原代码，而实现新功能。
四、可复用性
可复用性就是指代码复用性程度，新功能开发是否可以复用原有代码，这就要求代码模块设计需要尽量不要和业务逻辑掺和在一起，减少代码编写和改动，事半功倍。
五、灵活性
顾名思义，就是代码写个非常精妙，即可满足扩展性，又满足复用性，尽可能少地影响已有代码，编写最少的代码，就可以实现新功能的扩展，以不变应万变，谓之神奇。
六、简洁性
有一条注明设计原则：KISS（“Keep It Simple，Stupid”）保持代码精简，这需要比较深厚的代码算法功底，高手过招，招招致命，绝无虚招。但是，简洁性可能又和可读性相违背，既要保证简洁，有需要保证代码可读性，需要平衡，绝非易事，思从深而行从简，厚积而薄发。
七、可测试性
代码可测试性可以从侧面反应代码质量的水平，方便编写单元测试用例，功能开发代码不是一改全改，而是将修改风险收敛在可控范围之内。
那么如何度量代码质量？ 欢迎大家一起来探讨。
