我們每個人都喜歡做有挑戰的，能學到新東西的任務，而不愿意去那些單調重復的，沒有什么新意的事情。然而常常事與愿違，在軟件開發中，前者并非主流，而后者占了大多數。前者未必每次都能輪到你，而后者也總是要人完成的。

面對后者，你可以選擇拒絕接受任務，但那會讓人覺得你工作態度不好，以后好的差事可能就輪流不到你了;你可以選擇走人，換個地方去做，但那也只能禱告，祈求上帝保佑你在別的地方遇到好任務。

其實這都不是好的做法，相反我們應該接受并搞掂它，應該想法轉換它們，完成任務但又不必自虐，從中還能學到東西。下面是我的一些經驗：

1、讓電腦去做重復的工作

Unix文化有一個原則：寧愿花機器一分，不花程序員一秒。單調重復的工作多數都是有規律可循的，有規律可循就可以讓電腦來做。

實例一：在早些年代，那時還沒有聽說autobuild這個概念，發布版本是一件痛苦事情。你要從CVS上取出源代碼，編譯各個版本((英文版, 日文版) x(大企業版, 小企業版, 試用版))，再制定各個版本的安裝包，最后上傳到FTP服務器上。

如果整個過程順利，四個小時差不多了，但事實是從來沒有順利過，結果通常要花費兩三天才能完成。編譯出錯，手工拷貝文件出錯，上傳時放錯目錄如此等等。那位負責做版本的大姐還算有耐心，堅持做了大半年時間，后來這事沒費多大勁就推到我頭上了(呵，大家都認為我好欺負)。

我接手后，第一件事是花了兩天用bash寫了個腳本，把整個過程自動化了，在接下來一個版本中進行了驗證，并修正幾個腳本里的問題，后來發布版本時幾乎不用人干預了。

實例二：如果有人問我寫得最多的程序是什么。我一定會回答是代碼產生器，前前后后、大大小小至少寫過十幾個代碼產生器，小的可能是用bash+awk來做的，也就上百行代碼，大的用C/C++來寫，動則數千行代碼，最大的竟達8000多行C++代碼。

大部分代碼產生器都為我節省了不少時間，或者至少把單調重復的事情變得有趣一點了，而且得到的代碼也更穩定可靠。

2、換種思路，看有沒有捷徑

有些事情單調重復，本來也是可以讓電腦去做的，但是開發相應的工具要費更多的時間，得不償失，這時不換一種思路，或許別有洞天。

實例一：曾接到一個任務，要求找出一個公共函數庫里的所有全局變量。那個庫是個大雜燴，里面什么東西都有，凌亂而龐大。時間期限是一周，時間比較充足，即使一個文件一個文件的去找，時間也來得及，但那太痛苦了。

更麻煩的是這個庫是變化的，可能剛剛完成任務，又有人加了一個全局變量，這樣就很難拿到一個最新的結果。怎么呢，我想，編譯器肯定是知道哪些是全局變量的，所以第一反應是拿一個開源的編譯器修改一下，讓編譯器告訴我結果。

修改編譯器可能也要一周時間，但利用它隨時可以得到最新結果。有沒有更簡便的辦法呢？猜想VC輸出的map文件或許有些幫助，打開map文件一看，果然如此。讓VC編譯該庫并輸出map文件，取出全局變量列表，搞掂了。從接受任務到完成任務前后不到一個小時。

實例二：前幾天，同事拿一個第三方庫，編譯時發現那個庫是用帶硬件浮點數的toolchain編譯，而我們的toolchain用的是軟浮點數。盡管反匯編出來，沒有發現浮點指令，但編譯器就是不讓鏈接該庫。我們的方案是，反匯編它再重新編譯它。

但反匯編出來的格式與as的輸入格式有些差異，要花不少時間去修改，修改之后發現還是編譯不過去。最后，這個任務又落到我頭上了。

我想既然沒有用浮點指令，編譯器不讓編譯可能是因為一個標志引起的，于是花了點時間去研究ELF(linux下的可執行文件格式)文件格式。果然是文件頭中一個標志引起的，寫了個小程序為該庫加上這個標志位，編譯就通過了。

3、換種心情，坦然接受

如果面對一項任務，你別無選擇時，那就坦然接受它吧。然后想法說服自己，讓自己有個好的心情，這樣的任務總是要有人做才行。還可以告訴自己，一定要從中學到點東西，即使從中學不到技術，也要從中學會忍耐。

當我從QA組進入RD組時，我任務是把Win32程序移植到linux下。這個任務比較重要，但絕不是什么好任務，工作本身單調不說，別人還瞧不起。他們認為這都是很簡單的，不用動腦子的體力活。

同組的同事很多都走了，新來的同事也呆不了多久。但我堅持下去了，移植的同時去研究那些代碼，去研究Win32和linux在編程上的差異, 一年之后我成了少數幾個了解整個系統架構的人，編程能力大有提高，對軟件的可移植性也有了較深的理解。

編輯：黃飛