最近我在接受采訪時被問到我關(guān)于成為一名偉大程序員的見解。這是一個有趣的問題，我認為我們都可以是偉大的程序員，無論我們的天賦如何，如果我們遵循一些規(guī)則的話——我相信——這應(yīng)該是常識。實際上，這些規(guī)則并不只適用于編程領(lǐng)域，也適合任何專業(yè)。

當然，這10個要點中的所有內(nèi)容并不都是完全正兒八經(jīng)的，有些事情只是我的看法，你的情況可能會有所不同，所以如果出現(xiàn)矛盾的話，不要耿耿于懷。

[[208177]]

這些要點是：

1.學(xué)習(xí)如何提問

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

完美主義者：特別是在詢問關(guān)于某些開源工具的問題時，他們可能已經(jīng)通過代碼進行了調(diào)試，發(fā)現(xiàn)了問題的真正原因。但是即使沒有發(fā)現(xiàn)真正原因，完美主義者也會講明白這個問題，重現(xiàn)步驟，建議可能行得通的解決方法，或者甚至是，建議可能行得通的修復(fù)途徑。事實上，完美主義者沒有問題。只有答案。

話匣子：這個人實際上沒有問問題。他們表明他們的想法，有時會到處放置浮夸的問號。對于問題，他們給出的是他們的思路流程，如果你揣著答案等的話，他們要么自己找到了答案，要么在多封電子郵件之后才問出真正的問題。“哦，對了，我發(fā)現(xiàn)這個需求是完全錯誤的，我用一些其他的技術(shù)解決了這個問題。實際上，我完全改變了庫。”呵呵。只希望他們別再問問題了。

笨蛋：代碼在這。我不知道哪里出錯了?請幫幫我。

經(jīng)理：對于這種類型的人，時間就是金錢。問題一定很短，答案越快越好。令人令人啼笑皆非的是，因為保持問題簡短(意即：不完整，不簡潔)，大多數(shù)情況下，會丟失很多重要的細節(jié)，然后為了解答問題，程序員只能請求更多細節(jié)。所以，經(jīng)理(自然會失望，因為他得到的并非是一個答案而是一個新的問題)會再次發(fā)送一個短的訊息，并且更緊急地要求答案。循環(huán)往復(fù)。最后可能需要1-2周的時間才能解答。

抱怨者：這類人不問問題。他們一直一直抱怨，直到問題消失。如果情況沒有變好，那就有了更多的理由抱怨。

現(xiàn)在應(yīng)該清楚的是，一個精心準備的問題(簡明扼要，簡單，簡短，但有足夠的細節(jié))將會產(chǎn)生更佳的答案。如果你確切知道對于該問題你需要學(xué)習(xí)什么，那么更有可能得償所愿。

2.學(xué)習(xí)如何不提出問題

實際上，最好盡量避免提問。或許你可以自己弄清楚呢?當然情況并不總是如此。許多事情你根本無法知道，通過詢問領(lǐng)域?qū)＜?，有助于找到抵達成功最快和最有效的途徑。但是，經(jīng)常自己去嘗試解決問題有很多好處：

通過這種艱辛的方法學(xué)到的東西能夠更好地保存到記憶中——我們將牢牢記住所學(xué)到東西。

自己去尋找答案更有價值。

你不會制造“噪音”。還記得前面所說的“話匣子”嗎?除非你詢問的人有責(zé)任回答問題(從而推遲他們的工作)，否則他們可能會在不了解你的思維過程的情況下，來嘗試回答每一個不完整的“問題”。這對任何人都沒有幫助。

通過推遲問問題(至少一段時間)，你可以收集更多的相關(guān)信息，然后提供給可能能夠回答問題的人。想想“完美主義者”，他們首先花更多時間尋找細節(jié)，然后自己解答問題。

通過訓(xùn)練你可以更擅于提問。這需要時間。

3.不要遺留破碎的窗戶

最近有一篇非常有趣的文章，是關(guān)于不要留下破窗戶的。文章的本質(zhì)是永遠不要妥協(xié)于質(zhì)量。永遠不要成為逃兵。永遠不要遺留…破碎的窗戶。以下引用自這篇文章：

“當我們采取一些捷徑在最短的時間內(nèi)提供一些東西時，反映了我們的粗心大意的代碼會讓我們之后的開發(fā)人員(來自同一個團隊，未來的團隊，甚至我們自己!)得出一個重要的結(jié)論：對我們所生產(chǎn)的代碼付出足夠的關(guān)注并不重要。應(yīng)用程序漸漸開始惡化將是一個不可阻擋的過程。”

其實，這并非意味著要成為一個完美主義者。有時，修復(fù)破碎的窗戶是可以推遲的。但是，通常情況下，對于允許窗戶被打破和保持打破狀態(tài)，沒有人會覺得開心。我們程序員不開心，我們的客戶不開心，我們的用戶不開心，我們的項目經(jīng)理也不開心。這是一種態(tài)度，是作為專業(yè)人士的核心內(nèi)容。Benjamin Franklin怎么看呢?

• “低價格的甜蜜被遺忘之后，低質(zhì)量的苦澀將回味悠長。”

一切都是如此。“低價”是我們用一種草率的方式來實現(xiàn)某些東西而獲得的快速勝利。

4.軟件應(yīng)該是確定性的。這就是要瞄準的目標!

在理想化的世界中，軟件中的一切都應(yīng)該是“確定性的”。我們都應(yīng)該是函數(shù)式程序員，編寫沒有副作用的純粹的函數(shù)。如String.contains()。無論執(zhí)行以下操作多少次：

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

…結(jié)果總是相同的，都是預(yù)期的結(jié)果。哪怕宇宙爆炸對這一計算也沒有影響。這是確定性的。

我們也可以在我們自己的程序中，而不僅僅是在標準庫中做到這一目標。我們可以嘗試盡可能多地編寫無副作用的確定性模塊。這真的與我們選擇什么技術(shù)無關(guān)。確定性編程可以用任何語言完成——即使函數(shù)語言有更多工具也可以通過更復(fù)雜的類型系統(tǒng)來防止意外的副作用。但是我所示的例子是一個Java示例。對象方向允許確定性。對的，像PL / SQL這樣的程序語言允許確定性。如果要在索引中使用函數(shù)，那么需要請求確定性的函數(shù)：

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

這又是一個規(guī)則問題。有副作用的過程/方法/“函數(shù)”是為“破窗戶”。有副作用也許會更容易維護，當然希望最終可以消滅副作用。但這通常是自己騙自己。當將來的某一天意外突現(xiàn)的時候，就是你付出昂貴代價的時候。別不相信，說曹操曹操就到。

5.接受意料之外的事情

程序員始終應(yīng)該遵守墨菲定律。一切都可能被打破。并且它即將被打破。作為軟件工程師，我們應(yīng)該謹記它是會破掉的。因為我們的世界是不確定的，所以我們正在實現(xiàn)的業(yè)務(wù)需求也是不確定的。我們只有在終于能夠確定的時候，才能實現(xiàn)技巧#4(確定論)。否則，我們將不可避免地進入不確定論的世界(也就是“現(xiàn)實世界”)，即一個將會出錯的世界。所以，要以此為基礎(chǔ)。接受意料之外的事情。訓(xùn)練你內(nèi)心的洪荒之力，從積極的角度預(yù)見各種麻煩。

當然，如何以簡潔的方式寫代碼來預(yù)見各種麻煩就是另一個故事了。如何從那些可能會失敗的東西(因此不需要處理)中辨別那些將會失敗的東西(因此需要處理)，還是需要通過一些實踐滴。

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

所有教給你的內(nèi)容都存在潛在的錯誤。即使是那些流行語。引用一句很不錯的話：

• “我的職業(yè)生涯至少有50%是為了幫助或解脫由教條主義引發(fā)的一個個災(zāi)難。
• 我們的職業(yè)充滿了虛假。我們喜歡把自己當作數(shù)學(xué)家，堅持最純粹的思想，認為它們一定是正確的。

那是一條歧路。我們的職業(yè)構(gòu)建在數(shù)學(xué)的基礎(chǔ)之上，但除非你進入范疇論或關(guān)系代數(shù)的時髦世界(即便你真的進入，我也懷疑一切是否是“正確的”)，否則你就得面對現(xiàn)實世界務(wù)實的業(yè)務(wù)需求。好吧，坦率地說，這離完美還有十萬八千里。讓我們來看看一些最流行的編程語言：

• C
• Java
• SQL

你真的覺得這些語言一點都不像數(shù)學(xué)嗎?行，不如我們先來討論段錯誤，Java泛型和SQL三值邏輯。這些語言是由實用主義者建立的平臺。所有這些都有一些非?？岬睦碚摫尘?，但最終，還是有了這些工具。

對于建立在語言之上的所有東西也是如此：庫，框架，設(shè)計模式，甚至架構(gòu)。沒有什么是對的或是錯的。一切都是為某些上下文設(shè)計的工具。想想在其上下文中的工具。永遠不要把這個工具當成一個獨立的理由。我們不是“為藝術(shù)而藝術(shù)”。

所以對這些質(zhì)疑說不：

• XML
• JSON
• 功能編程
• 面向?qū)ο缶幊?/li>
• 設(shè)計模式
• 微服務(wù)
• 三層架構(gòu)
• DDD
• TDD
• 實際上：*DD
• 不勝枚舉

所有這些都是某些給定上下文的好工具，但并不總是如此，要學(xué)會具體情況具體對待。保持好奇心，開發(fā)創(chuàng)造力，知道何時才需要使用這些工具，將有助于你成為一個更優(yōu)秀的程序員。

7.就是干

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

但大多數(shù)程序員只達到“好”的級別，或是有潛力達到“好”的程度。那么怎么才能成為一名好的程序員呢?正如羅馬不是一天建成的，偉大的軟件也不是一天可以寫成的，受歡迎的人并非我們這個時代唯一的英雄。我遇到過許多默默無聞但偉大的程序員，他們孜孜不倦地攻克軟件難題，解決了許多小公司隱蔽的問題。

偉大的程序員都有一個共同點：遇到問題就是干。練習(xí)，實踐。每天都致力于工作與學(xué)習(xí)，然后變得越來越優(yōu)秀。

想要更擅長SQL?那就干吧!每天都嘗試用一些新功能編寫一個SQL語句。使用window functions。分組。遞歸。分區(qū)的外連接。MODEL和/或MATCH_RECOGNIZE子句。不需要每次都交付生產(chǎn)，就是為了實踐。這些都是有價值的。

8.專注一個主題(從長遠的角度)

可能只有很少一部分“優(yōu)秀的”全棧開發(fā)人員獨領(lǐng)風(fēng)騷。事實上，大多數(shù)全棧開發(fā)人員都將位于中間水平。當然，一個小團隊可能只需要幾個全棧開發(fā)人員，就可以涵蓋很多業(yè)務(wù)邏輯，快速推出一個新的軟件。但是，軟件將非常笨拙，“馬馬虎虎能工作”。也許這對于只要可行即可的產(chǎn)品階段來說就已足夠，但從長遠來看，會導(dǎo)致全棧開發(fā)人員將沒有時間來正確分析(或預(yù)見!)更復(fù)雜的問題。

主要專注一個主題，并真正擅長這個方面。真金不怕火來煉，只要你有本事，那么走到哪里都需要。所以，致力于你的職業(yè)生涯，做一些真正好的東西，而不是“差不多就行”。

9.涉獵廣泛

雖然你應(yīng)該主要關(guān)注一個主題，但不應(yīng)該完全遺忘其他方面。你永遠不能馬上真正擅長SQL、擴大、擴展、低級性能、CSS、面向?qū)ο?、需求工程、架?gòu)等等的所有內(nèi)容(見技巧#8)。這是不可能的。

但你至少應(yīng)該明白它們每一個的本質(zhì)。你需要明白何時SQL是正確選擇(以及何時不是)。何時低級別性能的調(diào)整很重要(何時不是)。CSS原則上如何工作。面向?qū)ο?、FP優(yōu)點。等等。

你應(yīng)該花一些時間涉獵這些(以及更多)概念和技術(shù)，以便更好地了解它們的重要性。知道何時應(yīng)用它們，然后再找專業(yè)人士來實際執(zhí)行工作。

涉獵新的范式和技術(shù)，有助于你用全然不同的思維方式思考，可能你會在以后的日常工作中不自覺地以某種方式用到它們。

10.保持簡單，傻瓜式

愛因斯坦曾說：

“Everything should be made as simple as possible, but no simpler.”

(“任何事情都應(yīng)該盡可能簡化,直到?jīng)]法再簡化為止。”)

沒有人能夠處理巨大的復(fù)雜性。在軟件中不能，在生活的任何其他方面也不能。復(fù)雜性是好軟件的殺手，因此簡單性是使能者。易于明白。難于實現(xiàn)。你需要大量時間和實踐才能識別和生產(chǎn)出簡單。當然，你可以遵循許多規(guī)則來實現(xiàn)簡單化。

最簡單的規(guī)則之一就是使用只有幾個參數(shù)的方法/函數(shù)。讓我們來看看吧。前面提到的String.contains()方法就是如此。我們可以寫”abcde”.contains(“bcd”)，不閱讀任何文檔，每個人都能立即了解這做什么以及為什么。該方法做了一件事情，并且只做這一件。沒有復(fù)雜的上下文/設(shè)置/其他傳遞給該方法的參數(shù)。沒有“特殊情況”，也沒有任何警告。

此外，在庫中簡化比在業(yè)務(wù)邏輯中要簡單得多。那么我們能實現(xiàn)嗎?也許吧。通過實踐。通過重構(gòu)。但像偉大的軟件一樣，簡單性也不是一天可以搞定的。

(高級技巧：應(yīng)用康威定律。在一個業(yè)務(wù)超級復(fù)雜的環(huán)境中編寫又好又簡單的軟件是完全不可能的。要么你選擇復(fù)雜性和丑陋，要么你最好擺脫那個業(yè)務(wù))。