2008年1月16日
想搬到BlogBus 去
理由如下：
1、BlogBus 速度很快
2、BlogBus 可以提供很好的API 調用，我可以利用JavaScript 整合許多別的應用功能
3、BlogJava 這里的編輯器老出問題，還是我的FireFox 有問題？整得我很不爽
4、我的博客現在不光只有技術了，也不光只關注Java系列的了
新的地址為
http://phoenixtoday.blogbus.com/
2008年1月12日
看了部電影《鋼琴之森》，卻被它感動了，觸動很大，或許有些話說到心坎里了吧。
故事講述了兩個孩子，一個叫“海”，另一個叫“修”。他們都會彈鋼琴，“海”家里窮，卻從小與森林里的鋼琴一起長大，對他來說鋼琴是親人，是樂趣，是享受，鋼琴是給自己彈的，鋼琴是存在于他每一個細胞中的；“修”從小練鋼琴，從生下來，鋼琴對他意味著日本第一，意味著成功，但鋼琴就是他的敵人，為了鋼琴，他放棄了太多太多，他刻苦練琴只為超越別人，拿得第一，彈鋼琴意味著只要不出錯，就是完美。森林里的鋼琴卻只有“海”才能彈響，無論“修”如何努力，森里的鋼琴選擇的只是“海”。
這個電影，先引發了我的回憶。記得小學我第一次擁有的學習機，大部分時間，我是把它當成游戲機的，可是看著那些動來動去的小人，心里總會犯嘀咕。后來，就照著學習機書本上的，照貓畫虎的寫了那么幾十行還是上百行的類Basic 程序，看著自己寫出來的“超級瑪莉”可以左右移動，還真的是有些激動，可是那時候的激動，卻遠遠及不上本科之后的那一次。第一次接觸真的電腦是在初一，一個電腦培訓班里，對電腦有了概念，大致上就明白了一些基本操作和原理；后來有時會去網吧，再后來在初三擁有了自己的第一臺電腦，從此才走上了正軌。有了第一臺電腦后，不光用它來玩游戲，還開始買《大眾軟件》，慢慢的會的基礎知識越來越多，游戲也玩的越來越多，可是卻遠遠滿足不了自己的好奇心，到底這些游戲是怎么做出來的呢？初三的那一年，我將自己的理想從“科學家”細化為“計算機軟件學家”，呵呵，當時真的不知道有程序員這個詞。大學報志愿，義無反顧的報考了計算機專業，大一第一學期末，用C 語言寫出了自己平生第一個程序，望著幾百行的main 函數，看著屏幕上閃動的“Welcome” 心里真的激動的不知道說什么好了。本科的計算機真的是偏理論也偏硬件，讓一向好強的我，為了在學業上有所作為，硬啃那些不喜歡的東西，好不費力！大一、大二真的是迷茫，走了不少彎路，直到大三開始學Java ，開始自己尋找興趣的出路，才逐漸有了自己的發展。從小到現在，這條路走的還真的彎彎曲曲，沒有得到多少人的幫助，沒有得到好老師的指導，一切靠自己摸索，就為了心中那兩個字“喜歡”。
“海”的那句“彈琴是為自己彈得，不是為別人”，讓我想到了自己。是啊，我寫程序，研究技術，從來沒有想過為任何人，就為了自己那份喜歡，當然這不是說，我寫好的程序給別人帶來了快樂，減少了別人的工作量我不開心，而是當初就壓根沒想到，就是想這個場景可以用自己喜歡的技術，可以這么做，可以做的更好，可以解決以前遇到的問題。而這幾年，身邊遇到了很多朋友，有時也跟他們交談，大部分人給我說他當初選擇計算機的原因是因為“熱門”，少部分的人則是因為“這個行業可以賺錢”，還有幾個人我認為是為了“超越身邊的人”。這些人，從來沒有覺得自己是真喜歡這個行業，這樣做是有趣的，他們的動機都是由外在因素引起的，必然不會長久，無法堅持十幾年、幾十年，甚至一輩子，因為熱門的條件會改變，別的賺錢的機會未來會更多，身邊的強人你永遠超越不完。捫心自問，這真的是你喜歡的嗎，它對你來說真的是有趣的嗎？如果這個行業只能給你保證溫飽，就像很多數學家窮得叮當響，你也會義無反顧的堅守嗎？
“如果你彈不出自己的舒伯特，遲早有一天，舒伯特會找你要回曲譜”，是啊，如果你設計不出自己真正想做的程序，那么你的所學所做，又有什么意義呢？而你如果不喜歡自己現在所做，那么將來，你還能做出自己想做的嗎？“海”為了彈出自己的舒伯特，每天除了練琴還是練琴，加上自己固有的靈性，最后終于成功。“興趣”和“愛好”對于你所要堅持的行業來說，是遠遠不夠的，你能夠在別人享受生活的時候，自己安靜的看書嗎？你能真的為了一個目標，每天堅持寫代碼嗎？前幾天被同學笑了，因為我說“我過年和平時一樣的，看看書，寫寫程序，沒啥不同的”，然后他們笑我“你的生活還真的無趣”，o(∩_∩)o...，其實他們不知道，這才對我是最有趣的，我每天都在享受著，每天都在過年。越深入這個行業，越發現自己所學太少，時間太少，還有很多自己感興趣的東西，每一門想精深的東西，都還有那么多那么多知識。真的想早一些譜出自己的舒伯特，真的向往那一天，不知道何時真的能達到？努力吧！加油！
2008年1月8日
昨天，要寫一段程序完成一個定時任務，是有關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 的最佳功效。我把它起名曰，我個人的偏執情節吧。
困了，要睡覺了，本來還想將代碼從最初模樣，到最后模樣的過程復述一遍，改天有機會再說，精華都已經說了。嘿嘿
2007年12月31日
今天早上打破了原本的計劃，對于網上看到的一位小狂人，發表了很多看法。中國IT 這個行業就是這樣的，普遍的年輕化，輕狂化，但是真正的大師卻少的可憐。看了看自己在豆瓣上的“想讀”列表，突然覺得時間大大的不夠，心里又激起了一層漣漪，打破了那片平靜。不過經過一個小時的深入思考，我又重歸了那份平靜。
我是贊成中國道家學派的，人只有歸于平靜，身體和心靈都達到陰陽調和的狀態，心情穩定，脾氣溫和，頭腦冷靜，做事要循序漸進，才可以穩穩當當，根基牢固。所以我個人并不羨慕暴發戶，也不羨慕那些少年得志的人。一個完整的、健全的人，成大事的人，是要體會人生的低潮期的。和命運作斗爭的過程，你的思想和心智都會得到歷練，正如古人所說“天將降大任于斯人也，必先苦其心志，餓其體膚”，沒有經歷過失敗的人，是很難長久守住你的成功的。就像我上個禮拜讀的那本書里寫的故事一樣，一夜成名者，招致的嫉妒和怨恨太多，不是自己不夠優秀，而是環境不允許你優秀，終歸無以成大事。所以，做人還是要謙虛謹慎的，扎穩根基，一步一步的來，厚積而薄發。
思考到這一步，心情從浮躁終歸于平靜了。所以還是應當遵循我的目標，一步步來，時間之與我，的確寸秒寸金，所以我不能把這些時間浪費在對人生太多的感慨中，而應當去努力的尋覓，去體驗生活，去做自己該做的事情！不去空嘆光陰似箭，也不去妄自菲薄！從現在開始投入到實際的工作中吧！
2007年12月22日
今天算是在2008年的中國年、圣誕、陽歷年新年之前，所以我寫這篇blog無論你怎么算，那可是真正意義上的辭舊迎新啊（哈哈，我又有點偏執了）。一個目的，過去的一年是很精彩的，也很開心，我很努力，也收獲很多。未來的一年，我要更加好好珍惜我的朋友們，更加努力的面對一切困難和挑戰，擁抱2008！
在2007年發生了很多事情，有些可控，有些不可控，但是整體上來講還是收獲遠遠大于付出的。而我熱愛的軟件開發行業，也還是處于藝術的那種狀況，而且我估計在未來的10到20年仍舊會繼續這樣的情況，因此我還是可以以藝術家自詡的（哎呦，好臭屁啊！），我也會繼續充滿熱情的投入到這個行業中去。
過去的一年里，值得自豪的事情有（排名不分先后，想到哪寫哪的）：
1、做事情做的問心無愧，努力做好了每一件事情，認真面對生活的每一個細節
2、在繁重的項目壓力下（最多同時負責五個項目，還要帶團隊OOPS，還要帶導師的兒子，555555），依舊能堅持學習從而提高自己
3、體驗了一把累病了的滋味，并成功恢復了健康，而且在累病了期間感悟了許多人生，收獲頗多。恢復健康后，一直堅持鍛煉身體，現在的身體狀況一級棒！還胖啦，哇哈哈
4、在年底，順利的完成了項目的平滑交接，讓研二的師弟師妹們成為導師值得信賴的動力，最值得自豪的是我將很多平時鉆研的開發軟件的技術、思想和經驗延承了下去，培養出實驗室良好的研發氣氛（應用了很多極限編程和敏捷開發的思想哦）。
5、找了一份非常適合自己，非常喜歡，有良好前景的工作
6、完成了6到7個項目，做了兩個自己能給85分以上的項目（NASAC 論文評審系統和華秦智能管理系統）
7、深化了Java 語言的運用，可以熟練的使用Spring、Ajax、OSGi等框架和技術，深入研究了敏捷軟件開發和項目管理的種種方法，并應用到實際的項目中去。總之是深化了自己最擅長的技術，而又學會了許多新的技術。
8、珍惜了已有的朋友，又新交了許多優秀的新朋友
9、好好孝敬了父母，做了很多父母都為我自豪的事情
10、明確了自己下一步要做的計劃（這一條我感覺是在湊數吧，哈哈，圓圓滿滿吧）
過去一年里有些可惜的事情：
1、感情道路依然坎坷啊，還是沒有方向啊，哎～～～～
2、以后要注意身體的，不能再次累病了，切記切記哦
3、研究生階段有車有房的目標看來是宣告破產啦！
4、沒有出去實習一次，的確是有些遺憾的
嗯，開始未來的計劃吧：
1、依然要做事認真，注意細節，問心無愧；做一個正直的、善良的、有責任感的男人！
2、堅持鍛煉身體，讓自己再胖一些吧！
3、認真的、充滿熱情的投入到TW 的工作中，好好的和同事們相處，多交各種各樣的朋友，并努力增加知己的數目
4、努力使自己的感情道路不要再那么坎坷了，慎重慎重！
5、深化自己已掌握的知識包括深化敏捷開發、Spring2.X（包括Spring Web Flow、Spring OSGi 等等）、Ajax（GWT 和CSS，尤其是CSS，一定要做到是真的可以用它來改變自己的風格和布局，而不只是簡單的樣式而已，master it）；新的知識呢，再努力掌握RoR、Python、Erlang和項目風險控制、項目估算的相關知識，學會使用Unix/Linux 操作系統，并堅持下去，深入研究下Android 并努力應用到實際的項目中去；努力使自己的軟件架構能力更上一層樓；努力提高自己的代碼編寫質量，達到90分以上
6、完成自己的BoBoBlog release 1
7、好好的，順利的在四月份完成畢業（這個不難吧）
8、如果有出國的機會，努力把握之，好好見識一下！
9、讓自己的英語能夠，看英文書不累，跟看中文書一樣；跟老外對話不需思考，聽口音重的老外講話也OK
10、學會做一手好菜，努力讓自己的父母更開心快樂
好了，咋想也想不出來啥了，辭舊迎新、辭舊迎新！寫此文以表決心！
2007年12月19日
上周六、日兩天參加了公司的Away Day。作為一名還沒入職的員工，能有這樣的機會融入進去，實在很難得。兩天的行程是這樣安排的，第一天主要去聽一些session，包括技術和非技術的；第二天就是真的away 啦，吃喝玩樂嘍。整體感覺很舒心，公司的同事們都很好，很open mind，大部分都很健談，很樂于幫助你。兩天的生活感觸多多，交了許多新朋友，也看到了差距和很多新的有趣的東西以供我修正自己前進的方向。
第一天剛進公司，就感覺外國人很多，我覺得公司在中國也就一百多號人，外國人至少占了三分之一吧。來之前就知道，公司的總部加大了對中國部門的投入，鼓勵國外優秀員工進入中國幫助中國同事提高他們的項目完成能力，但是真的親眼見到才覺得挺震撼的。這一天最有感觸的是幾件事，第一件事情是，剛進公司沒多久就被發了一件印有公司名和Away Day 的長袖衫，趕緊穿上。然后所有人都乘電梯下到一樓去參加全體大會了，大會主要是對過去一年的總結，可以說是一個大大的show off 吧，才發現原來中國分公司在過去的一年中做了那么多重大的事情，收到了那么多客戶的表揚和贊賞。心里著實的高興了一把。然后就是Roy 給我們打氣啦，說原來他是以麥肯錫為目標的，結果現在是麥肯錫以TW為目標，然后小小透漏了一下公司的秘密，那才真的是最震撼的，這件事情讓我真的確信了我們加入了一個全球最好的技術咨詢公司。從同事那里聽到Roy 是一個極其個性的領軍人物，是他決定了四年前公司進行Ruby 相關的實驗開發（四年前啊，那是Ruby才出來，真有遠見），是他反對公司進行股票上市，是他確定公司的目標為“using IT to make the world better”，還是他以自己的孩子專業是“促進世界和平”而自豪。進公司之前就聽說了TW 絕對是非常人性化非常公平的一個公司，每個TWer 都覺得自己的公司是最好的，都很自豪，自己經歷一下才發現是真的，因為對中國地區的老大當場就開始投票了，而且是絕對的公開投票，當然結果還是我們的G 大大了，因為他做的的確足夠好，后面還有一段和他的故事呢。開會的最后，還有一件值得一提的事情，那就是見到了傳說中的TW 第一美女 S，Sun 高層挖過來的，據說Java TW 第一人啊。真的是很漂亮，美麗的英國lady。
這一天值得提起的第二件事情，就是參加的session 了，印象最深的是A （就是面試我那個）講的Erlang。在來之前，好像在雜志上還是網上略知一二，就是下一代語言么，很支持并行編程的那種，號稱是下一代語言中的Java，這個自然是要狠狠的關注一下的。A 在講的時候，好像也不那么熟悉，后來被問倒了，還真的很不好意思哪，哈哈，不過沒什么，大家人都很好。我知道在Java 中同時處理千級別的線程就會出現比較嚴重的問題了，而且那程序寫的可就是相當的難看啦。當天聽了Erlang 的session，說是并行度可以輕松達到萬以上的級別，而且不會像Java 中出現對具體線程的控制模塊。我看到了那些示例程序，很優雅的腳本，從來沒有出現諸如synchronized 這些詞匯。語言風格有點DSL 的味道，Erlang 也是腳本語言，而且與那些主流語言的風格很不相同，是一種自頂向下，逆推式的風格。熊哥哥給我們當場演示了一個用Erlang 完成的消費者模式的程序，寫的的確很清晰。據說公司有一個項目正在做的就是用Erlang，真的是很佩服TW 的先驅思想和執行力度。
晚上吃飯也發生了一件很有趣的事情——看TW 的酒協與來自澳大利亞的C 拼酒還有C 勸老大喝酒。C 是很壯的那種外國人，高大、英俊、強壯，那酒量，那可是相當的相當的......TW 酒協會長，差點就栽在他手里了。下一次一定能和C 合張影，他是給我感覺最好的外國人，很想和他成為朋友，幽默有趣，個性開朗。
晚上回到旅館和小龍聊了好久，小龍透漏給我一個很有價值的信息，那就是在TW 里，如果你有好的想法，可以做一個session 希望大家和你一起同做，這對我來說可是天大的福音了。呵呵，加油，給自己打打氣！
第二天的行程是爬長城和去紅螺寺，一天里最有趣的事情莫過于和老大在車上玩殺人了，學會了一句經典對白“現在，我來理性的分析一下”，說的時候要注意臉部表情要認真嚴肅，聲調要低但是要有穿透力和震撼力，不然沒老大那效果。這是和老大在整個行程中最親密的接觸了，后來在爬長城的時候，還和老大和熊哥一起合影了。
記成流水帳了，哎，真不好。不過兩天行程很緊張，活動密度大，經歷的事情都是沒經歷過的，將就點吧。呵呵。我想我會在公司里好好努力和發展的，因為看到公司里很多人都是我這樣的，不僅是喜歡這個行業，更想創造出無限的價值，來讓生活更美好，藝術家，藝術家啊（哈哈，自夸了，真的好邪惡啊——這是和NaNa 學到的一句經典對白）。
2007年12月11日
看了同事的一篇Blog 講的Uncle Bob 好像是生病了，還要用嗎啡。不是真的吧，我可是看他的《敏捷軟件開發》才開始喜歡上敏捷軟件開發的，真的希望這不是真的，如果是真的，那我在這里祈禱希望他早日康復。
順便提一下吧，今天看了了Jessie 的Blog 真的很喜歡Thoughtworks，大家讓我感覺到那里是很開心的，很開朗，很人性的一個環境。有很多小故事都令我挺感動的，舉一個小例子吧，我們在北京的住房都是公司幫我們找好，我們去看的，能做成這樣的公司，全中國能有幾家？好了，這算是我遇到前所未有的明主了，好好干吧，加油！
人生就是這樣，有得有失，不過只要自己一直努力，那么得到的總會比失去多。我很滿意啦，很知足啦！
2007年12月9日
前兩天看到一個有趣的觀點：早崩潰，不破壞。這個理論給我了許多思考，不只是軟件開發上的，更有很多對人生的看法。
這個理論大致是這樣的一個意思：當前的軟件設計，與其說是科學不如說是藝術，因為并沒有一個嚴格的方法和論斷可以定奪一個軟件的好壞，也沒有一個確定的工業標準（通常很科學化的東西都可以很快的用工業標準來描述）可以指導、確保軟件的開發過程不那么隨意。正因為如此，當前的軟件世界問題多多，而且久違的銀彈還是沒有出現。那么，在實際開發的過程中，如何開發出一個質量高，又符合要求的系統呢？這就是“早崩潰，不破壞”理論存在的價值了。它是說，項目你可以讓它盡早的崩潰，實時的崩潰，以發現問題，從而改正這些Bug，使系統能夠暴露問題，盡早的恢復到正常的狀態。這就引出了測試要頻繁的進行，甚至是使用測試驅動進行開發。當然開發的早期，會陷入比較痛苦的狀態，問題多多，不知道如何解決。不過這些都是有好處的，做了這樣的工作，確保了發展方向和軟件質量的正確性，就使你的系統在最后才不會產生嚴重的破壞。破壞——disaster 級別的，有時是很難恢復的。所以這么看來，前期的打擊會造就后期的輕松與成熟，這何嘗不是大大的值得呢？
這個理論看似只是針對軟件開發的，卻給我了許多額外的思考。生活、工作、愛情等等又何嘗不是這樣的呢？
生活中，從最小的小孩子呀呀學語，蹣跚學步，多讓家長“崩潰”啊，是不是，呵呵（其實我覺得那時候要是自己有意識，也會很崩潰的），可是卻造就了他們未來發展的基礎；最近要開始學做菜，因為要去北京發展了，這個學習過程也是很崩潰的，不過想想未來，做菜可以帶來自己伙食的改善，可以增加自己的技藝，可以讓家庭更幸福，可以讓父母更開心等等，這個未來的力量還是很強大的。所以，生活實際上也是“早崩潰，不破壞”的。
工作中，你初期進入公司，總有個人生地不熟的過程，總有個和公司文化適應的過程，不是每個人都那么幸運，可以一去就融入環境的。一進公司，要學習很多知識，要學會與同事友好的相處，這些東西別看貌似很小，其實壓力會不小的，所以也是很“崩潰”的。但是從長遠來看，只要你努力的去做好前面的一切，那么這樣的過程會讓自己得到很大的提高，會讓你的人際關系更加的順暢，會讓你的工作更加的舒心，當然經濟價值也會逐漸的體現出來。這就使得你后期的“破壞”的可能性就很低了。看來有時“郁悶”“崩潰”不見得是一件壞事情，關鍵是你不要迷失，不要認為你的生活會永遠如此，要開朗些，陽光些，繼續努力下去。
最后就是關于愛情了。我有一些朋友曾經跟我說過他們希望找從來沒有談過戀愛的女孩子或男孩子，這樣固然是好，因為單純，可以給人很純凈的愛情的感覺。但是我個人覺得，如果一些女孩子有過戀愛的經驗，至少是曾經很努力的去喜歡過一個人，能成熟的思考一些問題。這對于將來的愛情和婚姻是很大很大的一筆財富（當然愛看書的女孩子除外，因為她們可以從書中體驗人生，使自己思想成熟起來）。先前的愛情失敗的確會讓一個人很“崩潰”的，愛情失敗無所謂對錯，兩個人不可能一方全對，另一方全錯。兩人皆有不對的地方，皆有處理不當的事情，只是多少而已。失敗的愛情雙方都是輸家，沒有人是贏家。不過這樣的“崩潰”是有好處的，它會引起你的反思，會讓你思考自己的錯誤，從而為下一次感情做好準備。當然，“崩潰”的原因，也可能是真的不合適，那么你就更要好好總結一下，從而為下一個合適的做好準備。關鍵是，不要讓“崩潰”麻痹了你，喪失了去追尋真愛的勇氣，這是最最主要的！“崩潰”不是“破壞”，關鍵是看你怎么處理，怎么對待。只要結局不是“破壞”，那么前期的“崩潰”均是有很大的價值的！
歸根到底還是，要有勇氣，要能耐得住壓力和寂寞，不要為社會和生活的繁雜喪失那顆珍貴的心，在那最艱難的時刻，聽聽你自己的心是怎么說的，堅強下去，你可以的。
傻傻的想，傻傻的揣摩，隨便寫寫，從軟件談到人生，供大家思考。
2007年12月6日
When asked "Do you write tests?", a lot of developers these days will
say "of course" as their answers. However, not everyone can admit to
doing TDD (Test Driven Development) correctly. Test Driven Development
says, a developer will write a test that fails first, then write code
to make the test pass, and refactor when possible, and repeat. This is
what most people's TDD rhythm is. For the most part this is fairly easy
to do. But to reach the next level, one has to understand TDD as a
tool: TDD means more than just test your own code. Here is a couple
tips on what the last "D" means:
Discipline
It
takes a great deal of discipline to even write a failing test before
writing the actual code. Sometimes, we write a little seudo-code here,
or move a method definition there, or changing code else where trying
to see if more new code needs to be written after it, and sooner than
you think you are writing the actual implementation of the methods you
wanted to test (Test Afterwards Development anyone?). Other times you
write the test, but you are too anxious to even run it and see it
fails. And other times you want to jump into the actual code
immediately when you see your new test fails, but failing for the
unexpected reasons.
Don't fall into these traps. If anything is true, testing is hard, but it is at the same time rewarding and fun. What's also true is, it will pay off.
Write the failing test, draw up your list of tests you will need to
write, and satisfy them one by one. Having discipline is the
cornerstone of becoming a better programmer.
Design
It
takes too long to write a test? Tests are running too slowly? Are your
tests difficult to read? Are they too brittle and fail all the time?
Hang in there! You ever had the feeling you saw code in the codebase
that irks the living hell out of your mind written by someone else on
your team? Well, it is time for you to get some of these feedback about
your own code. Yay, your code sucks! Your tests
are telling you that! Let's address each of these one by one.
Slow
running tests? You shouldn't be hitting a database or web service in
your unit tests, because you can mock/stub them out. Difficult to
mock/stub it out? There probably is a better way to design your classes
your tests are hitting. Ever heard of Inversion of Control (or
Dependency Injection)? Master them. True TDD masters use them
extensively.
Unreadable tests? Is it because of too many
mocks/stubs? Or is it the code is 500 lines long and doing high octane
720-double-backflip logic? Either way, you have to learn to like small
objects. Check this
blog post of mine out.
Hard
to test something? Tests too brittle? Perhaps you have encapsulation
issues in your class design. If your classes are referencing 15 other
neighbors, of course they are hard to mock/stub. Chances are, you have
to spend time to debug your tests to find out what's wrong! Heard of
Law of Demeter? Even if you have, take a look at this
highly entertaining yet informative post. It might change your perspective a little.
The
bottom line is, TDD is a way to guide you to writing good code, but
only if you know how to use it as a tool. Now that you know, hopefully
you will have a new perspective next time you write a test.