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 的最佳功效。我把它起名曰，我個人的偏執情節吧。
困了，要睡覺了，本來還想將代碼從最初模樣，到最后模樣的過程復述一遍，改天有機會再說，精華都已經說了。嘿嘿