爱尚实训哈尔滨校区,Java培训,大数据培训,Python培训,人工智能培训,计算机培训,IT培训,软件培训

在线咨询

当前位置: 首页> 行业资讯

行业资讯

    老司机告诉你高质量的Java代码是怎么练成的?

    2018-05-04更新

     

    一提起程序员,首先想到的一定是“码农”,对,我们是高产量的优质“码农”,我们拥有超跃常人的逻辑思维以及不走寻常路的分析、判别能力,当然,我们也有良好的编码规范,毕竟是靠代码来养家糊口,最怕半路接到一个项目或是项目增加新功能,发现之前写的注释非常不全,代码也非常的不整洁,有些地方写的‘’窝七八烂的,看着很不舒服。

    代码编码规范的都会起到什么作用?

    1、好的编码规范,可以减少一个软件的维护成本,并且几乎没有任何一个软件,在其整个生命周期中,均由最初的开发人员来维护;
    2、好的编码规范可以改善软件的可读性,可以让开发人员尽快而彻底地理解新的代码;
    3、好的编码规范可以最大限度的提高团队开发的合作效率;
    4、长期的规范性编码还可以让开发人员养成好的编码习惯,甚至锻炼出更加严谨的思维;

    高质量的Java代码是怎么练成的?爱尚实训和你一起寻找办法

    命名

    一个错误的命名会很误导人,不良的命名,对于阅读代码的人来说很纠结。一个良好的命名对自己也有很大的帮助。

     

    建议个人命名的变量长一些,一般用单词作为全称,这样代码读起来易懂,有些缩写根本不知道它代表的单词是什么,除了像id代表identifier,org代表organization这些大家常见的缩写命名。

     

    命名一个方法的时候,最好能让大家见名知意,看到名字就能猜出你的功能,而不需要去看方法的注释,甚至是读源码来了解你的功能。

     

    注释

    写一个方法时可以先把这个方法的功能、算法原理交代一下,以后自己或者是其他人维护你的代码时就可以很方便,对于易出错的部分加注释提醒即可。

     

    用class类型

    写方法的时候的参数,少用基本类型的组合,而用class类型。

    例如:

    写一个查找用户的方法queryUser(int age)

    最开始的业务需求是根据年龄来查找用户,后来业务规则发生了变化,你可能需要根据年龄和性别来查找用户,于是你又改成了这样queryUser(int age, intsex),假设用0代表男,1代表女(其实更好的实现是用枚举来表示男女);

    说不定你哪天的业务又有变化了,需要根据年龄、性别、家庭住址来查询,于是乎你又改成了这样queryUser(int age, int sex, String address)。

     

    如果你当时设计的方法是:queryUser(User user)传入的参数是一个User类呢,那该多好啊,你根本不需要改接口。

     

    在实际项目开发中改一个接口的成本还是挺大的,实际项目开发中为了达到层次清晰、解耦的目的,后台分了好多层,action、business、dao其中dao还有分了dao接口和实现,一个接口修改得牵动多少地方。

     

    而当初设计的接口传递的是User对象,那么你的代码可以简单的增加几行就能达到了目的,而不需要修改那么多的接口,一边修改一边纠结。

     

    少复制、粘贴代码

    同样的代码不要粘来粘去,当时写的时候确实是快了,可是以后需要修改的时候可就慢多了。

     

    更可怕的是你要修改多处,结果你只修改了一处,而你自己却以为万事大吉了,说不定哪天就蹦出个bug来。应该把这些公共的代码提取成一个class或者是一个方法。

     

    一个方法中不要写太多代码

    一个方法中写好多代码,写的时候确实是很方便,很快,更好的办法是把一个大的方法分解成几个小的方法,然后在主方法中调用其他子方法。

     

    如果把所有的逻辑都写在一个方法中,当需求发生变化的时候,再要修改那就慢多了。

     

    一小段逻辑的代码可以提取出一个private方法,然后在一个方法中调用好几个私有的小方法。

     

    这样读代码的人读起来也轻松,日后需求发生变化了,你的这些个小的逻辑代码块儿只要重新组合下,就又能满足新的功能,可以复用。

     

    增加设计文档

    增加一个新的功能模块时最好有个设计文档,先把方方面面都考虑周全了,设计好了再编码实现。

     

    如果一开始就有个设计文档,能把方方面面都考虑周全,实现起来就容易多了,实现的代码还能优雅些。

     

    为了达到最终的目的,可能中间要走些弯路,如果增加的功能多了,每次实现都走一些弯路,系统最终会变的臃肿不堪。

     

    如果推倒重来,以前的功夫就都白费了,不光是编码,还有测试部门的测试,有时时间也不允许重构,再说了重构还有风险,这其中的代价还是挺大的。

     

    所以新增功能一定要把需求搞清除,有个良好的设计文档,考虑周全了再编码实现。

     

    最后在向SVN提交代码时先做个功能测试,然后没问题了,再做个codereview。

     努力的人,爱尚实训老司机今天的忠告,你记住了吗?