成爲高效程序員的7個重要習慣

做爲軟件工程師，你但願從工做中得到的是：穩定的薪水、參與好項目的機會、好工做的跳板或只是和其餘程序員成爲好基友。這裏的「高效」，我指的是按時完符合要求的項目的能力。經歷過很多軟件編寫工做後，我相信如下實踐會幫助你學會「高效」，同時提升專業聲望、拉長職業壽命，和得到我的知足

　　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條線程(我能找出的)時，他贊成不該該保留這麼多線程，而且最好修改一下。但他仍是按老樣子編寫代碼——他沒有修復任何漏洞，他只是用更多代碼掩蓋了漏洞。

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

來自：http://www.yixieshi.com/zhichang/14061.html