別把自己當個超人——給初級程式設計師的一點小小建議

我在Twitter上看到了一篇有趣的博文——你可以先看看。如果你懶得上Twitter看，看我轉載這篇的就行了。

---

有一天我和我的朋友Simone一起喝咖啡，期間我們聊起一些工作上的事情。我們倆都管理著一些員工，為了說明給初級職員分派任務時出現的問題，她打了一個絕妙的比方。

這就像你讓他們掛一幅畫，但他們從來沒有幹過這樣的活。你明白你要做什麼——只要讓他們這麼做就行了。事實上，你認為有些東西不用解釋，因為你覺得它們太簡單了。所以，你讓一些新手來為你工作時，你說，“把這幅畫掛在那裡，做完了告訴我”，很好理解，對不對？但他知道應該怎樣釘釘子嗎？實際上，有很多細節他不清楚，他需要學習才能把畫掛好。另外，還有很多東西你容易忽略。

首先，是怎麼做。他需要什麼工具？你知道工具箱裡有錘子和釘子。但他不知道，他認為他有合適的工具完成任務。於是他在辦公桌上找到了一個訂書機和膠帶。

現在他有兩種方法完成任務。他可以做很多小的膠帶圈，這樣它們可以固定在牆上，然後把它們釘在畫的背面。這種方法看上去可能沒事，但是隻有畫掉下來的時候你才知道他做錯了。另一種方法是，他把一大條膠帶纏在畫上，並且把它用訂書機牢牢釘在牆上。用這種方法的結果可能更糟，雖然和你的要求差不多——畫掛好了，但是畫面被遮住了。只要有足夠的訂書釘，畫就能掛住。但是這樣太難看了，而且也不是你想要的掛法。如果你不及時制止他，他可能會繼續用這種方法掛畫。

還有一種可能的情況，特別是對那種急性子的初級程式設計師來說。當你的老闆來問你射釘槍的採購訂單時，你才發現他這樣做了。於是你叫來你的下屬瞭解情況，發現他上週一直在google上搜尋，閱讀參考書，並向討論組求助。他知道你想把畫掛在牆上的釘子上，並且認為釘釘子的工具是高階氣動射釘槍。如果他能接受你的意見，你得指出掛圖和裝修用的釘子是不一樣的，並且告訴他工具箱裡的錘子才是真正適合做這件事的工具。要是他還固執己見，就可能會有像下面這樣的爭吵了：

“為什麼不能買射釘槍？”
“因為沒有足夠預算。”
“難道就沒法做好一件事情嗎？”
“你可以用錘子釘釘子。”
“可是我們不是應該更快更好地完成工作嗎？難道我們用錘子的原因只是因為用習慣了它？眼光應該放遠點。”
“我們沒有足夠的時間證明買射釘槍是對的。明白嗎？”

最後雙方不歡而散。

現在，你覺得你把工具的問題說得夠清楚了。他也拿到了錘子和釘子，開始了他的工作。問題是，他還應該知道如何有效地使用它們。對你來說熟練使用錘子是輕而易舉的事情。但是對以前從未見過錘子的人來說，它看上去似乎只有一種用法。事實上，你可以用錘柄末端。你還可以用爪形部分夾住釘子，然後把它釘進牆裡，而不必在大力釘釘子時用手拿著釘子。

站在木工的角度來看，這似乎有點低階，但它反映了使用軟體工具時的實際問題。一個軟體往往提供很多參考文件，但範例和習慣用法卻不多。你可以買一本一千多頁的參考書，它告訴你用一個軟體可以做些什麼，卻沒有哪怕僅僅5頁內容來說明在你的實際情況下你該怎麼用它。就算你有一個例項，它們也不告訴你為什麼要用這種方式執行。讀完本文之後，你就不會再糾結釘釘子是用錘子還是射釘槍了。

我剛開始使用XML時就遇到了這種情況。我讀過的幫助文件裡這樣說過，“用SAX解析器讀取XML檔案，不要用DOM解析器。DOM解析器執行速度很慢，並且佔用記憶體過多”。後來我問過其他人，“為什麼不行呢？難道DOM解析器執行效果很差嗎？”

他說:“並非如此，但如果你只想獲得作者和標題資訊你何必載入一個10M的檔案呢？”
“啊，是這樣，我想把一個20K的檔案內容釋出為一個網頁。”
“那你還是用DOM解析器吧。”

此外，還可能會出現資料互動問題。現在你的下屬知道怎麼釘釘子了，他做的第一件事情是在畫框上釘一個釘子。

天哪！！！

“不不不，你沒看到畫框背後的繩子嗎？你應該把釘子釘在牆上，然後把繩子掛上去。”
“哦，我不知道它有什麼作用。不過你只釘一個釘子？多釘幾個不是更安全嗎？比方說釘6個。”
“用一個就足夠了，釘子多了反而不好調整。”
“為什麼要調整呢？”
“你得把畫掛正吧。”
“哦？要掛正嗎？”

唉，又沒說清楚。

現在我們開始討論更高層次的設計問題。畫應該掛在哪裡？應該掛多高？他沒法決定。如上文所說，它沒有你想得那麼簡單。

你明白畫不能掛在門邊，因為開門時會擋住它。它也不能掛在那邊，因為你要把新書櫃放在那。或許你的天花板有14英尺高，畫只是用來讓這個大房間顯得不那麼空蕩。也有可能這是你和“貓王”的合影，有人坐在你辦公桌前的時候你可以顯擺顯擺。如果它是一張老照片，你必須確保它不會受陽光直射。這些都是“業務規則”。雖然你掛畫的方式大同小異，但你必須考慮它們。

也有些業務規則會影響你的決策。如果畫比較貴重，你得想辦法把它保護好，比方說把它掛在比較難夠著的地方。如果它價值連城，你得用兩英寸厚的玻璃來保證它的安全，周圍還得裝上警報系統。要是你打算用來掛畫的那堵牆非常結實，你得用鑽頭才行。如果牆本身比較值錢，你還是暫時打消掛畫的想法吧。

這些規則可能有些道理，但它們並非那麼顯而易見。一些在某種情況下正確的方案在其它情況下不一定是對的。你只能通過你在房間裡掛畫的經驗來了解它們。另外，你還得考慮哪些規則可能改變。你確定要把畫掛在這嗎？這幅畫會被移到別處嗎？它會不會被換成另外一幅畫？新的畫和原來那幅還是一樣大嗎？

別指望新手會考慮這些。你可以適當指點他一下。你的任務是儘可能多地告訴他工作的細節。如果他聰明，好奇，他會提問，並瞭解這樣做的來龍去脈。不過這需要時間。

如果你沒有給他足夠的資訊，他會試著猜測。前面提到的急性子的程式設計師這時可能就不顧規則了。你告訴他把你的寵物狗照片掛起來，一週後他回來了，問你要不要再考慮考慮他關於石膏鋸的建議。

“你為什麼會想到石膏鋸呢？”
“辦公室的工具箱裡只有木鋸，不太適合鋸石膏板。”
“什麼？你認為只有你想鋸石膏板嗎？你可以在Home Depot上買一個鋸子。”
“那麼，好吧，我去買一把。”
“等等，你怎麼會想到鋸石膏板？”
“是這樣，我不知道掛畫最好的方式是什麼，所以我上網找了討論組裡的畫廊設計師。他們說，最好的方法是鋸穿牆壁，做出一個框架。把畫從後面放進去，這樣能夠保證玻璃的安全，因為你不必動它。而且這種方法比釘釘子更加美觀。”
“...”

這個比喻可能有些不太切題，不過請相信我——它非常有參考價值。如果你的職業生涯中還沒有遇到此類事情，你可以先看看它。

關鍵是，從細節技術層面到整體效果層面，有很多東西你必須知道。不能讓一個新手隨意猜測，不管他有多聰明。而且這和聰不聰明沒關係，一切都要根據實際情況決定。可能你和他們一起工作太久了，你忘了你也有一段時間不知道這些。但是你必須詳細地描述你的要求，方便他們提問。

---

僅僅是這樣嗎？

這讓我想起了《帝國反擊戰》中我最喜歡的場景之一：Luke Skywalker遭受了失去親人的打擊，他一直在尋找自己隱祕的身世。後來他跟隨絕地大師Yoda學習如何成為絕地武士。但是Luke想學的東西Yoda卻沒有教他。實際上，觀眾們認為，Luke似乎並不瞭解絕地武士應該是怎樣的，畢竟除了和Ben Knobi一起學習的時間，他幾乎沒有任何這方面的經驗。而他之前並不知道Kenobi是絕地武士，直到他親眼目睹Kenobi在戰鬥中犧牲。

這是這個場景中令我印象最深的畫面：
LUKE：師父，移動石頭很難，它和我以前學的完全不一樣。
YODA：不，沒有什麼不同。只是你認為它們不同罷了。你必須忘掉你所學的。
LUKE：（靜靜地集中精神）好吧，我試試看。
YODA：不，別老想著只“試試”。要麼做，要麼就別做。

而《帝國反擊戰》和上文掛畫的例子有什麼聯絡呢？

初級程式設計師們應該“忘掉”他們覺得自己已經知道的東西，然後重新學習他們需要的東西。

剛走出校園的程式設計師有兩種型別：他們要麼幹勁十足，隨時準備改變世界；要麼他們膽小如鼠，不敢抓住機會或者嘗試有風險的東西，生怕被炒魷魚。

第一種程式設計師，也是我非常擔心的一種。他們自認為他們知道要做什麼，並且在google和網際網路上搜尋他們需要的資料——他們會為了掛畫把牆鋸開。或者他們會因為射釘槍和你爭吵，因為他們覺得那是對的：射釘槍釘釘子的效率更高。實際上他們錯了，因為射釘槍沒法控制釘釘子的力量（它會把釘子整個釘進牆裡），並不適合掛畫。

另外一種就比較不幸了，他們沒法被用人單位接納。因為他們缺乏工作的主動性，所以他們沒法真正學到什麼東西。他們只能做簡單的拼寫檢查或是類似於行政助理的工作，甚至有可能一輩子都耗在HTML網頁上。他們會抱怨，厭倦這份工作，最後跳槽到郵政行業，市場銷售行業（也許更糟，做個推銷員）。不管怎樣，這對他們沒有好處。

這不得不讓我深思：初級程式設計師應該做些什麼呢？如何讓一個程式設計師從入門到精通？初級開發人員應該怎樣避免向這兩個極端發展呢？

結論就是：初級程式設計師們必須學會“問”。問了，就必定會有收穫。

看看急性子的初級程式設計師的例子：如果他敢於發問，“老闆，我從來沒掛過畫，我該怎麼做？”，就不會有射釘槍、膠帶、石膏鋸這樣的問題了。作為一個過來人，你應該知道他沒有你那麼經驗豐富。

老手們沒法瞭解新手們不會什麼。但是幫助他們意識到“哪些不會”是非常重要的。這種關係就好比之前提到的絕地大師和絕地學徒之間的關係，也可以說是西斯領主和西斯學徒的關係，或者是千百年來人類歷史上的各種師徒關係。

最關鍵的一點呢？

從某個角度來說，我們都是初級程式設計師。就算你有四十年各平臺和嵌入式系統的C++開發經驗，但涉及到關聯式資料庫（或是Nosql，或是Java和JVM，或是C#和CLR）的時候，你就是一個初級程式設計師。再換句話說，關於原力和拯救宇宙（包括一個後來你才知道是你妹妹的漂亮女孩）的絕地武士，你依然是個新手。

現在你知道該怎麼做了。

為你自己找一位老師（也許現在更準確的說法應該是“導師”），向他們學習或是提問是非常有用的。然後，反過來，讓你的同事或是朋友中的初級程式設計師也這麼做；他們不一定會接受你的幫助，但仔細想想，你在這個年紀的時候，不也希望有一位大師來教你嗎？

你是想成為愛抱怨的Luke Skywalker還是想成為絕地武士Luke Skywalker呢？Luke失去了一隻手之後才明白Yoda遠遠比他聰明，應該多請教他，而不是告訴他“你做錯了”。

如果你不想讓專案出錯，還是老老實實承認自己不是無所不能吧。如果你想讓你的專案更加出彩，不妨考慮一下我的建議。

原文連結：http://blogs.tedneward.com/2012/03/21/Unlearn+Young+Programmer.aspx