成爲偉大程序員的 10 個要點

最近我在接受採訪時被問到我關於成爲一名偉大程序員的看法。這是一個有趣的問題，我認爲咱們均可以是偉大的程序員，不管咱們的天賦如何，若是咱們遵循一些規則的話——我相信——這應該是常識。實際上，這些規則並不僅適用於編程領域，也適合任何專業。

固然，這10個要點中的全部內容並不都是徹底正兒八經的，有些事情只是個人見解，你的狀況可能會有所不一樣，因此若是出現矛盾的話，不要耿耿於懷。

這些要點是：

1.學習如何提問

提問題的程序員基本上有這些類型：

• 完美主義者：特別是在詢問關於某些開源工具的問題時，他們可能已經經過代碼進行了調試，發現了問題的真正緣由。可是即便沒有發現真正緣由，完美主義者也會講明白這個問題，重現步驟，建議可能行得通的解決方法，或者甚至是，建議可能行得通的修復途徑。事實上，完美主義者沒有問題。只有答案。
• 話匣子：這我的實際上沒有問問題。他們代表他們的想法，有時會處處放置浮誇的問號。對於問題，他們給出的是他們的思路流程，若是你揣着答案等的話，他們要麼本身找到了答案，要麼在多封電子郵件以後才問出真正的問題。「哦，對了，我發現這個需求是徹底錯誤的，我用一些其餘的技術解決了這個問題。實際上，我徹底改變了庫。」呵呵。只但願他們別再問問題了。
• 笨蛋：代碼在這。我不知道哪裏出錯了？請幫幫我。
• 經理：對於這種類型的人，時間就是金錢。問題必定很短，答案越快越好。使人使人哭笑不得的是，由於保持問題簡短（意即：不完整，不簡潔），大多數狀況下，會丟失不少重要的細節，而後爲了解答問題，程序員只能請求更多細節。因此，經理（天然會失望，由於他獲得的並不是是一個答案而是一個新的問題）會再次發送一個短的訊息，而且更緊急地要求答案。循環往復。最後可能須要1-2周的時間才能解答。
• 抱怨者：這類人不問問題。他們一直一直抱怨，直到問題消失。若是狀況沒有變好，那就有了更多的理由抱怨。

如今應該清楚的是，一個精心準備的問題（簡明扼要，簡單，簡短，但有足夠的細節）將會產生更佳的答案。若是你確切知道對於該問題你須要學習什麼，那麼更有可能得償所願。

2.學習如何不提出問題

實際上，最好儘可能避免提問。或許你能夠本身弄清楚呢？固然狀況並不老是如此。許多事情你根本沒法知道，經過詢問領域專家，有助於找到抵達成功最快和最有效的途徑。可是，常常本身去嘗試解決問題有不少好處：

• 經過這種艱辛的方法學到的東西可以更好地保存到記憶中——咱們將緊緊記住所學到東西。
• 本身去尋找答案更有價值。
• 你不會製造「噪音」。還記得前面所說的「話匣子」嗎？除非你詢問的人有責任回答問題（從而推遲他們的工做），不然他們可能會在不瞭解你的思惟過程的狀況下，來嘗試回答每個不完整的「問題」。這對任何人都沒有幫助。
• 經過推遲問問題（至少一段時間），你能夠收集更多的相關信息，而後提供給可能可以回答問題的人。想一想「完美主義者」，他們首先花更多時間尋找細節，而後本身解答問題。
• 經過訓練你能夠更擅於提問。這須要時間。

3.不要遺留破碎的窗戶

最近有一篇很是有趣的文章，是關於不要留下破窗戶的。文章的本質是永遠不要妥協於質量。永遠不要成爲逃兵。永遠不要遺留…破碎的窗戶。如下引用自這篇文章：

「當咱們採起一些捷徑在最短的時間內提供一些東西時，反映了咱們的粗枝大葉的代碼會讓咱們以後的開發人員（來自同一個團隊，將來的團隊，甚至咱們本身！）得出一個重要的結論：對咱們所生產的代碼付出足夠的關注並不重要。應用程序漸漸開始惡化將是一個不可阻擋的過程。」

其實，這並不是意味着要成爲一個完美主義者。有時，修復破碎的窗戶是能夠推遲的。可是，一般狀況下，對於容許窗戶被打破和保持打破狀態，沒有人會以爲開心。咱們程序員不開心，咱們的客戶不開心，咱們的用戶不開心，咱們的項目經理也不開心。這是一種態度，是做爲專業人士的核心內容。Benjamin Franklin怎麼看呢？

「低價格的甜蜜被遺忘以後，低質量的苦澀將回味悠長。」

一切都是如此。「低價」是咱們用一種草率的方式來實現某些東西而得到的快速勝利。

4.軟件應該是肯定性的。這就是要瞄準的目標！

在理想化的世界中，軟件中的一切都應該是「肯定性的」。咱們都應該是函數式程序員，編寫沒有反作用的純粹的函數。如String.contains()。不管執行如下操做多少次：

assertTrue("abcde".contains("bc"));

…結果老是相同的，都是預期的結果。哪怕宇宙爆炸對這一計算也沒有影響。這是肯定性的。

咱們也能夠在咱們本身的程序中，而不只僅是在標準庫中作到這一目標。咱們能夠嘗試儘量多地編寫無反作用的肯定性模塊。這真的與咱們選擇什麼技術無關。肯定性編程能夠用任何語言完成——即便函數語言有更多工具也能夠經過更復雜的類型系統來防止意外的反作用。可是我所示的例子是一個Java示例。對象方向容許肯定性。對的，像PL / SQL這樣的程序語言容許肯定性。若是要在索引中使用函數，那麼須要請求肯定性的函數：

CREATE INDEX upper_first_name ON customer (upper (first_name));
-- Deterministic function here: -----------^^^^^^^^^^^^^^^^^^

這又是一個規則問題。有反作用的過程/方法/「函數」是爲「破窗戶」。有反作用也許會更容易維護，固然但願最終能夠消滅反作用。但這一般是本身騙本身。當未來的某一天意外突現的時候，就是你付出昂貴代價的時候。別不相信，說曹操曹操就到。

5.接受意料以外的事情

程序員始終應該遵照墨菲定律。一切均可能被打破。而且它即將被打破。做爲軟件工程師，咱們應該謹記它是會破掉的。由於咱們的世界是不肯定的，因此咱們正在實現的業務需求也是不肯定的。咱們只有在終於可以肯定的時候，才能實現技巧#4（肯定論）。不然，咱們將不可避免地進入不肯定論的世界（也就是「現實世界」），即一個將會出錯的世界。因此，要以此爲基礎。接受意料以外的事情。訓練你心裏的洪荒之力，從積極的角度預見各類麻煩。

固然，如何以簡潔的方式寫代碼來預見各類麻煩就是另外一個故事了。如何從那些可能會失敗的東西（所以不須要處理）中辨別那些將會失敗的東西（所以須要處理），仍是須要經過一些實踐滴。

6.不要貨物崇拜。不要教條主義。始終具體狀況具體對待。

全部教給你的內容都存在潛在的錯誤。即便是那些流行語。引用一句很不錯的話：

「個人職業生涯至少有50％是爲了幫助或解脫由教條主義引起的一個個災難。

咱們的職業充滿了虛假。咱們喜歡把本身看成數學家，堅持最純粹的思想，認爲它們必定是正確的。

那是一條歧路。咱們的職業構建在數學的基礎之上，但除非你進入範疇論或關係代數的時髦世界（即使你真的進入，我也懷疑一切是不是「正確的」），不然你就得面對現實世界務實的業務需求。好吧，坦率地說，這離完美還有十萬八千里。讓咱們來看看一些最流行的編程語言：

• C
• Java
• SQL

你真的以爲這些語言一點都不像數學嗎？行，不如咱們先來討論段錯誤，Java泛型和SQL三值邏輯。這些語言是由實用主義者創建的平臺。全部這些都有一些很是酷的理論背景，但最終，仍是有了這些工具。

對於創建在語言之上的全部東西也是如此：庫，框架，設計模式，甚至架構。沒有什麼是對的或是錯的。一切都是爲某些上下文設計的工具。想一想在其上下文中的工具。永遠不要把這個工具當成一個獨立的理由。咱們不是「爲藝術而藝術」。

因此對這些質疑說不：

• XML
• JSON
• 功能編程
• 面向對象編程
• 設計模式
• 微服務
• 三層架構
• DDD
• TDD
• 實際上：*DD
• 不勝枚舉

全部這些都是某些給定上下文的好工具，但並不老是如此，要學會具體狀況具體對待。保持好奇心，開發創造力，知道什麼時候才須要使用這些工具，將有助於你成爲一個更優秀的程序員。

7.就是幹

這是真理。話說，總有一些牛人出類拔萃，可以傲視羣雄，讓人鞭長莫及。

但大多數程序員只達到「好」的級別，或是有潛力達到「好」的程度。那麼怎麼才能成爲一名好的程序員呢？正如羅馬不是一天建成的，偉大的軟件也不是一天能夠寫成的，受歡迎的人並不是咱們這個時代惟一的英雄。我遇到過許多默默無聞但偉大的程序員，他們孜孜不倦地攻克軟件難題，解決了許多小公司隱蔽的問題。

偉大的程序員都有一個共同點：遇到問題就是幹。練習，實踐。天天都致力於工做與學習，而後變得愈來愈優秀。

想要更擅長SQL？那就幹吧！天天都嘗試用一些新功能編寫一個SQL語句。使用window functions。分組。遞歸。分區的外鏈接。MODEL和/或MATCH_RECOGNIZE子句。不須要每次都交付生產，就是爲了實踐。這些都是有價值的。

8.專一一個主題（從長遠的角度）

可能只有不多一部分「優秀的」全棧開發人員獨領風騷。事實上，大多數全棧開發人員都將位於中間水平。固然，一個小團隊可能只須要幾個全棧開發人員，就能夠涵蓋不少業務邏輯，快速推出一個新的軟件。可是，軟件將很是笨拙，「馬馬虎虎能工做」。也許這對於只要可行便可的產品階段來講就已足夠，但從長遠來看，會致使全棧開發人員將沒有時間來正確分析（或預見！）更復雜的問題。

主要專一一個主題，並真正擅長這個方面。真金不怕火來煉，只要你有本事，那麼走到哪裏都須要。因此，致力於你的職業生涯，作一些真正好的東西，而不是「差很少就行」。

9.涉獵普遍

雖然你應該主要關注一個主題，但不該該徹底遺忘其餘方面。你永遠不能立刻真正擅長SQL、擴大、擴展、低級性能、CSS、面向對象、需求工程、架構等等的全部內容（見技巧#8）。這是不可能的。

但你至少應該明白它們每個的本質。你須要明白什麼時候SQL是正確選擇（以及什麼時候不是）。什麼時候低級別性能的調整很重要（什麼時候不是）。CSS原則上如何工做。面向對象、FP優勢。等等。

你應該花一些時間涉獵這些（以及更多）概念和技術，以便更好地瞭解它們的重要性。知道什麼時候應用它們，而後再找專業人士來實際執行工做。

涉獵新的範式和技術，有助於你用全然不一樣的思惟方式思考，可能你會在之後的平常工做中不自覺地以某種方式用到它們。

10.保持簡單，傻瓜式

愛因斯坦曾說：

「Everything should be made as simple as possible, but no simpler.」
（「任何事情都應該儘量簡化,直到無法再簡化爲止。」）

沒有人可以處理巨大的複雜性。在軟件中不能，在生活的任何其餘方面也不能。複雜性是好軟件的殺手，所以簡單性是使能者。易於明白。難於實現。你須要大量時間和實踐才能識別和生產出簡單。固然，你能夠遵循許多規則來實現簡單化。

最簡單的規則之一就是使用只有幾個參數的方法/函數。讓咱們來看看吧。前面提到的String.contains()方法就是如此。咱們能夠寫」abcde」.contains(「bcd」)，不閱讀任何文檔，每一個人都能當即瞭解這作什麼以及爲何。該方法作了一件事情，而且只作這一件。沒有複雜的上下文/設置/其餘傳遞給該方法的參數。沒有「特殊狀況」，也沒有任何警告。

此外，在庫中簡化比在業務邏輯中要簡單得多。那麼咱們能實現嗎？也許吧。經過實踐。經過重構。但像偉大的軟件同樣，簡單性也不是一天能夠搞定的。

（高級技巧：應用康威定律。在一個業務超級複雜的環境中編寫又好又簡單的軟件是徹底不可能的。要麼你選擇複雜性和醜陋，要麼你最好擺脫那個業務）。

個人Java學習交流QQ羣：589809992 咱們一塊兒學Java！