想成為一個偉大程式設計師：這個10 個要點也許可以幫到你
這10個要點中的所有內容並不都是完全正兒八經的，有些事情只是我的看法，你的情況可能會有所不同，所以如果出現矛盾的話，不要耿耿於懷。
image
這些要點是：
1.學習如何提問
提問題的程式設計師基本上有這些型別：
-
完美主義者：特別是在詢問關於某些開源工具的問題時，他們可能已經通過程式碼進行了除錯，發現了問題的真正原因。但是即使沒有發現真正原因，完美主義者也會講明白這個問題，重現步驟，建議可能行得通的解決方法，或者甚至是，建議可能行得通的修復途徑。事實上，完美主義者沒有問題。只有答案。
-
話匣子：這個人實際上沒有問問題。他們表明他們的想法，有時會到處放置浮誇的問號。對於問題，他們給出的是他們的思路流程，如果你揣著答案等的話，他們要麼自己找到了答案，要麼在多封電子郵件之後才問出真正的問題。“哦，對了，我發現這個需求是完全錯誤的，我用一些其他的技術解決了這個問題。實際上，我完全改變了庫。”呵呵。只希望他們別再問問題了。
-
笨蛋：程式碼在這。我不知道哪裡出錯了？請幫幫我。
-
經理：對於這種型別的人，時間就是金錢。問題一定很短，答案越快越好。令人令人啼笑皆非的是，因為保持問題簡短（意即：不完整，不簡潔），大多數情況下，會丟失很多重要的細節，然後為了解答問題，程式設計師只能請求更多細節。所以，經理（自然會失望，因為他得到的並非是一個答案而是一個新的問題）會再次傳送一個短的訊息，並且更緊急地要求答案。迴圈往復。最後可能需要1-2周的時間才能解答。
-
抱怨者：這類人不問問題。他們一直一直抱怨，直到問題消失。如果情況沒有變好，那就有了更多的理由抱怨。
現在應該清楚的是，一個精心準備的問題（簡明扼要，簡單，簡短，但有足夠的細節）將會產生更佳的答案。如果你確切知道對於該問題你需要學習什麼，那麼更有可能得償所願。
image
2.學習如何不提出問題
實際上，最好儘量避擴音問。或許你可以自己弄清楚呢？當然情況並不總是如此。許多事情你根本無法知道，通過詢問領域專家，有助於找到抵達成功最快和最有效的途徑。但是，經常自己去嘗試解決問題有很多好處：
-
通過這種艱辛的方法學到的東西能夠更好地儲存到記憶中——我們將牢牢記住所學到東西。
-
自己去尋找答案更有價值。
-
你不會製造“噪音”。還記得前面所說的“話匣子”嗎？除非你詢問的人有責任回答問題（從而推遲他們的工作），否則他們可能會在不瞭解你的思維過程的情況下，來嘗試回答每一個不完整的“問題”。這對任何人都沒有幫助。
-
通過推遲問問題（至少一段時間），你可以收集更多的相關資訊，然後提供給可能能夠回答問題的人。想想“完美主義者”，他們首先花更多時間尋找細節，然後自己解答問題。
-
通過訓練你可以更擅於提問。這需要時間。
image
3.不要遺留破碎的窗戶
有一篇非常有趣的文章，是關於不要留下破窗戶的。文章的本質是永遠不要妥協於質量。永遠不要成為逃兵。永遠不要遺留…破碎的窗戶。以下引用自這篇文章：
“當我們採取一些捷徑在最短的時間內提供一些東西時，反映了我們的粗心大意的程式碼會讓我們之後的開發人員（來自同一個團隊，未來的團隊，甚至我們自己！）得出一個重要的結論：對我們所生產的程式碼付出足夠的關注並不重要。應用程式漸漸開始惡化將是一個不可阻擋的過程。”
其實，這並非意味著要成為一個完美主義者。有時，修復破碎的窗戶是可以推遲的。但是，通常情況下，對於允許窗戶被打破和保持打破狀態，沒有人會覺得開心。我們程式設計師不開心，我們的客戶不開心，我們的使用者不開心，我們的專案經理也不開心。這是一種態度，是作為專業人士的核心內容。
Benjamin Franklin怎麼看呢？
“低價格的甜蜜被遺忘之後，低質量的苦澀將回味悠長。”
一切都是如此。“低價”是我們用一種草率的方式來實現某些東西而獲得的快速勝利。
image
4.軟體應該是確定性的。這就是要瞄準的目標！
在理想化的世界中，軟體中的一切都應該是“確定性的”。我們都應該是函式式程式設計師，編寫沒有副作用的純粹的函式。如String.contains()。無論執行以下操作多少次：
assertTrue("abcde".contains("bc"));
…結果總是相同的，都是預期的結果。哪怕宇宙爆炸對這一計算也沒有影響。這是確定性的。
我們也可以在我們自己的程式中，而不僅僅是在標準庫中做到這一目標。我們可以嘗試儘可能多地編寫無副作用的確定性模組。這真的與我們選擇什麼技術無關。
確定性程式設計可以用任何語言完成——即使函式語言有更多工具也可以通過更復雜的型別系統來防止意外的副作用。但是我所示的例子是一個Java示例。物件方向允許確定性。對的，像PL / SQL這樣的程式語言允許確定性。如果要在索引中使用函式，那麼需要請求確定性的函式：
CREATE INDEX upper_first_name ON customer (upper (first_name)); -- Deterministic function here: -----------^^^^^^^^^^^^^^^^^^
這又是一個規則問題。有副作用的過程/方法/“函式”是為“破窗戶”。有副作用也許會更容易維護，當然希望最終可以消滅副作用。但這通常是自己騙自己。當將來的某一天意外突現的時候，就是你付出昂貴代價的時候。別不相信，說曹操曹操就到。
image
5.接受意料之外的事情
程式設計師始終應該遵守墨菲定律。一切都可能被打破。並且它即將被打破。作為軟體工程師，我們應該謹記它是會破掉的。因為我們的世界是不確定的，所以我們正在實現的業務需求也是不確定的。我們只有在終於能夠確定的時候，才能實現技巧#4（確定論）。否則，我們將不可避免地進入不確定論的世界（也就是“現實世界”），即一個將會出錯的世界。所以，要以此為基礎。接受意料之外的事情。訓練你內心的洪荒之力，從積極的角度預見各種麻煩。
當然，如何以簡潔的方式寫程式碼來預見各種麻煩就是另一個故事了。如何從那些可能會失敗的東西（因此不需要處理）中辨別那些將會失敗的東西（因此需要處理），還是需要通過一些實踐滴。
image
6.不要貨物崇拜。不要教條主義。始終具體情況具體對待。
所有教給你的內容都存在潛在的錯誤。即使是那些流行語。引用一句很不錯的話：
“我的職業生涯至少有50％是為了幫助或解脫由教條主義引發的一個個災難。
我們的職業充滿了虛假。我們喜歡把自己當作數學家，堅持最純粹的思想，認為它們一定是正確的。
那是一條歧路。我們的職業構建在數學的基礎之上，但除非你進入範疇論或關係代數的時髦世界（即便你真的進入，我也懷疑一切是否是“正確的”），否則你就得面對現實世界務實的業務需求。好吧，坦率地說，這離完美還有十萬八千里。讓我們來看看一些最流行的程式語言：
- Java
- SQL
你真的覺得這些語言一點都不像數學嗎？行，不如我們先來討論段錯誤，Java泛型和SQL三值邏輯。這些語言是由實用主義者建立的平臺。所有這些都有一些非常酷的理論背景，但最終，還是有了這些工具。
對於建立在語言之上的所有東西也是如此：庫，框架，設計模式，甚至架構。沒有什麼是對的或是錯的。一切都是為某些上下文設計的工具。想想在其上下文中的工具。永遠不要把這個工具當成一個獨立的理由。我們不是“為藝術而藝術”。
所以對這些質疑說不：
- XML
- JSON
- 功能程式設計
- 面向物件程式設計
- 設計模式
- 微服務
- 三層架構
- DDD
- TDD
- 實際上：*DD
- 不勝列舉
所有這些都是某些給定上下文的好工具，但並不總是如此，要學會具體情況具體對待。保持好奇心，開發創造力，知道何時才需要使用這些工具，將有助於你成為一個更優秀的程式設計師。
image
7.就是幹
這是真理。話說，總有一些牛人出類拔萃，能夠傲視群雄，讓人鞭長莫及。
但大多數程式設計師只達到“好”的級別，或是有潛力達到“好”的程度。那麼怎麼才能成為一名好的程式設計師呢？正如羅馬不是一天建成的，偉大的軟體也不是一天可以寫成的，受歡迎的人並非我們這個時代唯一的英雄。我遇到過許多默默無聞但偉大的程式設計師，他們孜孜不倦地攻克軟體難題，解決了許多小公司隱蔽的問題。
偉大的程式設計師都有一個共同點：遇到問題就是幹。練習，實踐。每天都致力於工作與學習，然後變得越來越優秀。
想要更擅長SQL？那就幹吧！每天都嘗試用一些新功能編寫一個SQL語句。使用window functions。分組。遞迴。分割槽的外連線。MODEL和/或MATCH_RECOGNIZE子句。不需要每次都交付生產，就是為了實踐。這些都是有價值的。
image
8.專注一個主題（從長遠的角度）
可能只有很少一部分“優秀的”全棧開發人員獨領風騷。事實上，大多數全棧開發人員都將位於中間水平。當然，一個小團隊可能只需要幾個全棧開發人員，就可以涵蓋很多業務邏輯，快速推出一個新的軟體。但是，軟體將非常笨拙，“馬馬虎虎能工作”。也許這對於只要可行即可的產品階段來說就已足夠，但從長遠來看，會導致全棧開發人員將沒有時間來正確分析（或預見！）更復雜的問題。
主要專注一個主題，並真正擅長這個方面。真金不怕火來煉，只要你有本事，那麼走到哪裡都需要。所以，致力於你的職業生涯，做一些真正好的東西，而不是“差不多就行”。
image
9.涉獵廣泛
雖然你應該主要關注一個主題，但不應該完全遺忘其他方面。你永遠不能馬上真正擅長SQL、擴大、擴充套件、低階效能、CSS、面向物件、需求工程、架構等等的所有內容（見技巧#8）。這是不可能的。
但你至少應該明白它們每一個的本質。你需要明白何時SQL是正確選擇（以及何時不是）。何時低級別效能的調整很重要（何時不是）。CSS原則上如何工作。面向物件、FP優點。等等。
你應該花一些時間涉獵這些（以及更多）概念和技術，以便更好地瞭解它們的重要性。知道何時應用它們，然後再找專業人士來實際執行工作。
涉獵新的正規化和技術，有助於你用全然不同的思維方式思考，可能你會在以後的日常工作中不自覺地以某種方式用到它們。
image
10.保持簡單，傻瓜式
愛因斯坦曾說：
“Everything should be made as simple as possible, but no simpler.”
（“任何事情都應該儘可能簡化,直到沒法再簡化為止。”）
沒有人能夠處理巨大的複雜性。在軟體中不能，在生活的任何其他方面也不能。複雜性是好軟體的殺手，因此簡單性是使能者。易於明白。難於實現。你需要大量時間和實踐才能識別和生產出簡單。當然，你可以遵循許多規則來實現簡單化。
最簡單的規則之一就是使用只有幾個引數的方法/函式。讓我們來看看吧。前面提到的String.contains()方法就是如此。我們可以寫”abcde”.contains(“bcd”)，不閱讀任何文件，每個人都能立即瞭解這做什麼以及為什麼。該方法做了一件事情，並且只做這一件。沒有複雜的上下文/設定/其他傳遞給該方法的引數。沒有“特殊情況”，也沒有任何警告。
此外，在庫中簡化比在業務邏輯中要簡單得多。那麼我們能實現嗎？也許吧。通過實踐。通過重構。但像偉大的軟體一樣，簡單性也不是一天可以搞定的。
（高階技巧：應用康威定律。在一個業務超級複雜的環境中編寫又好又簡單的軟體是完全不可能的。要麼你選擇複雜性和醜陋，要麼你最好擺脫那個業務）。
image
最後，給大家推薦一個 前端學習進階內推交流群685910553 （前端資料分享），不管你在地球哪個方位，
不管你參加工作幾年都歡迎你的入駐！（群內會定期免費提供一些群主收藏的免費學習書籍資料以及整理好的面試題和答案文件！）
如果您對這個文章有任何異議，那麼請在文章評論處寫上你的評論。
如果您覺得這個文章有意思，那麼請分享並轉發，或者也可以關注一下表示您對我們文章的認可與鼓勵。
願大家都能在程式設計這條路，越走越遠。