读读《编写高质量代码:改善Java程序的151条建议》

这本书可以作为平时写代码的一个参考书，这本书以我个人读的经验看来，最好是通过平时代码驱动的方式来读，这样吸收的快，也读的快。

这本书主要讲什么，我自己用了个思维导图概述:

根据这种导图可知，主要讲的就是Java语法、JDK API、程序性能、开源工具和框架、编程风格和编程思想等五个点。

我这次主要读的是关于开源世界和思想开源这两章，这两章相当于导图中提到的开源工具和框架、编程风格和编程思想。所以今天讲的也是这两个方面。

一、开源工具和框架

导图如下所示:

作者的观点是:大胆采用开源项目。并对此提出五点建议。不过在我看来的话除了选择框架和工具需遵循六个原则外，其它四点从导图上看似乎没有多大用处。所以我也不打算详细说，但是这四点我将其理解为这些想法和建议。

想法和建议如下:

使用的相关工具类要统一，比如apache common对于String相关的有其专门处理类，尽可能不要引用其它具备此功能的，因为容易弄混,而且导包的时候，有些时候安ctrl+alt显示的太多,如果你不是对对应的API十分熟悉的情况下，很容易眼花缭乱,在此我要说明的是，工具类统一的好处避免导包眼花缭乱,同时也避免出现为了实现某个功能需要对应的工具类时，你引用这个，我引用那个。

目前开源项目，我认为比较不错的工具类集成项目，就是Hutool,它不仅文档相对完整，而且不少开源项目及其对应的公司也在用。

Hutool官方地址为:http://www.hutool.cn/

但是在选择开源框架和工具的时候，最好遵循六个原则:

(1)普适性;

选择工具或框架必须要考虑项目整体团队的技术水平，不能有太大的跨度和跳跃性，要确保大部分项目成员对工具比较熟悉，比如在关于持久层的选择下，选择MyBatis比Hibernate要好，原因是因为上手快，学习成本低，再比如MyBatis替换为MyBatis-Plus，跨度和跳跃性也不大，因为MyBatis-Plus本质上还是MyBatis，这样一来团队学习的成本很少，项目重构的成本很低，同时开发的效率也会提高。

(2)唯一性;

相同的工具只能选择一种或多种，不要让多种相同或相似职能的工具并存。例如，hutools可以代替apache common的相关功能，尽可能的选择其中一种，这样当项目成员在开发时，有的时候ctrl+shift+O导包时不用考虑导的对不对。

(3)大树纳凉;

找知名的开源项目，比如目前在Java中广泛应用的Spring+MyBatis+SpringMVC等。或者是现在开源项目之一的Jeesite4.0。因为有很多人在用，我们不必担心遇到很多Bug,虽然也有，但是由于用户的群体广泛，可以避免我们踩很多坑。

(4)精而专;

(5)高热度;

选择开源项目尽可能选择那些更新频繁的。频繁意味着有人负责维护，出问题了有人负责解决。更新频繁的总比一年甚至两年更新甚至已经不更新的项目要好吧。因此我们再采用开源项目的时候应抱有这样的观点，大胆采用，仔细筛选。当然了，还有就是最后如果发现选择了某个开源项目，突然作者因为某种原因不维护了，遇到这种情况时，不要抱怨对方，也不要诋毁人家，毕竟我们享受的是他人辛苦贡献的成果。

?

二、编程风格与编程思想

关于编程风格与编程思想，该作者提出了八点建议，我觉得挺棒的。所以我将其用思维导图归纳成如下:

1.提倡良好的代码风格

?

?换行排版总得要把，不然看起来乱七八糟也不好，这个目前大多数人都可以做到。但是风格统一的话，就有点难了，俗话说，一百个人眼里有一百个哈姆莱特。有点难并不代码没有办法解决，比如现在流行的Java规范手册《阿里巴巴Java开发手册》，就可以借鉴参考。便捷(通用性工具，比如sonar这个代码质量分析或者是sonar lite这个Eclipse代码分析插件也是有利于塑造良好的代码风格。

?

?2.不要完全依赖单元测试来发现问题

?单元测试确实不能覆盖所有的场景，因为我们开发人员在有限的时间内，所能做的测试及其对应的数据场景，也就三种:

(1)正常;

(2)边界;

(3)异常;

其它的我们也没有这个时间去考虑那么多，即便是有专门的测试人员，测试的场景也还是有限。更何况像没有测试的小公司呢。

?

3.让注释正确、清晰、简洁

?

?我觉得上面的这个思维导图已经足够详细了，所以关于注释我不再赘述。

4.接口职责单一

?

5.增强类的可替换性

?

6.依赖抽象而不是实现

?

?

4、5、6涉及对应的设计模式，但是这些设计模式，我们实际开发中，一直在遵守，同时也一直在破坏。很难有人完全遵从设计模式的那一套。

7.抛弃七条不良编码习惯

?

(1)自由格式的代码，随心所欲想怎么写就怎么写，最后你就等着哭吧。

(2)不使用抽象的代码，比如在Java中，一般项目会这么写:

entity、dao、service、serviceImpl、controller

entity对应数据实体

dao相当于数据访问层

service及其实现类相当于业务逻辑层

controller自然就是接口或者是视图控制层

有的人图省事，按照自己的想法来，将service和serviceImpl合并为一个，我们之前说过单一职责原则。如果是service和serviceImpl合并为一个，就不符合作者所说的，单一职责和依赖倒置或面向接口。因为无论是单一职责也好，依赖倒置或者面向接口也罢，遵从的核心就是，“高内聚，低耦合”。他这么做，自然就是“低内聚，高耦合”。

(3)像彰显个性，比如自认为将代码写的让别人看不懂，就认为自己很牛逼。

(4)像死代码，比如某某功能代码已经暂时弃用，但是以后可能用,就用个注释将其注释掉，等待以后再用，实际情况是以后都不会再用，放在这影响可读性。

(5)像冗余代码,比如有工具类可以做字符串和非空判断，你却还要写个if-else if-else等等。

(6)像拒绝变化的代码，就好比人拒绝成长那样，总有一天呢会吃亏的。

(7)像自以为是的代码，自己很快的写完初步测试了几个场景，或者是不测试就盲目的自信认为自己写的完全没有问题，一点bug都不会有，到最后，一般情况都会有问题的。这一点我深有感触。

?

8.以技术人自律而不是工人

?

(1)关于熟悉工具，比如Eclipse，你如果十分熟悉的话，无论是当项目越来越庞大时，或者是调试时，你总会比那些熟悉程度相对于比你低的多的人在错误排查或者说找某个包下的类，效率上要快的多。

(2)关于IDE，每个编程语言都有其独特的IDE，如果没有IDE，想象着你用记事本或者notepad写代码，然后命令行编译，那是一件多么痛苦的事情啊，IDE的出现与广泛应用就是为了提高程序员的开发效率，减少不必要的体力劳动。

(3)坚持编码,这里要提一点，只要还是在技术这个圈子里面混，代码还是要写的，不然哪来的灵感呢。

(4)编码前思考，这里之前我也说过，编码前不思考直接开干，最后的结果是效率低，无用功。

(5)坚持重构，重构不一定是大规模，它可以是一步一步，比如你之前的controller一般都是作为控制层，通常是接收请求，处理数据，返回数据等，像与安卓对接，一般都是JSON数据，你可以将之前引用的JSONObject抽取出来为一个类复用，省得每次controller都要导包。

(6)多写文档，之前也说过，写文档不仅仅是为了理清业务逻辑和解决问题，还是为了提高自己的思维能力。

(7)保持程序版本的简单性，一个项目不要太多版本，否则往往会将简单的事情变为复杂。

(8)做单元测试，关于单元测试的重要性，我在这篇文章说过，文章链接:https://www.cnblogs.com/youcong/p/9291184.html 所以就不再多说。

(9)做好备份，不怕一万就怕万一，总得留个后手。

(10)不要重复造轮子，有现成的工具，就不要自己千辛万苦的去写了，直接用现成的，当然了，你如果觉得你可以改造这个轮子，让这个轮子变的更好，那么，我个人觉得不妨试一试，也许能推陈出新。

(11)不要拷贝，你可以理解为了有很多处代码段需要引用某段函数，既然是需要引用相同的某段函数，为何不将其写成一个代码块方便调用呢。

(12）代码充满灵性的体现是，至少你看到这段代码知道是什么意思，见其便知意。而不是看天书似的。

(13)测试自动化，不管是性能测试、单元测试，还是功能测试，想尽办法让它自动化，不要在测试之前手动配置触发条件。

(14)做压力测试，这个就不必多说了，现在压力测试工具有很多，loadrunner或是jmeter,整体来说，都还不错。

(15)"剽窃“不可耻，学习人家怎么写代码的，好的借鉴，不好的引以为戒，也是一种提高自我编码质量的有效方式之一。

(16)坚持向敏捷学习,提高软件开发流程的效率。

(17)重里更重面，把握好用户的第一面。

(18)分享，分享自己的技术，分享自己解决问题的方式，分享自己是怎么写代码的。

(19)刨根问底，凡是对于问题或者事物，都要心中有为什么，特别是开发任务繁重的时候，业务不问清楚，很容易导致做无用功。

(20)横向扩展，主要是又一点到多面，相当于在某些业务时，你接触过数据库、接触过安卓、接触过IOS或者是运维等，借此可以扩大自己的知识面，这也是发展为全栈工程师的途径之一。

?

小结:

上述说的，有些来自这本书，也有些来自我个人的想法。希望能给大家带来帮助。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!