1.理解你的需求

成為高效程序員的第一步是，保證時間的合理分配。沒有什么比將時間花在完全沒有前途的工作上更浪費的了。

盡快開工

盡快完成一個直觀的系統。這意味著先創建界面，無論是程序界面還是用戶界面，然后生成內部功能的存根代碼（如果有必要的話）。這么做便于“客戶”查看，通過執行用戶界面或編寫程序界面的代碼，可以發現最初代碼存在的矛盾或遺漏。甚至在第一次交付以前，你有可能會注意到問題或可改進的地方。

有一個經典觀念認為，如果你提前設計好所有東西，那么之后你要做的就只剩寫代碼了。如果你之前做過完全相同的項目，那么這個說法當然正確。但如果不是，你很可能會陷入死角，也就是你只是在猜想或執行一個可疑的假設。

很早以前在一家無限網絡的新公司工作時，我們開了兩個月的會來設計一個將在6個月內發布的無線門戶和網關。最終，我們厭煩了開會，開始編寫代碼。頭兩周內，我負責的部分與原始設計不符，兩個月后的第一個無線連接測試表明，我完全誤解了無線協議。

這不是說設計是沒必要的。但在一定程度上，設計只是一種猜想。設計應該通實執行來確認，并且早執行總是比晚執行好。

即使原始設計是充分的，只要你發現可以調整的地方，你就要改進它。硬件產品、建筑和大型軟件項目等會受到僵死的“預制”的損害，但對于軟件，你可以在項目早期提煉項目要求，然后制作適合的界面。但是，這必須盡早完成。

盡早開工有利于樹立你的職業形象。如果能向你的老板展示一些成果，他會很高興的。另一方面，提早開工有助于緩解焦慮。

經常交付

一旦你完成一些可用的東西了，不要只是把它留作“概念實證”。要讓其他人試執行它、看看他們的反應，然后讓它指導開發過程的優先次序。觀察人們如何使用你的軟件，這是無可代替的方法。客戶問卷調查和焦點研究可能會提供一些有用的意見，但有可能會讓開發者的設計決定和特點被客戶牽著鼻子走，這是一種冒險。

特別是要盡快將軟件交付QA人員，經常提交成果，最好是按預定的時間間隔。讓他們測試每天的成果，或至少是每周的成果也是好的。這會讓QA人員覺得自己全程參與項目開發，從而培養職業責任感，更樂意發現和報告問題。最需要優先解決的是導致產品失效的問題，如崩潰或死循環——讓問題盡可能涵蓋多方面，熟悉整個產品，這樣才有可能提早發現設計問題。

在一個小型3D軟件公司，我負責移植從SGI出品的龍頭產品到Windows NT。6個月后，移植沒完成，倒有了崩潰的傾向，我很不情愿地將第一輪成果交付測試團隊。幸運的是，因為漏洞太多，QA經理堅持要我立刻解決導致測試

人員無法有意義地使用程序的問題。如果是我自己測試，我應該會忙于看起來更困難更重要的核心3D問題，可能會怠慢看來起比較普通的問題，如用戶界面、載入-保存功能和與計劃支持的硬件之間的兼容性。

程序師常常不想過早將代碼交付測試人員——他們不想聽到自己已經知道的漏洞；而測試人員極有可能不想測試基本上行不通的東西。但測試人員的工作就是找到這些問題。如果程序師想盡快看到成果的話，應該把漏洞報告當成好東西。

2.把工作當真

將軟件放在盡可能接近完工的狀態下運行。你永遠不知道你什么時候得演示系統、發送評估備份或甚至交付。

使用真實數據

如果你只用作為著冰山一角的樣本數據作測試，那么，你的程序可能一撞上真實數據的大冰山就沉了。

我曾參與開發一種用于評估先進的半導體絕對值的供應鏈管理產品。跨過交付這道大坎后，我們接到消息說他們輸入的第一批真實數據仍然在處理中——已經兩天了。我同情主程序師，他不得不在管理人員和客戶的催促之下忙活了兩周。很高興遇上這事的人不是我。

使用正式版本

記住，用你自己的機器創建的東西不是正式的。

在最近的一個游戲開發項目中，我負責用戶界面，我陸續從QA那接到報告說有些顏色不對。最后，我發現問題只出現在交付版本中，另一位程序師使用專門的主機調試工具找到了漏洞。結果竟是一個我在兩個月前犯下的愚蠢錯誤，沒有指定初始顏色值。調試版本總是選擇特定的默認值，但是交付版本會更改，最終結果是不太確定的。如果我注意經常地運行交付版本，我會立刻發現問題的，而不是損失大量的時間。

經常合并

及時將你的代碼并入主代碼庫中——你拖得越久，這項工作就越累。

我曾與一名程序師共事，他覺得每天數據庫中出現的所有新代碼和數據變化都“很麻煩”。確實，這讓所有其他程序師每天都要花一定時間合并，他才能夠只掃視一下代碼和數據就開始運行一些不錯的獨立樣本。但每一次階段性交付時，我們都要花好幾天再次把單獨的代碼接到當前的代碼庫中，有時候甚至得拖延交付或冒著損失整個項目的風險。

將你的代碼與正式版本分開意味著程序師不能評估你的代碼，以及測試員不能盡早發現漏洞。可能你并不想其他人挑剔你的代碼，但早發現問題總是比晚發現好的——所以，忍了罷。

3.理解你的代碼

生活中充滿了奇妙的神秘，但你的代碼可不適合出現這些神秘。你不必知道你的車怎么工作的——如果引擎發出奇怪的聲音，把它交給汽車技師就好了。但換成是你的代碼，如果連你都不知道它是怎么運行的或出了什么錯，那就沒人知道了。

有自己的編寫風格

我童年時的鋼琴教師是這么評價我和我姐姐哥哥的：“你姐姐的時間感強，你哥哥的鍵盤打得不錯。”然后他停頓了一下說：“你嘛，嗯，你很努力。”

編程是一種有些人能做有些人不能做的事，但還有一些人則是天才。雖然我有過多年的練習，鋼琴還是彈不好；雖然我那么喜歡打球，水平仍然一般般。但我確實認為我有編程和寫作的天賦。不要吃驚，我認為好程序就像好散文。散文和代碼都是文本，有語法、句法、拼寫和語義。對于大多數寫代碼的人和寫作的人，有這些就夠了，但好作家和好程序師還要有一種美感，他們的作品在結構和風格上是有特點的，往往能借此識別出作者。

許多Windows程序師都感到好奇：為什么壞脾氣的老Unix/Mac/Amiga/Lisp程序師對Win32/MFC/.NET很不滿，但如果所有應用界面都來自Microsoft，你可能就不知道還有什么東西是更好的。

復制粘貼

風格化編程的反面是復制粘貼。從什么地方復制一些可能有用的代碼，稍作調整，合并，重復，然后就大功告成了。你的軟件簡直就是大雜燴。

離開一家公司的幾個月后，一位前同事電郵問我，他復制粘貼了十頁的代碼組成一個算法，為什么運行不了。我實在不知道怎么回答了。如果你不能解釋你自己的代碼應該是怎么運行的，你還指望誰來拯救你？

我甚至在診斷自己從樣本代碼復制粘貼過來的代碼時也犯過難。從復制粘貼開始新代碼是合情理的，但你不能因為看起來能運行就放手不管了——你得返回去看看你是否讀懂了每一條，根據自己的目的理清代碼。

清理代碼

保持你的房子/公寓/房間整潔的最好辦法就是每天花一點時間清理它，或至少每周清理一次吧。如果等到住所亂到一定程度才打掃，那么這麻煩就非常大了。除非你雇個清潔工。

假設你沒辦法奢侈到雇一個人每天幫你清理代碼的程度，那么你就應該定時地檢查你的代碼、清理累積的死代碼、淘汰過時的注釋和錯誤的名稱，否則你必定會得到一份不敢拿出來見人的代碼。如果你不覺得丟不起人，好吧，你行。

我指導過的一名程序員總是向我報告，她的代碼“完成”了。這是管理者樂意聽到的話，卻讓我非常抓狂。她的代碼從來沒有做完——你得調試它、維護它、改進它，直到它徹底沒問題。

問題？注釋？

有些人認為編程是一門手藝活，也有些人認為編程是一項工程。更經常的是，它是一門考古學。你挖掘代碼的沉積物，想知道這些奇怪的人工產品是用來干什么的。為后來人著想一下，留點線索吧。

我問之前提到的那位程序員“完成”注釋了沒有。結果是，一個函數名稱為“GetData”的注釋居然是“Gets data”。這不只是廢話——簡直是侮辱。什么數據？什么格式？來自哪里？更不要提像服務器不可用或傳送中斷時會怎么樣這種小細節了。

將你的代碼做成文檔，以防有人隨時要拿來用。可能要用的人就是你本人——想想如果不這么做，你得重新訪問代碼多少次啊？

與之前的一個老板合作時，他叫我瀏覽一段沒人有時間看的代碼。一開始，我認為它很糟，不知道寫的都是什么東西。之后我慢慢摸索出來這段代碼是干什么的，所以我勉強同意它不算太糟。最后我終于認出這貨竟是我兩年以前寫的。教訓：多留點注釋。

當你寫代碼時，記得注釋，而不是等著出現什么方便的清理短語——注釋你的代碼，讓它甚至可以清楚地反映你在編寫時的想法。你可以成為自己的編寫伙伴。

現在你可以用javadoc和doxygen等生成漂亮的HTML或來自源代碼注釋的其他格式化的文件。理想的情況是，你每天晚上做的就是doc生成的部分，可以通過你的內聯網獲得。

注意警告

無視編輯器和運行時間警告會害到你自己。有“警告”就有原因。

我曾做過一個基于Unix的應用，它不能成功地連接某些函數。我們通過在運行時再次連接這些函數解決問題。六個月后，當我們執行一個干凈的新版本時，我們才發現原來我們關掉了能提醒我們未知連接漏洞的警告。在供應商的斥責下，我們將連接問題解決了。但結果是，原來我們只要通過重新排列庫就能連接上了。

提高編輯器的警告水平，注釋代碼以及記錄創建和運行時間的警告信息，最好包括解決警告的標準，這樣你就會知道是否解決問題或忽略問題。

4.優化編程

帶著目的寫代碼

復制粘貼代碼的人的另一個極端是，只是為了讓代碼看起來更漂亮（至少對他們而言）而改變代碼。雖然有編程審美感是值得贊揚的，但改變代碼以便讓你覺得漂亮只是浪費時間（無用的冒險）。瀏覽并改變別人寫的代碼，讓它看起來更漂亮，真是讓人生氣。

我有一個挑剔的同事，瀏覽我們的代碼庫時將所有的附加語都刪除了。如果他只是清理了入門級員工寫的代碼，那可能沒人會說什么，但那些附加語是我們團隊的技術領導寫的，他可是我們公司最出色的人物之一。

不要搞破壞

“代碼重構”現在十分流行，但程序員往往以為它是指代碼清理或重新設計。這個技巧是指重新組織代碼，同時不破壞其他東西。如果你以改進的名義破壞已經存在的功能，那么你的意思就是：要么你的時間比其他人的時間金貴，要么你不破壞就不會整代碼。

我有一個特別討人嫌的同事，他決定重新執行我們系統中的解析器，但結果讓代碼變成其他所有人都不知道怎么寫了。我讓他恢復原狀，之后發現代碼能編寫了，卻不能運行了—–問他怎么回事，他說“應你的要求”，他移除了整個解析器。真沒團隊精神。

保持代碼運行需要一些耐心和額外的工作——你勤奮地回歸測試你的工作，在將函數添加到新代碼中時，你可能需要暫時留住老代碼和界面。但對于所有與這個代碼庫有關的人來說，這是必須做的。

找到瓶頸

人們總是談論“最佳”，但這不是一個正確的詞。我們極少將最佳作為目標——相反的，我們的目標是改進和權衡以達到足夠好的表現。

在谷歌的電話面試時，我被問到如何在一組有序的數字中搜索某個數字。顯然，提問的人是在問二進制搜索法。但在現實生活中，我可能會做出“錯誤”的選擇——從頭找到尾。如果程序表現足夠好了，還花兩倍的時間寫兩倍的、必須維護和調試的代碼，那是毫無意義的，特別是如果那段代碼并非程序的瓶頸（我嚴重懷疑如果那個數據是瓶頸部分，你居然還會將它線性排列）。

如果你確實需要在程序的速度或空間方面達到最佳，折騰除了瓶頸以外的其他任何部分都只是浪費時間。

5.自我管理

你可能對你那位討厭的老板有各種抱怨，你的抱怨可能沒錯。所以你得成為你自己的管理者。即使你的老板人不錯，他也不會站在你背后告訴你該寫什么、怎么寫才會快（盡管我肯定許多老板恨不得這么做）。

估計時間

程序師不能提供有用的時間估計，這是出了名的。但我認為這是無理指責，因為管理層往往作出更差的預測，并且程序員的警告往往被無視（這可能是所有工程的共同災難）。但是，合理的時間估計對于按時完成項目仍然是關鍵的。

在一個商業軟件項目中，我的有些同事居然樂得忘了產品交付日期——有人問是否已經交付了，另一個人才很驚訝地發現，日子已經過去好幾天了。

更糟的也更普遍的是，程序員能給出的時間估計是“只需要幾天。”每次我聽到這話，或者我自己說出這話，我都感到害臊。

一家圖像軟件公司的總裁想讓產品支持VRML（那時它是下一件大任務），包括我們將在兩個月內發行的產品也支持VRML。他可能想到（他是正確的）我會拒絕開始新項目，所以他問了另一個工程師，得到了他想到的回答：“只需要幾天。”兩天后，我告訴總裁，我們剛剛浪費了他和我的兩天時間，因為有兩百多個更重要的漏洞要修復，他認為我的理由算是充分。（后話：VRML沒有太成功。）

另一位程序員完全沒有時間估計的概念。但沒有必要完全拒絕時間的模糊屬性——畢竟只是估計，事實上你應該避免太確切。如果你是一名有經驗的工程師，你就知道你以前做類似的工作需要多長時間，如果你不是，那你就問問有經驗的人。

我有一個聰明的朋友，經常被指派去開發實驗原型，他問我：“你怎么估計時間？”我認為這是一個反問句，但甚至純研究人員也要估計時間。有人支付他們，希望得到結果，即使它是許多演示樣本或某段時間發表的文章。

如果你確實估計不準需要多少時間，那么你就不是做這項任務的合適人選。

有時候程序師不情愿承諾時間是因為他們害怕保證。確實，這個世界沒那么美好，經理會在時間上跟你討價還價，競爭對手可能用嚴苛或不切實際的安排來擠兌你，希望你失敗。在你承諾時間后，你就悲劇了，你別想得到任何你希望的結果。

我曾有個老板問完成時間后會追問一句：“你保證？”但問他硬件條件和其他相關事宜時，他會說：“我盡量。”

我能說的只有，抓緊時間以及給出現實估計。任何讓步都應該根據實際的介于產品和資源之間的交易。要根據假設、相關事宜和資源做時間安排，找個地方寫下來，這樣以后你就不用麻煩你不太給力的記性了。

計劃進度

在決定上哪去以前，你不會跳上車的，對吧？你在開車時心里可能就有路線了。相同地，在你開始用電腦寫以前，你應該知道你今天想完成什么，有一些想法了。

每天都會遇到分心的事，所以你不可能總是完成你想完成的事。與那些將軟件工程團隊當作自動販賣機的人的想法相反的是，有些任務不是一天就能完成的。所以想想你到周五要完成什么，如果你完成了，那么周末你就可以好好過了。

6.不斷學習

一名社團足球隊成員曾經問我，我們每天束緊防滑釘練習，你們“C語言編程的秘密是什么？”如果存在這樣的秘密的話，我肯定會在晚間電視節目上宣傳如何靠房地產發財。對不起，沒有捷徑——你必須學習、練習和犯錯。你不一定得依靠團體訓練或學校教育——有許多國立的和當地的專業團體、書籍，當然還有網絡。

編程是科學

編程被稱作“計算機科學”是有原因的。無需正規的計算機科學教育，任何人都可以輕易地開始編程（可能太容易了）。特別是，那些學過其他工程和理科的人，可以非常快地上手編程，然后以此謀生。但對于高效地處理重大任務，你必須知道軟件的固有功能和限制、識別前提，這樣你才不會白費力氣地做重復的工作。你不必知道所有事，但你應該至少粗略地了解許多領域，必要時能做一些額外的研究。

例如，創建了新文件格式的人應該知道一些關于編輯器的事。我不是指所有代碼生成的優化如循環展開，而是基本的問題和各種編輯的短語和大部分指定標記和語法的重要性。今天，大多數人會默認地使用XML，那是件好事，

但在那之前，一般是粗略地寫一些文本格式，指向一些生成的樣本文檔作為文件，之后其他寫了另一個解析器的人會補上一些在文檔中閱讀的東西，但不是全部。在出了差錯的情況下，你有兩種方式推卸責任——要么讀者不行，要么作者太差。無論怎么樣，更受歡迎的產品會贏。

我對3D圖象行業最不能容忍的事情之一是，過多的文件格式不明。當我執行一個3D作品的OBJ文件解析器時，我測試的每份導出作品都生成明顯不同的文件，比如空白和換行不同。與之形成對比的是，我的一個初出茅廬的同事用語法和詞法分析器設計了一個新游戲交換格式（現在，這不再是什么大不了的事了—-大多數新圖象文件格式好像都是基于XML的）。

只會將簡單的腳本和用戶界面放在一起的程序員和可以處理實際問題的程序員，如果說這二者有什么區別的話，那就是對復雜計算的理解能力，如算法怎么影響問題的大小。每一位程序員都應該知道基本的復雜性術語和對常見問題的復雜程度有常識性認識。

我的第一份工作是計算機輔助半導體設計，涉及許多可擴展性的問題，包括一些NP-complete問題（非常難處理）。但是，每次看到在線性時間中不能解決的問題，和我們自夸可能意味著大部分是線性時間的“線性”算法，有些工程師會興奮地說：“這是旅行商問題！”（游戲邦注：旅行商問題，即TSP是一個有著重要工程背景、在圖論中的典型組合優化問題，已被證實是一個NP完全問題。也就是，如果一個旅行商不得不到幾個城市做生意，怎樣走最短的路線使他一次到達這幾個城市。）

免費啤酒、自由討論、免費軟件

好吧，其實沒有免費啤酒；但現在程序員過得還不錯（盡管經濟衰退和外包業惹爭議）——畢竟你需要的東西網上教程、討論組上都有，還有免費軟件可以用。你要解決的只有硬件和寬帶問題。

7.尊重

高效軟件工程師的要求之一是，被認真對待。你必須得到你的同事和老板的尊重，至少出于你的技術能力、對自己的工作有主導權、對他人有一定影響力。

愚蠢問題

真的，這個世界上存在許多愚蠢的問題。提出一個聰明的問題會增加別人對你的尊重，但這是一項技術活。一個揭露未解決的事的好問題會讓別人看到你深刻的內涵，你敏銳的思維。要求說明關于技術參數的問題，顯示了你閱讀和發現問題的能力。

如果你的問題沒有得到答案，可能是問題本身有誤，所以不要再重復發問了。換一種方式提問，帶上更多細節或背景。如果被提問的是你或花時間回復新手問題的是你，你會感謝上述考慮的。

能與技術支持人員保持良好關系，這是讓我對自己都感到驕傲的事。但我確實記得一件往事，那時我拋出一個問題：“幾周前提出來的那個問題是怎么回事？”你可以想象別人是多么惱火地回答——“你說的怎么回事是指什么，并且，你說的是什么問題？”

粗魯無禮是沒有回報的，特別是如果你是要求免費指導或咨詢討論組。即使你是在支持協議的保護之下發問，激怒了你的技術顧問對長期合作也會很不利。

我曾經向臭脾氣的新人們解釋為什么他們的問題有問題或者什么是他們從一開始就做錯了的，真是太累人了。現在，我給你快速生效的傻瓜過濾器——“我想知道的只是……”或果斷無視。

讓所有人知道你讀了文件和谷歌搜索了該問題。除了避免回復必然的“RTFM”（游戲邦注：RTFM意為：去讀該死的指導手冊。當你需要信息或者解決問題時，在請求對方幫助之前，應該花一些時間嘗試自己去尋找需要的東西。）和“Google is your friend”，都顯示了你做足了功課，那些幫助的人不必搜索相同的資源。如果你確實指望他們為你搜索那些資源，那你的意思就是，你的時間比他們的金貴，你在謀殺他們的時間。

白癡答案

如果你要表現得你知道自己在說什么，那么你確實應該知道你到底在說什么。工程師的交流有時候更多地是炫耀自己的知識而不是提供信息（如果你也能這么做，那我向你致敬）。這往往無益于求職面試，面試官其實是假借“發現你是怎么想的”的幌子，向求職者拋出空洞的問題。當然，如果求職者有一點自知之明的話，也可能產生出乎意料的結果。

有一位技術總監打電話面試我，要我概述C++編輯的結果堆棧框架，并且口頭答復他。我一步一步地打草稿，每次我給他正確的答案，他都反過來要我說一個錯誤的答案，以便我們可以仔細檢查為什么那個選擇不管用。我不知道我這么寫是不是在彰顯我有多聰明或他有多聰明。

作為一名工程師，你不能太倚重錢財和長相——信譽才是你的資本。所以如果你犯錯了，就坦率承認吧。

我有幸與一名資深工程師共事，他從來不犯錯。當他的Java代碼在多重處理器系統中崩潰時，原來是出現了大漏洞。當我拿代碼指出UI代碼不支持多線程運行時，他堅持說只有一個線程。當我列出代碼中的7條線程（我能找出的）時，他同意不應該保留這么多線程，并且最好修改一下。但他還是按老樣子編寫代碼——他沒有修復任何漏洞，他只是用更多代碼掩蓋了漏洞。

最后，一個節省時間的建議：不要糾結于愚蠢的爭論。愚蠢是會傳染的。