设计模式学习笔记（一）如何评判代码质量的好坏？

1.评判代码质量好坏的角度

在目前的面板项目中，经常听到同事用“代码写的很烂”、“这是什么鬼”、“我去，这个思路很棒啊”等字眼来评判项目中部分代码逻辑的好坏。

经过阅读一些文章和学习技术大神分享的内容，了解到真正评判代码好坏不应该笼统的用“好”、“烂”这种字眼。

从描述上应该更丰富、更专业、更细化。常用词汇有：

灵活性（flexibility）、可扩展性（extensibility）、可维护性（maintainability）、可

读性（readability）、可理解性（understandability）、易修改性（changeability）、

可复用（reusability）、可测试性（testability）、模块化（modularity）、高内聚低耦

合（high cohesion loose coupling）、高效（high effciency）、高性能（high

performance）、安全性（security）、兼容性（compatibility）、易用性

（usability）、整洁（clean）、清晰（clarity）、简单（simple）、直接

（straightforward）、少即是多（less code is more）、文档详尽（well

documented）、分层清晰（well-layered）、正确性（correctness、bug free）、健

壮性（robustness）、鲁棒性（robustness）、可用性（reliability）、可伸缩性

（scalability）、稳定性（stability）、优雅（elegant）、好（good）、坏（bad）

……

以上的词汇，对于代码评判的维度不同。比如，代码的可读性好、可扩展性好，就意味着代码的课维护性好。

2. 什么是好的代码

（1）可维护性（maintainability）

所谓“代码易维护”就是指，在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码。所谓“代码不易维护”就是指，修改或者添加代码需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能完成。

代入我目前做的项目，那就是要做到bug容易修复，修改、添加功能能够轻松完成。如果做不到以上几点，那代码就是不易维护的。

在九月份之前，我们的项目代码是很难维护的，无论是新增功能还是修复bug，都要绕很大一圈，仅仅是持久层就用  mapper、dao、dto三层，如果想要新增一个对数据库的增删改操作，需要修改的java类超过6个。

而业务层是通过工作流的委托模式实现逻辑调用，存在的问题就是你在查bug的时候要去找到对应的那个service很麻烦。

（2）可读性（readability）

软件设计大师 Martin Fowler 曾经说过：“Any fool can write code that a computer

can understand. Good programmers write code that humans can understand.”翻

译成中文就是：“任何傻瓜都会编写计算机能理解的代码。好的程序员能够编写人能够理解

的代码。”

代码的可读性很重要，代码的开发周期不一定很长，但是维护周期一定很长。让同事能够轻松读懂你写的代码，才能说明你的代码的可读性很好。

我们的项目代码可读性有待商榷，之前的架构师、开发人员都是从C#转过来的，导致代码的底层架构和逻辑层采用的设计并不是很优美。

（3）可扩展性（extensibility）

可扩展性，可以让我们在不修改或者少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。

目前项目对逻辑层的可扩展性做的比较好，逻辑层都是基于可扩展性去做的。

（4）灵活性（flexibiity）

灵活性，也可以用易复用来表示。主要体现在项目底层抽象出了很多可以复用的模块、类等代码，直接拿来用即可。

经过九月份的一次优化，目前项目的灵活性已经大大提升，新同事上手要减少百分之六十的学习成本。

（5） 简洁性（simplicity）

保持代码简单、逻辑清晰，意味着易读、易维护。开发不是炫技，搞太多花里胡哨的东西没什么必要。

所以，在能实现功能的基础上，对代码进行抽取、删减重复逻辑、配置管理基础数据等优化是很有必要的。

（6）可复用性（reusability）

可理解为，减少重复代码的编写，复用已有的代码。这点可以通过抽取公共的逻辑、抽象出接口、基于继承的多态类型转换等去做到。

目前项目对逻辑层相同的功能如：读取配置文件、上传下载文件、返回值的封装等逻辑进行封装，提供复用。

（7）可测试性（testabillity）

代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。

我们目前的项目还做不到这点，因为逻辑层的设计以及底层框架选择的问题，测试的成本依旧很高。

3. 总结

好的代码，应该是 易维护、易 读、易扩展、灵活、简洁、可复用、可测试的代码。 要写出满足这些评价标准的高质量代码，我们需要掌握一些更加细化、更加能落地的编程方法论，包括面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。而所有这些编程方法论的最终目的都是为了编写出高质量的代码。