// 譯註：英文原文發佈今年年初，所以開頭提到了”新年“，請不要驚訝~
程序員總是有很多的決定，不是嗎？如果你的新年待辦事項還是空白的話，那麼可以考慮使用下面這些程序員的想法。即使是最聰明的人，也還有成長空間。以下內容摘錄自 Kevlin Henney 的《程序員應該知道的 97 件事》。
1. 在怪罪其他東西之前先檢查自己的代碼
質疑一下你自己和他人的預設情況。來自不同供應商的工具，可能內置有不同的預設，也有可能相同的供應商提供不同的工具。
當有人想你報告一個你無法重複的問題之時，去看看他們做了些什麼。他們可能會做一些你沒有想到的事情，或者是按照不同的順序來做那件事。
我的原則是，如果我遇到一個我無法避免的 bug 時，我會首先考慮是編譯器的錯誤，然後我就會去檢查堆棧是否被破壞了。這可以通過跟蹤代碼來實現，可以有效地移除問題。多線程問題是另一個絞盡腦汁也不容易找到的錯誤來源，通常還伴隨着機器的錯誤。當一個系統使用多線程的時候，所有的簡單的代碼的錯誤都會成倍地增長。不能依靠調試和單元測試去發現這樣的兼容性問題，所以簡單的設計是最重要的。
總之，在你怪罪你的編譯器之前，請記住福爾摩斯的忠告：“當你把所有的不可能都排除了，那麼剩下的東西，無論他有多麼的不可能，都必定是真相。”Dirk Gently 也說了類似的話。
——Allan Kelly
2. 持續學習
我們生活在一個有趣的時代。隨着全球化的發展，你要知道有大量的人都能勝任你的工作。你需要不斷地學習，以維持競爭力。否則，你會成爲一個落伍的人，永遠做着相同的工作，直到你不再被需要，或者這個工作被廉價外包給其他人的那一天。
因此，你打算做些什麼呢？有些大方的老闆會提供訓練來拓寬你的技能。而其他的公司並不會給你空閒的時間和金錢去做任何的訓練。所以爲了工作的穩定，你需要爲自己的教育負責。
這裏是一些讓你持續學習的方法清單。其中許多都能夠隨便在網上找到：
閱讀書籍、雜誌、博客、Twitter 和其他網站。如果你想對一個目標進行更深入的研究，考慮添加一個郵件列表或新聞組
如果你真想專注於某一種技術，那就動起手來——寫一些代碼
成爲行業的頂尖人物可能會妨礙你的學習，你得儘量與導師合作。雖然你可以從任何人那裏學到東西，但是從那些比你更聰明或更有經驗的人那裏你能夠學得更多。如果你不能找到一個導師，那就繼續去找
使用虛擬的導師。在網上找一些作者或者開發人員，他們寫的東西你都會喜歡並且都會看的。訂閱他們的博客
瞭解你所使用的框架和庫。知道了他們是如何工作的，你使用起來就更得心應手。如果他們是開源的，你就很幸運了。使用調試器來單步執行，去觀察他們內部是如何運作的。你將會看到那些真正聰明的人所編寫和審閱的代碼
當你做錯了或者是在修復 bug，或者是碰到一個問題的時候，嘗試去深入瞭解到底發生了什麼。有可能其他人也遇到了同樣的問題，並且把 2 他發佈在了網上。Google 這時候就非常有用了
學習一樣東西的一個好方法就是去傳授和談論它。當人們想要聽你講解並且想問你問題的時候，你就會更加積極地去學習。在工作中使用 lunch-’ n’-learn 方法，可以是一個用戶組或者是一個本地的協會
加入或者創辦一個研究小組（社區的模式）或本地用戶組，可以研究你們感興趣的語言，技術或者是法律
多去參加會議。如果你不能去，很多的會議都會把內容免費發佈到網上的
想要長期通勤？聽一下博客吧
你是否曾經在一個代碼庫上運行一個靜態分析工具或者在你的 IDE 裏看到一些警告？弄明白他們報告的是什麼，爲什麼要報告
遵循高效程序員的建議，每年學習一門新的語言。至少學習一門新的技術或者是一個新的工具。弄一個分支出來添加上你的想法，以便你能夠在你目前的知識庫裏使用
並不是你應該學的每一樣東西都必須跟技術有關。學習你工作領域的一些東西，能夠讓你更加了解需求，並且能夠給幫助你解決一些商業問題。學習如何提高工作效率，學習怎樣更高效低工作是一個不錯的選擇
返回學校
如果你有《黑客帝國》裏的尼奧那樣的能力就好了，能夠直接下載我們需要的東西到大腦裏面去。但是我們並沒有，所以必須花費一定的時間去學習。你不必每時每刻都在學習。一點點時間足以，比如一週一次，有總比沒有好。我們總得有一些工作之外的生活。
科技發展如此迅速，我們不要被甩在後面了。
——Clint Shank
3. 不要害怕破壞某些東西
每一個具有行業經驗的人無疑曾在一個充滿不穩定性的項目中工作過。這個系統是很難重構的，通常改變一個地方就會觸及到另一個不相關的地方。每當要添加一個模塊的時候，程序員的目標都是儘量少改動，在每一個版本中都是小心翼翼的。這就和把建造摩天大樓當做搭積木一樣，容易造成災難。修改對的時候是非常傷腦筋的，因爲系統已經生病了。它需要一個醫生，否則狀況就會越來越差。雖然你已經知道了你係統發生了什麼錯誤，但是你還是害怕“打破雞蛋去煮你的煎蛋卷”。一個熟練的醫生知道，爲了做手術就必須開刀，而且她也知道開刀只是暫時的，而且很快就會癒合。對於最初的疼痛來說，做手術是非常有價值的，患者通常都會獲得比做手術前更好的狀態。
不要去擔心你的代碼。當你在做事的時候如果暫時被打斷，誰會去擔心呢？對改變的恐懼會讓你的項目將進入這樣的狀態。花一些時間去重構項目會讓你節約很多的時間。還有一個額外的好處就是一個團隊面對這個損壞的系統的處理經驗會讓你們明白該怎樣才能讓它正常工作。要學會運用這些知識，而不是牴觸他們。每個人都不應該把時間花在自己所討厭的東西上。重新定義內部接口，重組模塊，重構、複製、粘貼代碼，並通過減少依賴來簡化設計。你可以通過消除極端情況來減少代碼的複雜度，他們通常會產生不當的耦合性。慢慢地將舊架構過渡到新的架構，邊改邊測試。試圖在一個可能產生很多問題的大項目上進行一次大的重構，這些問題可能慧然你在中途就放棄之前所作的所有的努力。
作爲一個醫生，是不應該害怕切除患病的部位，以留出癒合的空間。態度是會傳染的，並且會激勵其他人去對那些一直拖延着的項目進行修改。去列出一個團隊都感覺良好的項目的清單。雖然這些任務可能不會產生明顯的效果，但你得去說服管理層，他們就會減少開支，加速對新版本的開發。永遠不要停止關心代碼的總體“健康度”。
——Mike Lewis
4. 做專業的程序員
一個專業的程序員最重要的特徵就是個人責任感。專業的程序員會對自己的生涯、自己的估計、自己的日程安排、自己的錯誤以及自己的作品負責。一個專業的程序員是不會把這些責任推給其他人的。
如果你是一個專業人員，那麼你就會對自己的工作負責。你有責任閱讀和學習。你有責任追趕業界及技術的潮流。而很多程序員都認爲這是他們上司的工作。對不起，這是大錯特錯的。你認爲醫生也會那樣做嗎？你認爲律師也是那樣的嗎？不是的，他們會利用自己的時間和金錢去學習。他們花費大量的下班時間去閱讀期刊和做出計劃。他們會時刻更新自己，我們也必須這樣做。你和僱主之間的關係只是爲了履行合同。總之：你的僱主承諾給你工資，你就得承諾去把這份工作做好。
專業的程序員會對他們編寫的代碼負責。如果他們不清楚代碼是否會正常的工作，就絕不會輕易放出代碼。試想一下，如果打算放出一個不確定的代碼，你還有可能是一個專業的程序員嗎？專業的程序員都不希望 QA 來發現他們的錯誤，因爲他們如果不經嚴格測試是不會放出代碼的。當然，QA 也許會找到一些問題，因爲沒有什麼是完美的嘛。但是作爲專業人士，重要的是我們的態度，我們決不能讓 QA 找到什麼問題。
專業人士都是團隊合作。他們會對整個團隊的未來負責，這並不是他們個人的工作。他們互相幫助，彼此教導，互相學習，甚至包括別人需要的任何時候。當一個隊友倒下，其他人都會去關心，因爲他們知道他們都有互相需要的時候。
專業的人士是不會容忍一大串 bug 列表的。一個巨大的 bug 清單是非常粗心的。一個在問題跟蹤數據庫裏有成百上千問題的系統是粗心釀成的悲劇。事實上，在大多數的項目中，如果非常依賴問題跟蹤系統，那麼他們肯定總是粗心大意的。只有非常大的系統纔可能會又這麼長的 bug 清單，這個時候需要的是自動化的管理。
專業人士不會把事情弄得一團糟，他們會對自己的工作引以爲豪。他們保持代碼的整潔，結構的良好，而且便於閱讀。他們跟隨着默認的標準而且做出了很好的實踐。他們永遠不會趨之若鶩。假設你能夠在醫生給你做開放式心臟手術的時候靈魂出竅。這個醫生有一個最後期限（只是字面意義上的）。他必須在心肺循環功能損失過量血細胞之前完成。你覺得他該怎麼做？你是想要他們像典型的軟件開發人員那樣匆忙而且混亂嗎？或者想要他們說“我待會兒再回來解決”？還是你要他們小心地遵循着紀律，抓緊時間，相信他自己的做法是目前可以採取的最好的方法。你是想要一片混亂還是專業精神呢？
專業人員得有責任感。他們會對自己的事業負責。他們會對代碼的正常運行負責。他們對自己工作的質量負責。即使最後期限迫在眉睫，他們也不會放棄自己的原則。事實上，當壓力越來越大的時候，專業人員甚至會對這些原則要求得更緊，因爲他們認爲這是對的。
——Robert C. Martin (Uncle Bob)
5. 利用代碼分析工具
測試的價值是在他們編程之旅的早期階段就灌輸給開發者的。今年來，單元測試，測試驅動開發，以及敏捷方法的興起都被大量地用於開發週期的每一個過程。然而，測試只是衆多能夠提高代碼質量的工具之一。
回到早期階段，當C語言還是一個新興的技術的時候，CPU 的時間和存儲的形式都是非常珍貴的。第一個C語言編譯器注意到了這一點，所以通過一些語義分析減少了便利代碼的次數。這意味着在編譯階段，只能檢測到一小部分的錯誤。爲了彌補這個，Stephen Johnson 編寫了一個叫做 lint 的工具，這個工具能夠取出你的代碼中的一些冗餘，實現了在其相似的C編譯器中已經去除的靜態分析。然而，靜態分析工具，會增加大量的無用警告或者是一些關於文體問題的不必要的警告。
當前，語言、編譯器和靜態分析工具的情況是非常不同的。內存和 CPU 時間現在也變得非常的便宜，所以編譯器能夠承擔更多的錯誤檢測。幾乎每一種語言都至少擁有一個工具來檢查違規的格式和常見的問題，不過有時，那些隱含的錯誤並不會被檢測到，比如潛在的空指針引用。對於更復雜的工具，比如針對C的 SPlint，針對 Python 的 Pylint，都是可配置的，也就是說，你可以通過一個配置文件選擇這個工具在命令行或者是 IDe 裏要發出什麼錯誤和警告。SPlint 甚至會讓你在註釋裏註釋你的代碼，以給別人更多關於程序運行的提示。
如果一切都失敗了，你發現你自己正在尋找一些你的編譯器或 IDE 或 lint 工具沒有捕獲的簡單的 bug 或者是一些違規行爲，你就得收起你所有的靜態分析工具。這並不像聽起來那麼困難。大多數編程語言，尤其是那些聲稱是動態的語言，都會把他們的抽象語法樹和編譯工具作爲其標準庫的一部分。去了解你正在使用的這個語言的開發團隊的標準庫的細節是非常有意義的，因爲這樣你就能發現一些有價值的東西，這對於靜態分析和動態測試是非常有用的。比如：Python 標準庫包含了一個反彙編程序，它會告訴你生成一些編譯程序和目標程序的字節代碼。這對編譯器作者 python-dev 團隊來說貌似是一個不起眼的工具，但是它實際上在日常工作中發揮着不同尋常的作用。這個庫能夠反匯編出來你最後一次堆棧跟蹤的信息，這會給你恰當的反饋，因爲字節碼指令會把最後一次未捕獲的異常扔在那裏。
所以，不要把測試放在質量保證工作的最後，利用好分析工具，不要害怕把自己的錯誤展示出來
——Sarah Mount
6. 和你的朋友一起使用 Ubuntu 哲學
所以很多時候，我們獨立地編寫代碼，這些代碼反映了我們個人對問題的理解，也反映了一個非常個性化的解決方案。我們可能會是團隊的一部分，但是我們仍然會是獨立的，因爲這是一個團隊。我們很容易忘記這些獨立編寫的代碼會被其他人所執行、使用、擴展和依賴。這是在開發軟件中容易被忽略的社交的一面。創造軟件是一個混合了技術和社交的活動。我們只需要經常擡頭，這樣纔會意識到我們並不是孤立地工作的，我們都有責任去提高個人成功的可能性，而不只是爲了開發團隊。
你可以在孤立的環境下寫出高質量的代碼，但這樣會失去自我。從一個角度來看，那是一個以自我爲中心的方法（不是自大，而是自我）。這也是一個禪宗的觀點，他就是針對你編寫代碼那一過程的。我總是試着進入這個環節，因爲它會讓我離高質量更加接近，但那之後我就會陷入這個環節。我的團隊現在處於什麼環節？我的環節和團隊的是一樣的嗎？
在祖魯語中，Ubuntu 的哲學被概括爲“Umuntu ngumuntu ngabantu”，可以大致翻譯爲“A person is a person through (other) persons.”(人與人之間是互相聯繫的。我會變得更好因爲是你，通過你的行爲讓我變得更好。在另一方面，當我做自己的事做得糟糕的時候你也會在你所做的事情上變糟。對於開發者來說，我們可以這樣理解“A developer is a developer throuth (other) developers.”(開發者與開發者之間是相互聯繫的)，也可以說“Code is code through (other) code.”（代碼與代碼之間是相互聯繫的）
我寫的代碼的質量會影響到你寫的代碼的質量。如果我的代碼質量很差會怎樣呢？即使你寫了很整潔的代碼，但由於你會使用我的代碼，所以你的代碼也會降低到和我的代碼質量差不多的地步。你可以使用很多模式和技術去降低損失，但是損失已經造成了。我建議你去做一些必須做的事之外的一些事情，這是因爲當我在做自己的事情的時候我並不會去考慮你。
我會認爲我的代碼是非常整潔，但我還是認爲如果我使用 Ubuntu 哲學我可以做得更好。Ubuntu 哲學到底是什麼？它看起來就像是一段良好的整潔的代碼。它並不是簡單的代碼，而是一件藝術品。它是跟創造藝術有關的行爲。和你的朋友一起使用 Ubuntu 哲學將會幫助你的團隊守住你們的價值觀，增強你們的原則。如果有其他人在任何情況下接觸到你的代碼，都會變成一個更加優秀的開發者。
禪宗是有關個人的。對於一羣人來說，Ubuntu 也是一種禪宗。我們幾乎不會看到只爲自己而寫的代碼。
——Aslam Khan
7. 你必須關心你的代碼
不用福爾摩斯我們就會知道好的程序員才能寫出好的代碼。糟糕的程序員嘛…就不會。他們會產生我們必須清理的垃圾。你想寫出好的東西，是不是？那你其實就是想去做一個好的程序員。
優秀的代碼並不會無中生有。它並不像行星對齊那樣是靠運氣才產生的。爲了獲得優秀的代碼，你就得努力去爭取。這有些辛苦。如果你真的關心優秀的代碼你就會寫出很好的代碼。
優秀的程序並不單單來自技術能力。我曾見過一些有很高能力的程序員，他們能夠寫出給人很深印象的算法，他們把編程語言的標準爛熟於心，但是他們卻寫出了最糟糕的代碼。這些代碼閱讀起來非常痛苦，用起來也痛苦，修改起來也痛苦。我也曾見過更多謙卑的程序員，他們堅持寫出更加簡單的代碼，他們寫出來非常優雅非常富有表現力的程序，和他們工作簡直就是享受。
根據我在軟件行業多年的經驗，我得出了這樣的結論，一般的程序員和偉大的程序員之間真正的區別是：態度。優秀的程序使用了專業的方法，並在現實世界的約束和軟件產業壓力之下儘量寫出最好的軟件。
代碼的鋪就都得有一個良好的計劃。要想成爲一個優秀的程序員，你就必須做出很好的計劃，並且真正關心起代碼——培養積極的觀點，養成良好的態度。偉大的代碼是由工匠大師精心打造的，絕不是由滿湖的程序員或自稱編碼大師的程序員在不經意間就完成的。
——Pete Goodliffe
祝大家在 2014 年一切順利！
原文鏈接： Amy Jollymore 翻譯： 伯樂在線 - haofly
譯文鏈接： http://blog.jobbole.com/62142/
