2008年1月8日
想搬到BlogBus 去
理由如下：
1、BlogBus 速度很快
2、BlogBus 可以提供很好的API 调用，我可以利用JavaScript 整合许多别的应用功能
3、BlogJava 这里的编辑器老出问题，还是我的FireFox 有问题？整得我很不爽
4、我的博客现在不光只有技术了，也不光只关注Java系列的了
新的地址为
http://phoenixtoday.blogbus.com/
看了部电影《钢琴之森》，却被它感动了，触动很大，或许有些话说到心坎里了吧。
故事讲述了两个孩子，一个叫“海”，另一个叫“修”。他们都会弹钢琴，“海”家里穷，却从小与森林里的钢琴一起长大，对他来说钢琴是亲人，是乐趣，是享受，钢琴是给自己弹的，钢琴是存在于他每一个细胞中的；“修”从小练钢琴，从生下来，钢琴对他意味着日本第一，意味着成功，但钢琴就是他的敌人，为了钢琴，他放弃了太多太多，他刻苦练琴只为超越别人，拿得第一，弹钢琴意味着只要不出错，就是完美。森林里的钢琴却只有“海”才能弹响，无论“修”如何努力，森里的钢琴选择的只是“海”。
这个电影，先引发了我的回忆。记得小学我第一次拥有的学习机，大部分时间，我是把它当成游戏机的，可是看着那些动来动去的小人，心里总会犯嘀咕。后来，就照着学习机书本上的，照猫画虎的写了那么几十行还是上百行的类Basic 程序，看着自己写出来的“超级玛莉”可以左右移动，还真的是有些激动，可是那时候的激动，却远远及不上本科之后的那一次。第一次接触真的电脑是在初一，一个电脑培训班里，对电脑有了概念，大致上就明白了一些基本操作和原理；后来有时会去网吧，再后来在初三拥有了自己的第一台电脑，从此才走上了正轨。有了第一台电脑后，不光用它来玩游戏，还开始买《大众软件》，慢慢的会的基础知识越来越多，游戏也玩的越来越多，可是却远远满足不了自己的好奇心，到底这些游戏是怎么做出来的呢？初三的那一年，我将自己的理想从“科学家”细化为“计算机软件学家”，呵呵，当时真的不知道有程序员这个词。大学报志愿，义无反顾的报考了计算机专业，大一第一学期末，用C 语言写出了自己平生第一个程序，望着几百行的main 函数，看着屏幕上闪动的“Welcome” 心里真的激动的不知道说什么好了。本科的计算机真的是偏理论也偏硬件，让一向好强的我，为了在学业上有所作为，硬啃那些不喜欢的东西，好不费力！大一、大二真的是迷茫，走了不少弯路，直到大三开始学Java ，开始自己寻找兴趣的出路，才逐渐有了自己的发展。从小到现在，这条路走的还真的弯弯曲曲，没有得到多少人的帮助，没有得到好老师的指导，一切靠自己摸索，就为了心中那两个字“喜欢”。
“海”的那句“弹琴是为自己弹得，不是为别人”，让我想到了自己。是啊，我写程序，研究技术，从来没有想过为任何人，就为了自己那份喜欢，当然这不是说，我写好的程序给别人带来了快乐，减少了别人的工作量我不开心，而是当初就压根没想到，就是想这个场景可以用自己喜欢的技术，可以这么做，可以做的更好，可以解决以前遇到的问题。而这几年，身边遇到了很多朋友，有时也跟他们交谈，大部分人给我说他当初选择计算机的原因是因为“热门”，少部分的人则是因为“这个行业可以赚钱”，还有几个人我认为是为了“超越身边的人”。这些人，从来没有觉得自己是真喜欢这个行业，这样做是有趣的，他们的动机都是由外在因素引起的，必然不会长久，无法坚持十几年、几十年，甚至一辈子，因为热门的条件会改变，别的赚钱的机会未来会更多，身边的强人你永远超越不完。扪心自问，这真的是你喜欢的吗，它对你来说真的是有趣的吗？如果这个行业只能给你保证温饱，就像很多数学家穷得叮当响，你也会义无反顾的坚守吗？
“如果你弹不出自己的舒伯特，迟早有一天，舒伯特会找你要回曲谱”，是啊，如果你设计不出自己真正想做的程序，那么你的所学所做，又有什么意义呢？而你如果不喜欢自己现在所做，那么将来，你还能做出自己想做的吗？“海”为了弹出自己的舒伯特，每天除了练琴还是练琴，加上自己固有的灵性，最后终于成功。“兴趣”和“爱好”对于你所要坚持的行业来说，是远远不够的，你能够在别人享受生活的时候，自己安静的看书吗？你能真的为了一个目标，每天坚持写代码吗？前几天被同学笑了，因为我说“我过年和平时一样的，看看书，写写程序，没啥不同的”，然后他们笑我“你的生活还真的无趣”，o(∩_∩)o...，其实他们不知道，这才对我是最有趣的，我每天都在享受着，每天都在过年。越深入这个行业，越发现自己所学太少，时间太少，还有很多自己感兴趣的东西，每一门想精深的东西，都还有那么多那么多知识。真的想早一些谱出自己的舒伯特，真的向往那一天，不知道何时真的能达到？努力吧！加油！
昨天，要写一段程序完成一个定时任务，是有关Socket 发送的。胖子给我发了一段现成的程序，这段程序基本上的功能是实现了，但是表达的并不是那么清晰，因此我想重构一下。没想到重构的过程竟然花了一个多小时，从晚上八点多，一下就写到了十点，但是重构完后，感觉清晰多了。仔细想想收获颇多，因此在这里写写经验进行总结。
重构程序的目的，不是因为程序不能用才要你去重构，重构的目的是因为一、你的代码，被人看的次数，远比它用到的次数多；二、重构有利于你发现问题，让你的程序结构优化，因此可复用性更强，遵守了知识的唯一性，DRY 原则；三、如果你要改动这段代码，那么先重构，使得你的代码好改，这实际是在为你的未来减少工作量，而且一段优秀的代码，带给你的价值，远比你每次都要Ctrl+C，Ctrl+V 大得多。
写代码，要让你的代码第一次呈现在别人面前的时候，像读英语一般，那么你的代码功底是足够了。你的代码就可以称作你最好的文档了，其余什么文档，大可不必！
基于昨天的经验，我新总结了两条：
一、经常使用重构方法extract method 的人，会发现，总是可以省掉一些临时变量。这是好事，但这可能会造成如下的结果：
method_one(method_two(method_three(method_four())))
也就是说，很可能会导致这种长串的嵌套，导致程序可读性的下降，使人看的晕头转向。那么如何解决呢，其实是一个度的问题。我给自己定了一个规矩，临界点是三个函数这样级联起来，如果超过三个，我就将它们拆开。比如说上面这个小例子，我会拆成：
arg = method_three(method(four));
method_one(method_two(arg));
虽然浪费了一个临时变量，但是这样就可以让人一眼看懂我的意思，可读性提升，修改起来自然也会容易些。
二、写过Java I/O 的人，肯定看到过这样的程序：
Reader in = null;
Writer out = null;
try
{
in = new InputStreamReader(socket.getInputStream(),"utf8");
out = new OutputStreamWriter(socket.getOutputStream(),"utf8");
/**
* some TODOs here
*
**/
}catch(IOException ioe)
{
System.err.println("error message");
ioe.printStackTrace();
}
finally
{
try
{
if(in != null)
in.close();
if(out != null)
out.close();
}catch(IOException ioe2)
{
System.err.println("some error message");
ioe2.printStackTrace();
}
}
怎么说呢，这段代码看上去，其实是够好了，其实不重构也是可以的。也许我偏执吧，我认为它不够好，因为：首先，大段的try catch 的确会捕获异常，但是这段代码至少有好几段是会独立抛出异常的，这里包含了四个IO 实例的创建和销毁，这四段代码如果出错都会抛出异常，那么你捕获的到底是哪个呢？其次，没有把功能段合理分开，这段代码的逻辑功能实际上是两个，一个是读，一个是写，那么合并在一起，首先顺序很乱，其次容易让阅读的人产生困惑，从而造成代码可读性差。我是这样做的：
private void writeFile(String fileName, String outStr)
{
Writer writer = null;
try
{
writer = new OutputStreamWriter(new FileOutputStream(fileName),
"utf8");
}
catch (UnsupportedEncodingException e)
{
System.err.println("不支持的编码方式");
e.printStackTrace();
}
catch (FileNotFoundException e)
{
System.err.println("初始化文件失败，或路径不存在：" + fileName);
e.printStackTrace();
}
try
{
writer.write(outStr);
writer.flush();
}
catch (IOException e)
{
System.err.println("写文件失败");
e.printStackTrace();
}
finally
{
try
{
if(writer != null)
writer.close();
}
catch (IOException e)
{
System.err.println("关闭文件失败");
e.printStackTrace();
}
}
}
类似的，也将读的逻辑独立抽出来，虽然，这不但没使代码的量减少，却增加了很多try catch 模块，不过逻辑上很完整，而且发挥了每个try catch 的最佳功效。我把它起名曰，我个人的偏执情节吧。
困了，要睡觉了，本来还想将代码从最初模样，到最后模样的过程复述一遍，改天有机会再说，精华都已经说了。嘿嘿