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

这本书能够做为平时写代码的一个参考书，这本书以我我的读的经验看来，最好是经过平时代码驱动的方式来读，这样吸取的快，也读的快。

这本书主要讲什么，我本身用了个思惟导图概述:

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

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

1、开源工具和框架

导图以下所示:

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

想法和建议以下:

使用的相关工具类要统一，好比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)高热度;

选择开源项目尽量选择那些更新频繁的。频繁意味着有人负责维护，出问题了有人负责解决。更新频繁的总比一年甚至两年更新甚至已经不更新的项目要好吧。所以咱们再采用开源项目的时候应抱有这样的观点，大胆采用，仔细筛选。固然了，还有就是最后若是发现选择了某个开源项目，忽然做者由于某种缘由不维护了，遇到这种状况时，不要抱怨对方，也不要诋毁人家，毕竟咱们享受的是他人辛苦贡献的成果。

 

2、编程风格与编程思想

关于编程风格与编程思想，该做者提出了八点建议，我以为挺棒的。因此我将其用思惟导图概括成以下:

1.提倡良好的代码风格

 

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

 

 2.不要彻底依赖单元测试来发现问题

 单元测试确实不能覆盖全部的场景，由于咱们开发人员在有限的时间内，所能作的测试及其对应的数据场景，也就三种:

(1)正常;

(2)边界;

(3)异常;

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

 

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

 

 我以为上面的这个思惟导图已经足够详细了，因此关于注释我再也不赘述。

4.接口职责单一

 

5.加强类的可替换性

 

6.依赖抽象而不是实现

 

 

四、五、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或者是运维等，借此能够扩大本身的知识面，这也是发展为全栈工程师的途径之一。

 

小结:

上述说的，有些来自这本书，也有些来自我我的的想法。但愿能给你们带来帮助。