今天来思考下如何评价代码质量?
业界公认比较认可的七大标准:
可维护性(maintainability)、可读性(readability)、可扩展性(extensibility)、灵活性(flexibility)、简洁性(simplicity)、可复用性(reusability)、可测试性(testability)。
一、可维护性
不会因为新增功能feature或bugfix引入bug,可以比较高效地完成新功能开发和bugfix,代码易维护,维护成本和风险低
二、可读性
代码不只是需要遵循编程语言的语法规则,还需要遵循团队的编码规范约定,需要让团队内部的同学可以相互轻松看懂对方写的代码,比如是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等,一般团队都需要依靠编码规范来约束,通过代码review来检测可读性,可读性高的代码,负责review的同学比较快速读懂代码,没有疑问直击代码问题,反之,代码疑问多看不懂,review效果大打折扣,所以,代码可读性可以大大增强代码review效果,降低风险。
三、可扩展性
对内封闭修改,对外开放扩展,需要符合“高内聚低耦合”代码设计原则,扩展新增功能不会破坏修改内部代码引入不必要的风险,而是通过扩展设计,保证新增功能代码相对独立,不影响原来代码逻辑;尽量做到少修改原代码,而实现新功能。
四、可复用性
可复用性就是指代码复用性程度,新功能开发是否可以复用原有代码,这就要求代码模块设计需要尽量不要和业务逻辑掺和在一起,减少代码编写和改动,事半功倍。
五、灵活性
顾名思义,就是代码写个非常精妙,即可满足扩展性,又满足复用性,尽可能少地影响已有代码,编写最少的代码,就可以实现新功能的扩展,以不变应万变,谓之神奇。
六、简洁性
有一条注明设计原则:KISS(“Keep It Simple,Stupid”)保持代码精简,这需要比较深厚的代码算法功底,高手过招,招招致命,绝无虚招。但是,简洁性可能又和可读性相违背,既要保证简洁,有需要保证代码可读性,需要平衡,绝非易事,思从深而行从简,厚积而薄发。
七、可测试性
代码可测试性可以从侧面反应代码质量的水平,方便编写单元测试用例,功能开发代码不是一改全改,而是将修改风险收敛在可控范围之内。
那么如何度量代码质量? 欢迎大家一起来探讨。
最后感谢每一个认真阅读我文章的人,下面这个网盘链接也是我费了几天时间整理的非常全面的,希望也能帮助到有需要的你!
这些资料,对于想转行做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。希望对大家有所帮助……
如果你不想一个人野蛮生长,找不到系统的资料,问题得不到帮助,坚持几天便放弃的感受的话,可以点击下方小卡片加入我们群,大家可以一起讨论交流,里面会有各种软件测试资料和技术交流。
敲字不易,如果此文章对你有帮助的话,点个赞收个藏来个关注,给作者一个鼓励。也方便你下次能够快速查找。
自学推荐B站视频:
零基础转行软件测试:自学完软件测试,拿到了字节的测试岗offer,堪称B站最好的视频!