這是IT職場人生系列的第二十二篇。（[序言](http://blog.csdn.net/cheny_com/article/details/6643609)，[專欄目錄](http://blog.csdn.net/column/details/career.html)） （續上篇） ### 獲取幫助 **謙虛、大膽、再謙虛地嘗試** 這幾個詞看起來很不搭嘎，但我細細回憶起來10多年編程的經歷，這句話很可能是高手與低手最后產生差別的關鍵，所以重點寫一整篇。 菜鳥不是低手，低手指的是工作了很久，但技術能力上很落后的家伙。如果作為菜鳥，怎么才能避免成為低手呢？那就是謙虛、大膽、謙虛地嘗試。 未必所有問題都能百度到，也未必身邊一定有高人給予指點，那么遇到困難的時候，我怎么知道有還是沒有方法解決、方法是什么呢？ **1. 謙虛地認識自己面臨的困難** 這是第一個謙虛。 02年遇到一段程序，那個程序員水平不錯，但他偏偏不懂C++中的“模板template”（就是Java和C#中的泛型），所以在處理13種不同數據的時候，不得不編寫了13個函數，正趕上這個函數還在5種參數下運行，結果是編寫了13×5=65個函數。不過最后被發現了，一個下午就縮減到一個函數，一個月的工作量被扔掉。 “作為一個即沒見過又沒聽過模板的程序員，我怎么能預見到會有一種技術解決這些問題呢？”可能會覺得他很冤，對吧？ 這就要解釋“謙虛”的用意：當我們覺得這段代碼很別扭的時候（比如65個函數長得差不多，編程困難，維護更困難），就要嘗試處理它，如果他有這個心態，至少那個“5種情況”可以用一個循環解決掉的。那泛型呢？ 如果用盡了招數，還是剩下13個new不同類型的問題，用自己所學所知都解決不掉，心里要這么想：“我還是一個菜鳥，我不是站在世界邊緣，我遇到的問題，早就有人遇到過了，他們也早就解決了。”有了這個心態，就會去尋找答案，找人或找網絡都無所謂了。事實上，他的項目經理就坐在離他隔一個人的位置上，這位項目經理是個設計模式專家，就別提泛型這點小事了。 多數人找不到答案，是沒有去找答案，因為認為自己正面臨世界難題，這個問題無法解決。 一年前開發的時候，我們面臨很多難題，確切說我們真的“站在世界邊緣”，因為還沒進去呢，呵呵。下面是一些大大小小的我們猜測有答案，而最終果然也有的“難題”。擁有多年經驗的開發者可能對這些問題不以為然，但是對于真正兩眼一抹黑一行C#/Web/...代碼沒寫過的新手，相信這些問題存在答案是很困難的： a. 我們猜測，一個Ajax調用完成后可以調用兩個以上的JS函數作為OnSuccess參數 b. 我們猜測，一個頁面的菜單部分，可以延時1秒后再加載，以便整個頁面顯示的更快 c. 我們猜測，一定可以截獲數據庫的“寫”操作，以便在寫操作發生時同步更新我們的應用緩存，而不是完全銷毀并重建整個緩存 d. 我們猜測，Html的backgound-image應該可以設置偏移量，以便讓底圖出現在合適的位置 e. 我們猜測，一定可以寫一個類封裝MVC中的Repository（Nerddinner中沒有封裝），以便完成任何表的簡單增刪改查 f.? 我們猜測，一定可以把不同的類保存在一張表里邊（Nerddinner里邊從沒提過），拿出來的時候自動生成不同的類型 g. 我們猜測，一個js script可以用Html的Helper生成，而不止限于div/img這些常見的東西 h. 我們猜測，一個類可以在另外一個類的某個函數上方生成（也就是類包含著類，C++里邊是不允許的），因為我們太需要他們兩個定義在一起以便對照了 ……（說不上來一年里邊做了多少猜測了，呵呵） 這些問題，有些有現成的答案，比如f是用Discrimitor字段，c是有個ChangeSet，只要定位了問題，都是google到的答案。 但是并非所有問題都這么解決的，因為有些問題不太好描述，而且也很找到答案，我們還用了下面一些其他的手段。 **2. 大膽地嘗試** 我們當時設置了一種class為tip的<p>，當其母體（class = "withtips"）被鼠標懸停時會彈出，其左上角上有個小圖標（tip是16×16的問號，還有其他種類），以便和warning/notice有所區別。 可是，由于這個問號圖片是用backgound-image: url(...)做的（因而你代碼里邊無需提及這個圖片，只需要加上class = "tip"），當我們寫成 ~~~ background-image: url('../Resouces/Images/Others/Tip16.png'); background-position:top left; ~~~ 的時候，它總是緊緊地貼在p的左上角，沒有留出空白，顯得很難看。查了很多資料，都沒有提怎么辦。 當然，惹不起躲得起，有一種很簡單的方法：不用backround了，在每個tip里邊手工加一個圖片，這樣就可以用style來控制其margin了。這個，就屬于笨方法，經常這樣思考問題，水平就很難提高。 怎么辦？那就是想象：“我是這種語言的設計者，如果讓我來全權設計，我會寫成這樣……” 結果是： ~~~ background-image: url('../Resouces/Images/Others/Tip16.png'); background-position:top 8px left 5px; ~~~ 沒想到，成了。 d、g、h這三個問題，都是這么解決的。 確切說，在這一年里邊很多問題都是這么解決的，不是個例。如果被七八種新技術圍住，光靠google百度突圍是不可能的。 后面會看到，大膽=謙虛，看上去很奇怪的表達式。 **3. 謙虛地嘗試** 有些人剛學一種新語言，因為不懂，又加上自己很謙虛，所以單子就小，就不敢嘗試，其實這里邊反而有問題。 他們想：“我是想這么設計，因為這樣設計最好；可實際設計這些語言的大師們也這么想的嗎？他們真的做到了嗎？” 懷疑大師們的能力？懷疑你的想法大師想不到？其實這實際上隱藏著一種不謙虛的想法。 所以，越大膽的嘗試，越表明我們謙虛地認為前人早就思考和解決過這些問題了，我們只是試試具體寫法是不是正確而已。 “如果嘗試失敗了怎么辦？” 嘗試失敗，往往是因為我們的想象力與大師有差距造成的。一定要做最大膽、最優化的嘗試，這反而會“蒙中”大師們當年的設計。 作為菜鳥，要大膽地想象：“大師們不會設計一種語言，讓我只能重復拷貝代碼65次，或者每次寫tip都必須加上這張冗余的圖片代碼，或者……”，要謙虛地認為大師們早就實現了我們的夢想，天下已經沒有難題了。 為什么很多人編寫了很多年的代碼，有些很有用的東西從來沒用過呢（比如前面65個函數的例子）？原因就是，連想象力都距離大師們甚遠，能力差得就更多了。 這也是為什么提倡編碼要精益求精的原因（參考2月5日和2月20日的5篇文章），如果平時就喜歡寫垃圾代碼，是很難猜中大師的設計的，因為他不會做垃圾設計。 我有一個不等式是這么寫的： **我們的技術能力 < 我們的想象力 < 大師們已經實現的 <? 大師們的想象力** 為什么肯定地說大師們已經實現的比我們的想象力還多？因為拿起一個語言，會發現里邊有很多“沒用的”或“暫時沒用到過的”東西，這些東西就是兩者之差。 所以，阻礙我們的第一個東西是我們的想象力，而不是某種語言或技術的自身限制，連自己的想象力都受到限制，就不可能學好這種語言。 **總結一下本篇：大膽謙虛地與大師共振** 01年我在一個非常有進取心的團隊工作了接近兩年（他們的產品后來占據國內市場60%份額），在那里我們有很多技術夢想，有些我們手工實現了一半，有些限于當年的技術條件無法實現，比如： 1. OODB，一個把數據庫和C++對象映射起來的東西，就是現在的EF和LINQ 2. 限制C++模板的傳入類型，就是現在C#泛型中的where關鍵字 3. MVC分離，當時還只是一個概念，盡管我們努力手工做了很多工作，而現在直接框架化了 ……等等 由于存在夢想，想象力的邊緣就會擴大，而看到LINQ、泛型、MVC這些全新內容的時候，不但不會覺得奇怪和難以理解，反而立刻就會共振起來。 因此，當想象力越來越大的時候，反而學習一種語言越來越容易，因為它多半正好實現了我們想做的事情。 如果長期這樣思考問題，想象力就會接近大師們當前能實現結果，因此會達到共振狀態，連實現的方法都和自己想象的差不多，學習一種新技術就沒有什么太大的難度了。