Java代码质量

 

1、三思后行

作为程序员一定要克制住自己尽快开始编码的欲望

我们开车首先要清楚自己的目的地，目的地不清楚

开的再快也是白搭，所以编码之前要一定要弄清楚

需求，需求不清楚或者需求理解错了就和踩车选错

了目的地一样。

如何确认自己理解的需求是对的我这里分享一个方法

找项目经理讲一遍自己的理解，看自己的理解和项目经理

的理解是否一致，如果一致说明你理解了，如果不一致

那么要项目经理在解释一遍，如果项目经理也解释不

清楚，那么你一定不能开始编码，等他搞清楚了在

写。

理解了需求，我们还要做设计，先在规划一下整体

的代码逻辑，数据流程是怎么样的，比较复杂的话可以

画出来，然后根据流程图设计自己的代码结构，实现做好

规划比直接上手写要少走很多弯路。

最后一点，技术难点在行动前要先用demo实现，避免

写到一半卡壳又要来研究这个难点，避免整体的思路被

打断。

 

遵循编码原则

遵守编码规范

没有规矩不成方圆，一个团队合作开发，不是一个人

小打小闹，为了项目的整体质量和可维护性，降低

别人理解你代码的成本，提高工作效率我们必须

遵守公司统一的代码规范。

不出现多余的代码

我们的基础代码，往往是代码生成器生成的，在一些

业务场景下不是所有的接口都能使用，我们需要的

只是其中的一部分，所以没用到的就必须在开发完

后立刻生成接口，避免出现多余的接口，到了程序

的后期，你就不敢在删除接口了，因为你也不知道有没有

用到。

遇到配置不要写死

配置往往随着环境的不同就会不一样，比如数据库配置

不同的环境数据库账号密码不一样，你能写死数据库

配置吗？显然不能，其他配置也是的，比如一个微信

开发的appid 很可能我们是用自己的appid做测试，然后

上线了就要切换到客户的appid，所以配置一定通过配置

文件设置，而不是直接写死在代码中，也不要写死到常量

中。

 

复制粘贴的代码一定要了解原理

遇到 我们解决不了的问题，很多时候我们会去网上找一些代码过来，

有的人只要能解决问题，一顿粘贴复制，也不管

里面到底有些什么东西，这样是很危险的，你要知道

网上的代码是人家写demo给你看方便你理解的

而你是在实际的业务场景中，要考虑的东西

更加严谨，所以一定要理解你复制的代码，然后在放到自己的

项目中来，这样才是严谨的。

 

相似的代码一定要封装

 

如果有写逻辑比较相似但是又有一点区别

这个时候我们一定要重构代码抽取相同部分

否则的话就会导致后期修改非常麻烦，有一个

地方改了其他地方都要改，而且还不一定的全

改了这里忘了那里。如果我们一开始就封装了

相同的代码，其他地方都调用这个方法那么

我们就只要改一个地方就可以了。

 

单一原则

单一原则，我们的一个方法就只完成一个业务

逻辑，不要通过传不同的参数做不同的事情

及时两个事情看起来很相似，因为及时现在

相似后期可能会出现微调，一出现微调就很有可能

改好了这个情况，改坏了另外一种情况。所以

一个接口只做一个事情，及时你改也只会影响

一种情况。

 

不要重复造轮子

 

很多人不喜欢看别人的代码，及时别人已经实现了

这个方法都不用，宁愿自己写，这个是非常不理智的

既浪费了自己时间，又否定了团队的工作成果，

而且导致后面的开发者不知道用哪一个轮子好。

所以已经有了的方法和功能，不要重复写。

 

优化和重构是最好的自我提升机会

有人抱怨天天写增删改查没有意思，得不到提高

但是又从来不优化自己的代码，只求能跑能用

完全不讲究设计，查询效率搞不搞，处理速度快不快

代码逻辑结构是否可以优化这些问题都不考虑。

我想问问你简单的代码都优化不了，你还想写什么高深

的呢？所以项目中一有时间就要把自己的代码进行优化

可以反思自己当初为什么要这样写，为什么没有考虑到

这样的情况，下次就可以避免，代码的健壮性就会越来越

高，能力自然也就上去了。

 

学会使用//TODO 标记

无论是eclipse还是idel都支持TODO标签，我们在开发的过程

中有些地方可能要做个标记暂时做不了，先简单处理一下，等

什么情况了在进行补充，以前我们都是自己记忆者，但是会经常

忘记，我们可以用这个注释在编辑器中记录一下，发版本之前

检查一下标记。

 

注重程序的可读性

代码既是写给计算机看的，更是写给人看的，我们

70%的时间都是在看代码改代码，真正写代码的时间

一般只有30%，所以一个好的注释，方便理解的代码

结构可以帮我节约大量的时间。

尽量不要写太复杂的Sql

有的人很喜欢用sql处理业务逻辑，这样做在我们这里

不合适，因为不是每个人的sql能力都很好，我们更

擅长的是代码，所以宁愿效率低一点也不要把逻辑通过

复杂的sql来实现，否则就会降低代码的可维护性

 

不要过度设计

有的人学了一点设计模式就喜欢到处用，不管合不合适

反正就是要设计很多类很多接口一个简单的功能要

搞上7，8个类，好像设计的别人看不懂就是自己失败

这就是纯粹的炫技。没点用，首先不说你设计的怎么样

一般也不怎么样，我就问一句要是你看别人这样设计

后续的bug让你改，你愿意改吗？

所以不要高射炮打蚊子，简单实用比过度设计好。

 

禁止硬编码，魔法值这个就不解释了

 

避免长逻辑判断

什么叫避免长逻辑判断呢，说的就是一个

if条件中带很长很复杂的与或非，这样写理解起来是很复杂的

我们应该用一个有意义的Boolean变量来代替。比如说做一个

条件判断是否能通过审核功能，

判断的条件是所总经理和项目经理统一

我们可能会写if总经理同意and项目经理同意，这个同意可能还要去

查询数据库中，的一个字段并且这个字段的值等于一个同意状态

如果1表示同意这样这个if判断就变成了if 1==xxdao.find(xx).getxx()

& 1==xxdao.find(xx).getxx() 对吧，这代码你过了几天在来看你都

不知道是什么，然后重新去看一下逻辑才明白是做了个什么判断

我们可以这样写

boolean mangerAgree=1==xxdao.find(xx).getxx() ；

boolean bossAgree=1==xxdao.find(xx).getxx() ；

if(mangerAgree & bossAgree){

}

 

 

提交代码时写清楚备注，不要频繁提交

 

提交代码的时候很多人喜欢用gx，从项目第一天

到项目最后都是这个注释，这样很不好，首先态度上就有问题

提交代码是一件很慎重的事情，代码仓库如果出现问题，要通过注释

进行恢复的，别人也可以从下载代码的时候通过看注释

知道你更新了什么内容。所以一定要写清楚本次更新代码

到底是写了些什么东西。对自己负责一点，对团队负者一定养成

好的习惯。

 

 

编写接口注意事项

后台人员在通过接口时要注意的问题

1、使用同一的传参格式，禁止自定义格式

我们前后台规范传参是必须的，方便我们做统一的错误处理，分页等

公共事项都基于此，所以禁止开发和前端私定

传参格式。

2、接口保证责任单一原则

这个之前已经说了

3、调试接口不要写死参数

我们在做接口的时候考虑到登录用户的获取

有时会写死用户，这样是很不好的，经常会忘记

把写死的用户改回去。我们通过拦截器注入用户

而不改自己的方法。调试完成后注释拦截器，需要的

时候就打开。

 

4.业务逻辑能在后台处理的一定不要去前台处理

过多在前端暴露逻辑会导致系统的不安全

因为前端是客户端可以通过js看到的

 

5、接口传参越少越好，出参少，入参少

传参少也是减少暴露业务逻辑

 

6、考虑数据分页

我们写一个数据查询接口，一定要清楚是要分页的还是不要分页的

参数不同

 

7、写好的接口录入geek平台并通知对应的调试同事

 

8.、敏感信息不能直接暴露在url上

比如我们的用户编号，等能做加密的我们要做加密，

先把用户编号以加盐的方式进行加密，然后在拼接url

 

9、注意跨站脚本攻击和sql注入

如果采用富文本接收参数要主要防止跨站脚本攻击

前端参数不要用来直接拼接sql

 

10、避免使用get请求传中文，避免乱码

 

11、考虑接口是否支持跨域的情况

理解项目部署的情况，看接口是否要允许跨域请求如果前后端不在同一个域名下就需要允许跨域

 

 

 

这一节我们来聊聊场景业务场景的坑

本节我总结了我们在项目开发中一些常见的业务问题

这些问题都是我们吃过亏的。

第一，要记住，任何一个简单的功能，一旦数据量大就会变得

不简单，比如说 一个批量插入功能。我们数据量下的时候

我们可以用for循环插入没有任何问题，数据量稍微大一点

for循环就会很慢，因为要频繁的进行数据库操作，我们可以改用

批量插入一次插入多条，但是又有一个问题，容易被忽视，批量插入

最多可以插入多少呢？这个问题大家有没有想过，批量插入有条数限制吗

有数据包大小的限制吗？答案是都有，所以在做数据插入的时候就要想清楚

我们这个功能到底多少数据，一次插入多少条，要分多少次插入，myql一次

接收的数据包设置的最大值是多少。这些问题都要清楚才能吧这个功能设计好。

 

 

以上只是讲一个小例子

下面我们具体一点

数据量过大查询一定要分页不要出现全表查询

全表查询效率低容易导致内存泄露

数据量超过10万的表，用自增主键好过用uuid

我们默认的表主键用uuid这是出于安全性考虑，

但是如果数据量过大而且这个表要经常被查询，用自增

主键会比uuid好，查询速度快也不占存储空间

 

大数据量查询建立索引，会大大提高查询的效率

注意建索引要用索引，不要建了索引却不用也白搭

 

for循环处理数据一定要考虑数据量与处理时间的问题

比如给所有公众号的用户推送一个即时消息，要求在10s内

完成，如果用户有10万那么显然一个for循环是肯定完不成的

我们就要另外出方案，看是用多线程来出来，还是多服务器集群来

处理。

 

删除数据时要看是否需要判断数据权限

我们的删除接口都可以通过前端看得到，那么我是否能通过改变接口的

访问参数直接删除数据库其他用户 的数据呢？这显然是不合理的

在可能出现恶意操作的用户场景下，我们做删除时要判断当前登录用户

是否具有权限删除这个数据。简单实用的方法是，删除条件带用户id和数据id

一起删除。

 

 

删除数据时要看是否需要判断数据权限

在设计系统的时候，要考虑数据能不能被物理删除，

物理删除了会不会影响其他表的查询

 

调用外部程序，出参入参都要打印

我们的系统有可能会和第三方系统进行数据交换

那么在数据交换的接口我们请求发出去的参数和我们请求

接受回来的参数都要打印出来。一方面方便调试，定位问题

另一方面如果是和第三方合作，有日志可以定位责任

 

数据去重考虑是否区分大小写

如果我们做一个数据去重功能，要看

业务要不要求做大小写敏感，如果要

这表的编码要改成支持大小写区分的编码

 

并发修改数据

 

如果有并发修改数据的业务场景一定要做数据锁的控制

避免出现数据库脏读的情况，我们可以给

数据加一个版本字段，每次修改数据库之前

都先判断字段的版本。这就是乐观锁机制

我们这里不讲实际编码只讲原则，所以感兴趣的同学

自己去找资料学习一下。

 

和大家分享一下编程的八荣八耻

 

以动手实践为荣，以只看不练为耻。

以打印日志为荣，以出错不报为耻。

以局部变量为荣，以全局变量为耻。

以单元测试为荣，以手工测试为耻。

以代码重用为荣，以复制粘贴为耻。

以多态应用为荣，以分支判断为耻。

以定义常量为荣，以魔法数字为耻。

以总结思考为荣，以不求甚解为耻。

以可配置为荣 ，以硬编码为耻

以可互备为荣 ，以单点为耻

以可无状态为荣 ，以有状态为耻

以可随便重启为荣 ，以不能迁移为耻

以整体交付为荣，以部分交付为耻

以标准化为荣，以特殊化为耻

以自动化运维为荣，以人肉化运维为耻

以无人值守为荣，以人工值班为耻

 

 

编程不是一个人的事

在团队中编程一定要注意沟通，多沟通

遇到问题就问，不要怕丢脸，只有不怕

丢脸自己的能力才会更快的提高，

另外一方面也只有谦虚的人别人才愿意教你

与你合作，过于自负顽固只会导致众叛亲离

保持一颗谦虚，开发的心才能走的更远

 

我们讲一下那写些问题是一定要拿出来沟通的

通用性代码一定要先讨论再编写

你写的代码有可能呢别人也会用到，那么就先

好相关的人说这个功能我来做，到时候你调用

我的方法，我是打算这样做的。。

对吧让后对方就给你提一点已经，你还可以这样

这样。沟通完只有你就做了一个通用的功能了

你的团队也知道以后要用这个方法就可以直接用

你的。

 

注意和上下游的伙伴达成一致

我们写一个功能往往可能用到上一个环节产生的数据

那么我们上游开发是否知道我们需要的数据是什么样

子的这个问题要确认，否则的话你搞了半天，别人数据

根本不是这样来的，白忙了。

 

课程终于要到结尾了，这个系列的课程我们讲了就很多东西

关于编程的方方面面我们都聊到了，我知道你可能记不住这么多

也不可能记住这么多，前面的你都可以忘记，但是有7个字绝对

不能忘，如果说这个课程要给你留下点什么我希望就是这7个字

 

“尊重自己的职业”

尊重自己的职业，等于尊重自己，只有自己看得起自己，才能

让别人看得起，尊重程序员这个职业，兢兢业业的写好每一行代码

用自己的指尖码出价值，实现梦想！

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1