标签：
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.
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。
各种局部配置都可以这么做。
标签：
原文地址：http://my.oschina.net/xiaoyuHe/blog/417365
