1.在怪罪其他東西之前先檢查自己的代碼

質(zhì)疑一下你自己和他人的預設情況。來自不同供應商的工具，可能內(nèi)置有不同的預設，也有可能相同的供應商提供不同的工具。

當有人想你報告一個你無法重復的問題之時，去看看他們做了些什么。他們可能會做一些你沒有想到的事情，或者是按照不同的順序來做那件事的。

我的原則是，如果我遇到一個我無法避免的bug時，我會首先考慮是編譯器的錯誤，然后我就會去檢查堆棧是否被破壞了。這可以通過跟蹤代碼來實現(xiàn)，可以有效地移除問題。多線程問題是另一個絞盡腦汁也不容易找到的錯誤來源，通常還伴隨著機器的錯誤。當一個系統(tǒng)使用多線程的時候，所有的簡單的代碼的錯誤都會成倍地增長。不能依靠調(diào)試和單元測試去發(fā)現(xiàn)這樣的兼容性問題，所以簡單的設計是最重要的。

總之，在你怪罪你的編譯器之前，請記住福爾摩斯的忠告：“當你把所有的不可能都排除了，那么剩下的東西，無論他有多么的不可能，都必定是真相。”Dirk Gently也說了類似的話。

——Allan Kelly

2.持續(xù)學習

我們生活在一個有趣的時代。隨著全球化的發(fā)展，你要知道有大量的人都能勝任你的工作。你需要不斷地學習，以維持競爭力。否則，你會成為一個落伍的人，永遠做著相同的工作，直到你不再被需要，或者這個工作被廉價外包給其他人的那一天。

因此，你打算做些什么呢？有些大方的老板會提供訓練來拓寬你的技能。而其他的公司并不會給你空閑的時間和金錢去做任何的訓練。所以為了工作的穩(wěn)定，你需要為自己的教育負責。

這里是一些讓你持續(xù)學習的方法清單。其中許多都能夠隨便在網(wǎng)上找到：

• 閱讀書籍、雜志、博客、Twitter和其他網(wǎng)站。如果你想對一個目標進行更深入的研究，考慮添加一個郵件列表或新聞組
• 如果你真想專注于某一種技術，那就動起手來——寫一些代碼
• 成為行業(yè)的頂尖人物可能會妨礙你的學習，你得盡量與導師合作。雖然你可以從任何人那里學到東西，但是從那些比你更聰明或更有經(jīng)驗的人那里你能夠?qū)W得更多。如果你不能找到一個導師，那就繼續(xù)去找
• 使用虛擬的導師。在網(wǎng)上找一些作者或者開發(fā)人員，他們寫的東西你都會喜歡并且都會看的。訂閱他們的博客
• 了解你所使用的框架和庫。知道了他們是如何工作的，你使用起來就更得心應手。如果他們是開源的，你就很幸運了。使用調(diào)試器來單步執(zhí)行，去觀察他們內(nèi)部是如何運作的。你將會看到那些真正聰明的人所編寫和審閱的代碼
• 當你做錯了或者是在修復bug，或者是碰到一個問題的時候，嘗試去深入了解到底發(fā)生了什么。有可能其他人也遇到了同樣的問題，并且把2他發(fā)布在了網(wǎng)上。Google這時候就非常有用了
• 學習一樣東西的一個好方法就是去傳授和談論它。當人們想要聽你講解并且想問你問題的時候，你就會更加積極地去學習。在工作中使用lunch-’ n’-learn方法，可以是一個用戶組或者是一個本地的協(xié)會
• 加入或者創(chuàng)辦一個研究小組（社區(qū)的模式）或本地用戶組，可以研究你們感興趣的語言，技術或者是法律
• 多去參加會議。如果你不能去，很多的會議都會把內(nèi)容免費發(fā)布到網(wǎng)上的
• 想要長期通勤？聽一下博客吧
• 你是否曾經(jīng)在一個代碼庫上運行一個靜態(tài)分析工具或者在你的IDE里看到一些警告？弄明白他們報告的是什么，為什么要報告
• 遵循高效程序員的建議，每年學習一門新的語言。至少學習一門新的技術或者是一個新的工具。弄一個分支出來添加上你的想法，以便你能夠在你目前的知識庫里使用
• 并不是你應該學的每一樣東西都必須跟技術有關。學習你工作領域的一些東西，能夠讓你更加了解需求，并且能夠給幫助你解決一些商業(yè)問題。學習如何提高工作效率，學習怎樣更高效低工作是一個不錯的選擇
• 返回學校

如果你有《黑客帝國》里的尼奧那樣的能力就好了，能夠直接下載我們需要的東西到大腦里面去。但是我們并沒有，所以必須花費一定的時間去學習。你不必每時每刻都在學習。一點點時間足以，比如一周一次，有總比沒有好。我們總得有一些工作之外的生活。

科技發(fā)展如此迅速，我們不要被甩在后面了。

——Clint Shank

3.不要害怕破壞

每一個具有行業(yè)經(jīng)驗的人無疑曾在一個充滿不穩(wěn)定性的項目中工作過。這個系統(tǒng)是很難重構(gòu)的，通常改變一個地方就會觸及到另一個不相關的地方。每當要添加一個模塊的時候，程序員的目標都是盡量少改動，在每一個版本中都是小心翼翼的。這就和把建造摩天大樓當做搭積木一樣，容易造成災難。修改對的時候是非常傷腦筋的，因為系統(tǒng)已經(jīng)生病了。它需要一個醫(yī)生，否則狀況就會越來越差。雖然你已經(jīng)知道了你系統(tǒng)發(fā)生了什么錯誤，但是你還是害怕“打破雞蛋去煮你的煎蛋卷”。一個熟練的醫(yī)生知道，為了做手術就必須開刀，而且她也知道開刀只是暫時的，而且很快就會愈合。對于最初的疼痛來說，做手術是非常有價值的，患者通常都會獲得比做手術前更好的狀態(tài)。

不要去擔心你的代碼。當你在做事的時候如果暫時被打斷，誰會去擔心呢？對改變的恐懼會讓你的項目將進入這樣的狀態(tài)。花一些時間去重構(gòu)項目會讓你節(jié)約很多的時間。還有一個額外的好處就是一個團隊面對這個損壞的系統(tǒng)的處理經(jīng)驗會讓你們明白該怎樣才能讓它正常工作。要學會運用這些知識，而不是抵觸他們。每個人都不應該把時間花在自己所討厭的東西上。重新定義內(nèi)部接口，重組模塊，重構(gòu)、復制、粘貼代碼，并通過減少依賴來簡化設計。你可以通過消除極端情況來減少代碼的復雜度，他們通常會產(chǎn)生不當?shù)鸟詈闲浴Ｂ貙⑴f架構(gòu)過渡到新的架構(gòu)，邊改邊測試。試圖在一個可能產(chǎn)生很多問題的大項目上進行一次大的重構(gòu)，這些問題可能慧然你在中途就放棄之前所作的所有的努力。

作為一個醫(yī)生，是不應該害怕切除患病的部位，以留出愈合的空間。態(tài)度是會傳染的，并且會激勵其他人去對那些一直拖延著的項目進行修改。去列出一個團隊都感覺良好的項目的清單。雖然這些任務可能不會產(chǎn)生明顯的效果，但你得去說服管理層，他們就會減少開支，加速對新版本的開發(fā)。永遠不要停止關心代碼的總體“健康度”。

——Mike Lewis

4.做專業(yè)的程序員

一個專業(yè)的程序員最重要的特征就是個人責任感。專業(yè)的程序員會對自己的生涯、自己的估計、自己的日程安排、自己的錯誤以及自己的作品負責。一個專業(yè)的程序員是不會把這些責任推給其他人的。

如果你是一個專業(yè)人員，那么你就會對自己的工作負責。你有責任閱讀和學習。你有責任追趕業(yè)界及技術的潮流。而很多程序員都認為這是他們上司的工作。對不起，這是大錯特錯的。你認為醫(yī)生也會那樣做嗎？你認為律師也是那樣的嗎？不是的，他們會利用自己的時間和金錢去學習。他們花費大量的下班時間去閱讀期刊和做出計劃。他們會時刻更新自己，我們也必須這樣做。你和雇主之間的關系只是為了履行合同。總之：你的雇主承諾給你工資，你就得承諾去把這份工作做好。

專業(yè)的程序員會對他們編寫的代碼負責。如果他們不清楚代碼是否會正常的工作，就絕不會輕易放出代碼。試想一下，如果打算放出一個不確定的代碼，你還有可能是一個專業(yè)的程序員嗎？專業(yè)的程序員都不希望QA來發(fā)現(xiàn)他們的錯誤，因為他們?nèi)绻唤?jīng)嚴格測試是不會放出代碼的。當然，QA也許會找到一些問題，因為沒有什么是完美的嘛。但是作為專業(yè)人士，重要的是我們的態(tài)度，我們決不能讓QA找到什么問題。

專業(yè)人士都是團隊合作。他們會對整個團隊的未來負責，這并不是他們個人的工作。他們互相幫助，彼此教導，互相學習，甚至包括別人需要的任何時候。當一個隊友倒下，其他人都會去關心，因為他們知道他們都有互相需要的時候。

專業(yè)的人士是不會容忍一大串bug列表的。一個巨大的bug清單是非常粗心的。一個在問題跟蹤數(shù)據(jù)庫里有成百上千問題的系統(tǒng)是粗心釀成的悲劇。事實上，在大多數(shù)的項目中，如果非常依賴問題跟蹤系統(tǒng)，那么他們肯定總是粗心大意的。只有非常大的系統(tǒng)才可能會又這么長的bug清單，這個時候需要的是自動化的管理。

專業(yè)人士不會把事情弄得一團糟，他們會對自己的工作引以為豪。他們保持代碼的整潔，結(jié)構(gòu)的良好，而且便于閱讀。他們跟隨著默認的標準而且做出了很好的實踐。他們永遠不會趨之若鶩。假設你能夠在醫(yī)生給你做開放式心臟手術的時候靈魂出竅。這個醫(yī)生有一個最后期限（只是字面意義上的）。他必須在心肺循環(huán)功能損失過量血細胞之前完成。你覺得他該怎么做？你是想要他們像典型的軟件開發(fā)人員那樣匆忙而且混亂嗎？或者想要他們說“我待會兒再回來解決”？還是你要他們小心地遵循著紀律，抓緊時間，相信他自己的做法是目前可以采取的最好的方法。你是想要一片混亂還是專業(yè)精神呢？

專業(yè)人員得有責任感。他們會對自己的事業(yè)負責。他們會對代碼的正常運行負責。他們對自己工作的質(zhì)量負責。即使最后期限迫在眉睫，他們也不會放棄自己的原則。事實上，當壓力越來越大的時候，專業(yè)人員甚至會對這些原則要求得更緊，因為他們認為這是對的。

——Robert C. Martin (Uncle Bob)

5.利用代碼分析工具

測試的價值是在他們編程之旅的早期階段就灌輸給開發(fā)者的。今年來，單元測試，測試驅(qū)動開發(fā)，以及敏捷方法的興起都被大量地用于開發(fā)周期的每一個過程。然而，測試只是眾多能夠提高代碼質(zhì)量的工具之一。

回到早期階段，當C語言還是一個新興的技術的時候，CPU的時間和存儲的形式都是非常珍貴的。第一個C語言編譯器注意到了這一點，所以通過一些語義分析減少了便利代碼的次數(shù)。這意味著在編譯階段，只能檢測到一小部分的錯誤。為了彌補這個，Stephen Johnson編寫了一個叫做lint的工具，這個工具能夠取出你的代碼中的一些冗余，實現(xiàn)了在其相似的C編譯器中已經(jīng)去除的靜態(tài)分析。然而，靜態(tài)分析工具，會增加大量的無用警告或者是一些關于文體問題的不必要的警告。

 當前，語言、編譯器和靜態(tài)分析工具的情況是非常不同的。內(nèi)存和CPU時間現(xiàn)在也變得非常的便宜，所以編譯器能夠承擔更多的錯誤檢測。幾乎每一種語言都至少擁有一個工具來檢查違規(guī)的格式和常見的問題，不過有時，那些隱含的錯誤并不會被檢測到，比如潛在的空指針引用。對于更復雜的工具，比如針對C的SPlint，針對Python的Pylint，都是可配置的，也就是說，你可以通過一個配置文件選擇這個工具在命令行或者是IDe里要發(fā)出什么錯誤和警告。SPlint甚至會讓你在注釋里注釋你的代碼，以給別人更多關于程序運行的提示。

如果一切都失敗了，你發(fā)現(xiàn)你自己正在尋找一些你的編譯器或IDE或lint工具沒有捕獲的簡單的bug或者是一些違規(guī)行為，你就得收起你所有的靜態(tài)分析工具。這并不像聽起來那么困難。大多數(shù)編程語言，尤其是那些聲稱是動態(tài)的語言，都會把他們的抽象語法樹和編譯工具作為其標準庫的一部分。去了解你正在使用的這個語言的開發(fā)團隊的標準庫的細節(jié)是非常有意義的，因為這樣你就能發(fā)現(xiàn)一些有價值的東西，這對于靜態(tài)分析和動態(tài)測試是非常有用的。比如：Python標準庫包含了一個反匯編程序，它會告訴你生成一些編譯程序和目標程序的字節(jié)代碼。這對編譯器作者python-dev團隊來說貌似是一個不起眼的工具，但是它實際上在日常工作中發(fā)揮著不同尋常的作用。這個庫能夠反匯編出來你最后一次堆棧跟蹤的信息，這會給你恰當?shù)姆答仯驗樽止?jié)碼指令會把最后一次未捕獲的異常扔在那里。

所以，不要把測試放在質(zhì)量保證工作的最后，利用好分析工具，不要害怕把自己的錯誤展示出來

——Sarah Mount

6.和你的朋友一起使用Ubuntu哲學

所以很多時候，我們獨立地編寫代碼，這些代碼反映了我們個人對問題的理解，也反映了一個非常個性化的解決方案。我們可能會是團隊的一部分，但是我們?nèi)匀粫仟毩⒌模驗檫@是一個團隊。我們很容易忘記這些獨立編寫的代碼會被其他人所執(zhí)行、使用、擴展和依賴。這是在開發(fā)軟件中容易被忽略的社交的一面。創(chuàng)造軟件是一個混合了技術和社交的活動。我們只需要經(jīng)常抬頭，這樣才會意識到我們并不是孤立地工作的，我們都有責任去提高個人成功的可能性，而不只是為了開發(fā)團隊。

你可以在孤立的環(huán)境下寫出高質(zhì)量的代碼，但這樣會失去自我。從一個角度來看，那是一個以自我為中心的方法（不是自大，而是自我）。這也是一個禪宗的觀點，他就是針對你編寫代碼那一過程的。我總是試著進入這個環(huán)節(jié)，因為它會讓我離高質(zhì)量更加接近，但那之后我就會陷入這個環(huán)節(jié)。我的團隊現(xiàn)在處于什么環(huán)節(jié)？我的環(huán)節(jié)和團隊的是一樣的嗎？

在祖魯語中，Ubuntu的哲學被概括為“Umuntu ngumuntu ngabantu”，可以大致翻譯為“A person is a person through (other) persons.”(人與人之間是互相聯(lián)系的。我會變得更好因為是你，通過你的行為讓我變得更好。在另一方面，當我做自己的事做得糟糕的時候你也會在你所做的事情上變糟。對于開發(fā)者來說，我們可以這樣理解“A developer is a developer throuth (other) developers.”(開發(fā)者與開發(fā)者之間是相互聯(lián)系的)，也可以說“Code is code through (other) code.”（代碼與代碼之間是相互聯(lián)系的）

我寫的代碼的質(zhì)量會影響到你寫的代碼的質(zhì)量。如果我的代碼質(zhì)量很差會怎樣呢？即使你寫了很整潔的代碼，但由于你會使用我的代碼，所以你的代碼也會降低到和我的代碼質(zhì)量差不多的地步。你可以使用很多模式和技術去降低損失，但是損失已經(jīng)造成了。我建議你去做一些必須做的事之外的一些事情，這是因為當我在做自己的事情的時候我并不會去考慮你。

我會認為我的代碼是非常整潔，但我還是認為如果我使用Ubuntu哲學我可以做得更好。Ubuntu哲學到底是什么？它看起來就像是一段良好的整潔的代碼。它并不是簡單的代碼，而是一件藝術品。它是跟創(chuàng)造藝術有關的行為。和你的朋友一起使用Ubuntu哲學將會幫助你的團隊守住你們的價值觀，增強你們的原則。如果有其他人在任何情況下接觸到你的代碼，都會變成一個更加優(yōu)秀的開發(fā)者。

禪宗是有關個人的。對于一群人來說，Ubuntu也是一種禪宗。我們幾乎不會看到只為自己而寫的代碼。

——Aslam Khan

7.你必須關注你的代碼

不用福爾摩斯我們就會知道好的程序員才能寫出好的代碼。糟糕的程序員嘛…就不會。他們會產(chǎn)生我們必須清理的垃圾。你想寫出好的東西，是不是？那你其實就是想去做一個好的程序員。

優(yōu)秀的代碼并不會無中生有。它并不像行星對齊那樣是靠運氣才產(chǎn)生的。為了獲得優(yōu)秀的代碼，你就得努力去爭取。這有些辛苦。如果你真的關心優(yōu)秀的代碼你就會寫出很好的代碼。

優(yōu)秀的程序并不單單來自技術能力。我曾見過一些有很高能力的程序員，他們能夠?qū)懗鼋o人很深印象的算法，他們把編程語言的標準爛熟于心，但是他們卻寫出了最糟糕的代碼。這些代碼閱讀起來非常痛苦，用起來也痛苦，修改起來也痛苦。我也曾見過更多謙卑的程序員，他們堅持寫出更加簡單的代碼，他們寫出來非常優(yōu)雅非常富有表現(xiàn)力的程序，和他們工作簡直就是享受。

根據(jù)我在軟件行業(yè)多年的經(jīng)驗，我得出了這樣的結(jié)論，一般的程序員和偉大的程序員之間真正的區(qū)別是：態(tài)度。優(yōu)秀的程序使用了專業(yè)的方法，并在現(xiàn)實世界的約束和軟件產(chǎn)業(yè)壓力之下盡量寫出最好的軟件。

代碼的鋪就都得有一個良好的計劃。要想成為一個優(yōu)秀的程序員，你就必須做出很好的計劃，并且真正關心起代碼——培養(yǎng)積極的觀點，養(yǎng)成良好的態(tài)度。好的代碼是由工匠大師精心打造的，絕不是由馬虎的程序員或自稱編碼大師的程序員在不經(jīng)意間就完成的。

——Pete Goodliffe

翻譯： 伯樂在線 - haofly