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在編程上的差異， 一年之后我成了少數幾個了解整個系統架構的人，編程能力大有提高，對軟件的可移植性也有了較深的理解。

編輯：黃飛