代码规范（二）——java篇

51. 

try {

    newMAC = PosCryptor.getMAC(PosServerConfig.getKeyHost(),PosServerConfig.getKeyPost(),

            entNo, posNo, operNo,requestMsgTypeId, newBody);

    LOGGER.debug("newMAC:"+LoUtils.byte2HexStr(newMAC));

}catch (UnknownHostException e){

    throw new PosRunTimeException("keyserver 连接异常!",e);

}catch (IOException e){

    throw new PosRunTimeException("keyserver io异常!",e);

}catch (Exception e){

    throw new PosRunTimeException("keyserver格式解析异常!",e);

}

建议：参考第19节。

建议：org.apache.commons.codec.binary.Hex

52. 

@Service

public class XxxServiceImpl implements XxxService {

private static Object invokeGet(Object o, String fieldName) throws Exception {

String[] fieldNames = fieldName.split("[.]");

for (String fn : fieldNames) {

o = o.getClass().getMethod(fn).invoke(o, new Object[0]);

}

return o;

}

建议：通用的static函数，尽量放在Util里，尽量减少XxService的长度。

建议：分隔string，不应该用“.”，因为它在regex里有特殊意义。应该是逗号“,”。

org.springframework.beans.propertyeditors.StringArrayPropertyEditor.

DEFAULT_SEPARATOR就是“,”

建议：这个函数的本身意义，就有很大毛病：

（A）变量o被赋值多次，却被当成结果只返回一次。

（B）变量o既作为输入参数，又作为输出参数。

（C）变量o前后的意义都不同。

输入时的意义是：“某个普通对象”，将要被调用。

输出时的意义是：“某个普通对象”调用某method的结果。

 53. 有人说：持续集成，只是编译打包就行了，不需要跑自动化测试。

建议：参考第38节。

 55.  

建议：在循环里搞删除，影响性能，应该使用sql批量删除，输入的参数为：”1,2,3”

建议：return行，返回：1或0，这是C风格，不是Java风格。

Java风格是：使用Exception：public void myDeleteFunction(String str) throws Exception

建议：扔掉try-catch。参考第19节。

建议：经过了以上3个和第19节的建议，这个函数只需要1行就行了：

msgPrivateMapper.deleteXxx (ids);

 56.  

建议：所有的能跑的东东，都应该写在单元测试（junit）里，而不是main里。

 

建议：有大量的注释（//或/* … */），就是错误。

要么删除；要么解开，改变成为一个个的单独的junit test method。

那么，在持续构建里，就能总是能把那些功能跑到，总是能自我检查尽早检查。

 

建议：main()最后1行，不需要显式调用System.exit(0)。

 58.  

建议：把重用多次的’N’、’Y’做成常量。

59.  

建议：del、add、update，都是相同性质的事务，Spring默认的行为就够用了。

所以，rollback-for和no-rollback-for这2项，可以删除。

 60. 有人说：代码写到一坨了，没法搞单独的TestCase。

那就说明：这个程序比较差，是紧耦合的。好的是：松散耦合。所以，要重构了。

解耦的最好方式是：接口+组合。例如：

public class MyBusiness {

private  MyBusniess00  bn00;

private  MyBusniess01  bn01;

private  MyBusniess02  bn02;

……

//  setter & getter

}

这也是Spring最常用的套路。

附带提个常识：

如果某程序有好的单元测试和覆盖率，那就肯定说明：它的结构是好的，松散耦合的。

 61. 如何对Java程序做格式化？

建议：这是个来自于Spring源码里的文件，用Eclipse导入：

Preferences—>Java—>Code Style—>Formatter-->Import 

62. 某项目有600个class，修改了2个，影响了些啥？

如果有完善的单元测试，跑跑，很快就知道影响了些啥，就能快速修改，极大的增强信心。

所以，如果你按照XP/TDD的核心思想（单元测试）做程序，将会越做越顺！

63. 源码里有192.168.1.xxx，如何评价？

如果这个IP是自己的，下班就关机了……

（A）那么，夜间Jenkins服务器跑CI（持续构建）/每日构建（Daily Build），肯定失败。

（B）别人从SVN拉下来项目，跑，也肯定失败。

所以，这个IP绝不应该是自己的。

 65. 如何查找性能瓶颈？

DeveloperA负责项目P，最核心的功能B，性能总数字是100个/12秒。

里面有这些东东：通讯协议解析C，业务D，业务E，业务F

请他把这4项的耗时的具体数字和TestCase拿出来，他没有。

请他把业务全部扔掉，只把C的耗时的具体数字和TestCase拿出来，他没有。

 

建议：较好的查找性能瓶颈的路线：

（A）设定个固定次数，例如：600，还可以设置大些，后面会多次用到这个。

设定基线，即：assert(…); 每次跑完，必须要能看见绿条（Green Bar）作为结果。

（B）单独把核心的功能B跑600次。

（C）单独把C/D/E/F分别跑600次。

（D）看看C/D/E/F里，谁耗时最多，就最先优化谁。每修改一次，就重新跑一趟。

搞好了这项，往往达到70%的效果。

（E）再优化耗时第2多的。搞好了这项，又增加了20%的效果。

 

 

优化某项，里面又有多个组件R/S/T，如何分辨性能瓶颈？

建议：重复之前的路线，针对R/S/T都建立TestCase……各个击破。

67. 跟性能最密切的程序段，可能是些啥？

WebApp里的Filter、Inteceptor，普通App的协议的解析和反解析……

是每次必须经过的路线。

针对这些，必须有专门的TestCase，反复跑，反复优化。

69.  

建议：HashMap是有关算法的，肯定要内建hash表和计算hash。

如果key是纯粹的数字，而且很小，那就直接做成数组/List，数组的index就是key。

数组是直接存取，不需要计算hash，更快。

 

建议：既然用了Spring，就有了BeanFactory，那就用它建立Singleton，不要自己手写getInstance()了。例如：

<bean id="dataSources" class="org.springframework.beans.factory.config.ListFactoryBean">

    <property name="targetListClass">

        <value>java.util.ArrayList</value>

    </property>

    <property name="sourceList">

        <list>

            <ref bean="dataSource_0" />

            <ref bean="dataSource_1" />

 

有人说：“做到spring里面去，效果是一样，还是这样好使用”

建议：列几项软件原则：

（A）“不做code，少做code。”  “代码行数越少越好。”

（B）朝着稳定的方向依赖。

完成同一个功能，是用Spring框架搞得稳定呢？还是用自己写的code搞得稳定呢？

 70. 

Map<Integer,String> messageBody = new LinkedHashMap<Integer,String>();

messageBody.put(3,termTradeCode);

messageBody.put(42,entNoAsc);

messageBody.put(62, "0012"+versionsAsc);

建议：

LinkedHashMap有复杂的算法，尽量回避。

给Map显式的分配空间，尽量大些，这里分配256就足够了。

List<Pair<K, V>>，只是简单的顺序的存取，很实用。参考第29节和上节。

或者，用数组，更快。

 71. 有人说：我做的程序，无法测试性能。还有人说：我做的这个框架，必须带些业务才能测试性能，无法单独测试纯粹的性能。

建议：

（A） 所有程序都能测试出来性能。如果无法测试出来，或者测试出的数字差，说明：

这个程序或者测试程序有毛病，需要改善。

（B） 业务是业务，框架是框架，它们之间应该是弱耦合的，针对接口编程的，能替换其它实现类的。它们都是能单独测试的，还能用上针对接口的Mock的东东。

72. 

这个极品工程里，只有几个class，每个class还占了一个package。

建议：

（A） 不要瞎成立maven工程。

对于不确定是否需要独立的工程，先都放在一个里，便于修改。

这个cache-api工程，可以合并到common工程里。如果code太烂，干脆就废除掉。

（B） 静态方法调用要回避，应该做成实例形式，便于搞Object的模拟和测试。

 75.  

建议：

（A）权威的证明资料：《J2EE Development without EJB》

我们自建的MyException，都应该extends RuntimeException，而非checked Exception。

（B）重复的、临时的、不伦不类的、命名意义模糊的、小范围使用的class，赶快删除吧。

76.  

建议：PowerDesigner等工具生成的code，也要用眼睛看3遍。明显臃肿的，要删除。

77.  

建议：

（A）用void代替boolean。如果出毛病了失败了，就抛出RuntimeException。

（B）从try开始的几行，只保留Ecms所在的一行就够了。

（C）带有@Test 的method，都应该声明throws Exception，为了里面尽量少写try-catch。

78. 

建议：

（A） else-if，要有else { throw new RuntimeException(…) }

（B） Java7，switch( string )

79.  

建议：用标准的JavaDoc方式，这还能避免某些源码覆盖率工具的解析错误。

80.  

后面request在cache里的值，精确的覆盖了前面request在cache里的值。

 81.  

建议1：request应该是个傻傻的的简单的数据容器，里面怎么有个ServerMainHandler？

ServerMainHandler调用request，是正常的，还能反过来调用，就是错误。

建议2：handlerExecute(...)明显是搞业务的，里面怎么会放个Spring单态类？

应该通过set/get的方式注入Spring单态类才对，不用每次在参数里传入。

 82.  

aWeb项目的有多个spring的xml配置，可能跟b.jar、c.jar里的发生重名冲突。

如今，公司测试环境OS上多个app，配置都统一在一个目录里，配置文件更加容易冲突。

建议：配置文件应该统一命名为projectName_config.xml，projectName_config.properties

不应该有applicationContext*.xml这种文件名字了。

83.  

建议：把package级的javadoc写在.java里，jdk和开源软件都走这种标准路线了。

 84.  

建议：继承，只是OO的特性，跟常量（Constants）没有关系。

应该杜绝常量类的继承。还应该杜绝常量接口。

85.  

建议：

org.apache.commons.lang3.StringUtils

public static boolean isNotBlank(CharSequence cs)

public static boolean isNotEmpty(CharSequence cs)

 86. 

建议：common有太多的小模块了，全部加起来也只430KB。

这会浪费dev很多的编译和查错时间。

应该合并为1个模块。

 87.  

建议：

（A）最明显的是57行—65行，连续出现3次相同的code。应该重新整理if-else。

（B）36行，看看spring源码，initFilterBean()里面是空的。说明：此类不需要spring。

原则：性能要紧之处（例如：Filter），继承层级越少越好，设置为final也好。

所以，这里可以扔掉spring的父类，实现最基本的Filter接口就行了。

（C）42行，用str.contains(…)

（D）多个if-else，就必须要有足够的自动化TC覆盖到每个分支，否则，会出多个bug。

（E）Filter的参数，也应该来自于spring工厂。参考第96节。

88.  

疯狂的if-else，这来自于Apache Continuum，是个反OO的典型范例。

前人蹉跌，后人知警。

89.  

建议 1：第1行，返回的数据容器，应该是个普通的List/Map，怎么是JSONArray？

List/Map是性能最高的，JSONArray性能肯定偏低。

JSONArray是个偏重的容器，包含了List，还有些跟数据容器没有关系的东东。

对于网络传输和解析，这些都是缺陷。

 

建议 2：map的value，被前面的for循环多次赋值，实际却只用了最后的一次赋值！！！

而且，Map的Key顺序是不确定的，最后得到的value，也是不确定的！！！

建议 3：高亮的行，JSONArray.parseArray(…);

参数里应该是普通String才对，实际却是jsonArray.toString()！！！

倒腾几番，参数jsonArray完全没有排上用途，结果还是个String。

那干脆做成Map<String, Integer>就更简单了。

建议 4：网络传输，格式可能是json/xml/自定义string/binary/……。

在发送端和接收端，解析出来的都应该是基本的Pojo/Model。

如果用Pojo/Model，修改了传输信息格式，jsonàbinary，不会修改传输类（DTO）。

它转换到各种格式，是最容易的，也是最开放的。

如果用JSONArray，jsonàbinary，将会修改大量的传输类（DTO）。

建议 5：原则：朝着稳定的方向依赖。

是List/Map稳定呢？还是开源的（可能近几年没人管理或移交给他人的）fastjson稳定呢？

建议 6：避免用Map，避免hash计算，多用List。

就算用Map是对的，Map的key也应该是Integer、String、Class等，绝不是JSONArray。

建议 7：从原意看来，Map里只有一个元素（Entry），key是list，value是int。

既然信息只有两样，不用Map，恰好可以用apache-commons Pair<List, Integer>。

建议 8：从原意看来，如果要携带更多信息，可以自定义class来搞。 

 

建议 9：综上所述，Server端Client端都做得很奇葩。

以后dev再遇到这种code，应该立即提出来。

越早暴露就越好，bug越少，性能越高，今后修改越少，越节省公司的成本。

 

建议 10：

在内网里，ServerA从ServerB取得比较稳定的数据，可以把吞吐量搞大些。例如：

多数情况，总共都只有几百条，那就每次取2000条数据缓存于ServerA的session里。

避免每次取10条取多次而增加request次数。

 90.  

建议 1：成员变量Random被多线程访问，会出错。

建议 2：验证码，应该避免长得像的字符：

（A）数字1、L的小写和i的大写。

（B）数字0和字母o大写。

（C）数字2和字母z。

建议 3：成员变量都应该显式声明为final，扔掉private。

 91.  

建议：这种情况，“可读性”比“性能和硬编码”更重要。

String.format(“12%s45%s”, 3, 6);

92.  

建议：常用的英文词汇，搞简写就行了。

transactionàtx

account-->acc

currency-->ccy

level-->lv

message-->msg

amount-->amt

commandàcmd

buffer-->buf

receive-->rcv

service-->svc

93. 跑·不跑 

今天是2014/12/31，这几个的最后更新日期，竟然是146天之前！！！

建议：测试类，肯定是经常增加内容的。例如：

（A）测试组报了bug，dev就应该增加几个TC（TestCase）了。

（B）有了新需求，应该增加几个TC了。

（C）程序的某段，也许有更好的更快的做法，要做个试验吗？增加TC了。

（D）dev估计到某块可能出毛病，那么今后肯定会出毛病。增加TC了。

（E）需要几个性能测试？增加TC了。

 

程序，就是用来跑的，必须经常的跑，才能检查出健康状况。

持续构建，把工程里几万行code跑几遍几十遍，就是经常的“跑”。

本图，就是典型的“不跑”。

94. 外部配置·main程序（jar） 

在spring xml里配置相对的.properties文件路径：

<context:property-placeholder location="file:../../hsserv/config/pos.properties" />

 

这样做的好处是：

（A）只要把同一套配置编辑好了，今后发布N次jar，都不需要修改配置了，

减少了修改次数，这条会让测试人员和部署人员轻松很多。

（B）配置文件放在专门的目录里，设置权限，

只让有权限的人员操作，禁止他人的读写，安全。

（C）在一个OS实例里，appA、appB、appC能共用相同的配置。

（D）相对路径总是优于绝对路径。

（E）不需要设置OS级别的系统变量classpath，不需要设置tomcat的classpath。

 

打包的指令：mvn -DskipTests install -P deploy

在point1-0.0.1-SNAPSHOT.jar/META-INF/ MANIFEST.MF里，有两个attribute：

Class-Path: . config/ ../

Main-Class: com.gy.pos.Main

这表明：，classpath包括了：

当前路径，当前的config里的路径，上一级路径。 

有些.xml要单独的拷贝出来，避免出现重复的配置，这用到了maven-resources-plugin。

它们必须在classpath里，而且必须在jar外面，而且还能被别的app共用。

完整的配置：

 运行程序的指令：java -jar point1-0.0.1-SNAPSHOT.jar

path就是jar所在的目录

 

如果.xml还要被webapp（.war）共用，这么设置：

<Class-Path>. /opt/xml_conf/ /opt/lib/a.jar</Class-Path>

注意：它们之间的分隔符是空格，不是“;”或“:”

ecms_config.xml等放在/opt/xml_conf/里，就能被找到了。

95. 外部配置·web程序（war）

如果maven web项目的某子模块用了这个配置，在pom.xml里屏蔽掉。 

在打war包的时候，子模块的jar就 不会 有这个文件了。

然后，在dist或aggregator子模块里修改spring配置：

<context:property-placeholder location="file:../../hsserv/config/posweb_config.properties" />

或者：

<context:property-placeholder location="classpath:posweb_config.properties" />

这是最好的方案，保持spring的xml配置在多种环境dev/test/uat/prod都保持一致。

当然，需要先在OS级别设置系统变量：

CLASSPATH=.:/opt/xml_conf:../config
export CLASSPATH

 

注意：它们之间的分隔符是“:”，不是空格。

注意：这是全局性的，如果OS跑几个app，它们的类路径有同名的配置文件，可能会冲突。

最典型的例子：common-log-0.0.1.jar里有log4j.xml，会覆盖pos-server.jar的log4j.xml。

所以，pom.xml的打包功能，要排除掉这些文件。另外，也只能用人工来提防这个了。

 

有些是无法用classpath的，例如：log4j.xml里设置log文件，那就只能用文件路径了：

<param name="File" value="/opt/hsserv/log/myProj/debug.log" />

事实上，这个值跟classpath也是完全没有关系的。

 96. 外部配置·把spring的配置值传递给Filter

首先，确认几样东东的执行顺序：

（1）ContextListener（标准ServletContextListener、Spring ContextLoaderListener）

（2）Filter

（3）Servlet

所以，在Filter之前，Spring的ctx就已经组装好。

Filter做init()的时候，就能拿到Spring的配置值（myProperties）了。

<util:properties id="my_config" location="classpath:my_config.properties" /> 

以上2行都是spring的标准api。 

通用的Util.getConfigBean()还能在 任何时候任何地点 使用，这就足够灵活了。

97. 外部配置·一种配置有3套配置值

怎么会有3套配置值？后面还能覆盖前面的值？像“传染病”有了传递关系？

对于长期的维护，保持唯一性，很重要。

对于长期的维护，配置文件，越少越好。

再例如：

*-config.properties里有个开关runMock=on

*-config-test.properties里没有设置这个开关

*-config-prod.properties里没有（忘记了）设置这个开关

那么，在prod环境，用的就是开发环境的on！实际上我们需要的是off！

所以，建议删除此xml的*-test.properties、*-prod.properties。

98. 外部配置·自定义的扩展类 

目前，多个app用的是公司common里的：GyPropertyPlaceholderConfigurer，

作用：把多个.properties内容合并为一个大的，能取得配置值。

（A）这样搞，配置值会冲突。

曾经有人说：“制定一个命名方式比较好，比如用子系统标识做前缀”。

其实，“在每个配置文件里面，做监督检查”是很难的。

如同公司规定“禁止全体员工吃牛肉”，很难实现和监督。

（B）config.properties、notice-config.properties、acl-config.properties等等，

本来都是独立的，就不应该在此class里合并。

 99. 外部配置·多个配置文件·推荐的路线 

优点：

1 不需要自己创建class、interface跟Spring做整合。符合大原则：Don’t Write Code。

2 每个配置文件都保持了独立性，都能用Spring getBean()方式得到。

Properties  posConf  = ctx.getBean("pos_PosConf", Properties.class);

里面的Key Value的命名也是最宽松的，随便倒腾都行，不会影响别的.properties。

3 多个配置之间，永远不会有覆盖的事情。

100. 外部配置·全局配置·局部配置

如果公共classpath里已经有了some_config.properties，

但我的app不用那个，只用自己专有的some_config.properties，怎么办？

很简单，把some_config换个新名字some_config_for_myproj。

各种局部配置都可以这么做。