项目中遇到的小问题，总结。敲响警钟！

俗话说，人无完人。编程难免有出错的时候，在这里记录下来，警醒一下自己，吾日三省矣！

调用比人的方法的时候，没有注意他的命名规范符合自身系统的要求，就拿来主义。

如：byte S[] = { 99, 124, 119, 123, (byte) 242, 107, 111, (byte) 197, 48, 1......}中的s是大小写，在java中应该小写。
实现一种功能有很多种方式，但要选择最适合你系统要求的。

如：随机生成32位的十六进制字符串

// String s="AAC728728BB1D3ADBF7541D2DFF5FA90";

1、直接生成16进制的字符串

//		String s = "";
//		for (int i = 0; i < 4; i++) {
//			s = s + Integer.toHexString(random.nextInt());
//		}

2、先变成字节再转成成字符串

Random random = new Random();
byte[] result = new byte[16];
random.nextBytes(result);

总结：我一开始选择的是第一种，觉得方便，但是后者生成的随机数方式和系统中另一个使用的参数要求配对，而且另一个参数也是从byte[]类型转换成String类型，为了提高系统的稳定性，当然是第二种比较优越了！

JUnit的使用，不单单是用logger.info()，更重要的是测试和预期的值相等不相等，压力测试。

如：

<pre code_snippet_id="117191" snippet_file_name="blog_20131218_4_590401" name="code" class="java">

@Test
	public void testGetOPCMapString() {
		for (int i = 0; i < 100000; i++) {
			gen.getSN("1813000208000", i);
			final Map<String, String> opcMap = gen.getOPCMap();
			logger.info("gen.getOPCMap():" + opcMap);
			logger.info("gen.getOPCMap().get(K):" + opcMap.get("K"));
			logger.info("gen.getOPCMap().get(K).length():"
					+ opcMap.get("K").length());
			Assert.assertEquals(32, opcMap.get("K").length());
			logger.info("gen.getOPCMap().get(OPC):" + opcMap.get("OPC"));
			logger.info("gen.getOPCMap().get(OPC).length():"
					+ opcMap.get("OPC").length());
			Assert.assertEquals(32, opcMap.get("OPC").length());
		}
	}

JUnit中的注解使用：

@Before
	public void setUp() throws Exception {
		//做一些初始化的工作，比如初始化数据库连接、new接口等操作
	}
@After
	public void tearDown() throws Exception {
		//关闭资源的操作
	}

/**
 * Test method for {@link com#Method()}.

* 注意使用# 的时候,eclipse后面会提示前面com包中的方法

* @throws IOException 
 */
@Test
	public final void testMethod() throws Exception {
		//里面写测试方法
	}

用搜索引擎搜索的时候，对于编程问题来说，优选英文内容，什么How to Generate Random Numbers in Java，什么out file fast in Python，都往上拽！

-------------------------------------------------------------------------------

2013年12月18日更新：

java编程中'为了性能'一些尽量做到的地方： 总结的也很不错，要是带上例子，那就更好了！

-------------------------------------------------------------------------------

2013年12月20日更新：

在远程调试中，你的logger.debug或者logger.info失效，也就是说，在该处下断点也不执行了。

这时候你需要的是检查你的配置，因为出现这种情况，一般有两种情况：

检查项目的classpath，即查看buildpath中的Default output file是否是本项目的位置
检查tomcat目录\conf\catalina\localhost下的ROOT.xml文件的docBase和workDir的值，也要对应于本项目对应的本机地址。

Happing Loggering！

作为独立开发者，突然之间要加入到团队开发中，吐槽一下自身的感受

之前一个人开发习惯了，想到什么就些什么，而且也不会有什么阻碍，反正自己都明白。但问题来了，投身于团队开发中，每个人负责的模块都是不一样的，你很可能不了解其他人的模块，假设此时 Project Leader要求你熟悉该模块，然后在该模块的基础上增加或重构某功能，那你的麻烦也就来了。

为什么呢？首先，你会去找到该模块的负责人，然后和他沟通，恰巧他也有时间，直接把模块的细节以及注意的地方都跟你说了。但是这可是最理想的状态。假如他有事出去了；心情正好不佳；或者正在开会。在现实中这些事情发生的频率很高。
纳尼？你会不会放弃不做了呢？肯定不会，因为这涉及到团队的整体进度和荣誉感！
有一个不错的解决方案：团队内已经有一个较成熟的模块说明文档，里面涉及的细节和依赖的模块写的都很清楚。你从源码管理工具或Github上同步下来，花个十来分钟，相信你就明白70%、80%了。这可以让你继续进行下去，身下的20%、30%找机会和负责人一碰头，这问题，不就稳稳的了。
极端的情况：假设团队今天就你一个人来了，其他人都有事，但是每个人的文档都很全面，注意事项更新的很及时，那这个项目照样可以运转下去。


-------------------------------------------------------------------------------

2014年3月3日更新：

重构老系统的时候，不建议修改某方法里面的逻辑，因为它已经部署，动一个地方很可能就会影响系统中其他的功能，除非你有十足的把握。

<span style="white-space:pre">	</span>建议，写一个方法级别的单元测试，只是把入参修改，这样完全可以达到测试新功能要求。

对于方法而言，应该是独立的、纯粹的。即方法体不应该有多余的，与该方法内容不相关的东西。

private String buildMan(...){
	if(判断男生){
		//男生逻辑...
	}else{
		//女生逻辑...
	}
}

修改建议：

private String buildMan(...){
		//男生逻辑...
}

private String buildWoman(...){
		//女生逻辑...
}

很多时候，比起switch ,更偏向使用每个分支写成一个方法的方式来处理。

好处是不用每次加分支情况都要修改原来的函数：加一个case。而方法的方式可以写单元测试，容易管理。

构造方法里面可以干很多事情，比如对成员变量的修饰（null值的处理）等。

1、时间格式的处理

applyTime != null ? applyTime.substring(0, 19) : null;

2、读取文件配置值

PropertyResourceBundle prb = (PropertyResourceBundle) PropertyResourceBundle.getBundle(CONFIG_BUNDLE_NAMEDB);

增强代码的可读性，比如对if... else if..else..的处理

if(){
...
}else if(){
...
}else{
...
}

可以变成一行：

boolean isMan=buildMan();//可以通过方法来返回Man值，为下一步多元操作符做准备。
isMan? .. : isTwenty? .. : ..

对于null值的处理，可以采用类似apache的第三方类库，也可自己编写，不过要注意。

if(..==null){
	//1.抛出异常(log.error(...);)
	//2.返回null值(return null)
}

-------------------------------------------------------------------------------

2014年3月6日更新：

项目导出jar包的时候，配置文件不要一起打包到里面，如果要改一些数据库连接字符串、文件读入输出路径都是因人而异，而且大大增加了灵活性！
更到读取配置文件，请参考：java读取properties文件方法和对比
jar包导出为exe可执行文件，工具推荐：Jar2Exe Wizard
如下：

String filePath =System.getProperty("user.dir") +"/config/SMSConfig.properties"; 
		Properties prop;
		try {
			InputStream in = new BufferedInputStream(new FileInputStream(
					filePath));
			prop = new Properties();
			prop.load(in);
			in.close();
			String sms_BackPath=(String) prop.get("sms_BackPath");
			String sms_TempPath=(String) prop.get("sms_TempPath");
		} catch (Exception e) {
			
		}

清空tomcat安装目录下的work目录，可以解决程序没有及时更新修改过的代码问题，也就是消除缓存。

参考文章：关于tomcat下的work目录、tomcat缓存的问题!

-------------------------------------------------------------------------------

2014年6月3日更新：

慕课网

最近项目重构中，发现一个类似于上面2014年3月3日更新的内容（读取配置文件一项）的问题，又碰巧在慕课网上发现了类似的讲解，推荐给大家，也发现工作当中会不知不觉的用到设计模式，你能发现这个设计模式很好，这样就有方向学习，而更重要的是需要巩固设计模式，达到灵活应用的目的。