// 譯註：英文原文釋出今年年初，所以開頭提到了”新年“，請不要驚訝~
程式設計師總是有很多的決定，不是嗎？如果你的新年待辦事項還是空白的話，那麼可以考慮使用下面這些程式設計師的想法。即使是最聰明的人，也還有成長空間。以下內容摘錄自 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年一切順利！