想法和問題

當程序員已經處于中級時，應如何提高自己？有很多關于“學習編程”的資源，能夠讓人從0到新手（雖然這些資源中大多數的質量是值得商榷的），但是怎么樣才能將中級水平提高到專家級？如何構建允許我在高級別編寫代碼的心理模型？

在這篇文章中，我將討論關于普遍性能改進的一些理論，然后討論一些程序員用于實踐的方法（以及我對這些實踐的想法），然后是我對改進成為中級或更優秀程序員的***方法所作出的結論。

[[184663]]

關于普遍性能改進的快速指南

我最近一直在閱讀大量關于性能改進的內容，大多數文獻使用K. Anders Ericsson的研究作為起點。他是性能研究的杰出面代表，幾乎在所有涉及這個主題的書中都被引用。他今年發表的書《Peak: Secrets from the New Science of Expertise》，濃縮其30多年的研究，易于理解，這也是我推薦給大多數新手的單個***資源。

簡要總結上下文：

• 改進任務的執行來自于開發更好的心理模式，更好的心理模式通過有意或有目的的實踐。
• 為了能夠實現改進，必須能夠定義什么構成改進性能并且分解實現步驟。
• 實踐和性能是不同的，***的實踐方法幾乎從不是性能。例如：一個想要提高擊中的棒球運動員應該花費30分鐘在練習場中練習200個投球（實踐），而不是用2個小時去比賽中觀看15個投球（性能）。

提高方法

我發現人們建議的大多數關于編程的改進方法就是基于性能的。閱讀代碼，閱讀關于代碼的內容，編寫代碼，做項目，談論代碼等等。如果他們在自己的工作之外做這些事情，那么程序員基本上肯定會有所提高，但似乎不是很有效率。

如果我想更擅長于編程，但每周我只想從自己的時間中花幾個小時致力于編程呢？什么是建立更佳心理模型的最有效方式，以便于我可以做出更明智的決定？ 《Peak》一書中關于刻意實踐的一個***例子是音樂家。想要提高特定樂器的技能或學習一首新的音樂，是有經過定義的，標準化的方式的；包括一個音樂家在幾個月的時間里學習一首新音樂的例子——每日只是刻意練習5分鐘。而在編程中，我們沒有大量的明確目標或改進措施（即：在某一段音樂作品的錯誤的數量），但其他的我發現都沒有這個比喻接近。

那么，我們如何得到我們作為程序員的性能反饋循環？是的，我們有特定片段代碼的反饋循環，無論代碼是否工作，它的性能和健壯性如何等等。我們對于系統的穩健性有一個更長的反饋循環，因為它們在負載下會跌倒或隨著時間的推移會變得笨拙。但是我們并不經常得到問題方法的實時反饋。

下面是我用來學習編程的方法，有些地方很不錯，也有些地方值得改進：

通過編程挑戰實踐

我享受于編程挑戰，但一般來說，我發現它們不值得去接觸一種新的編程語言。它們提供弱反饋循環——你的程序要么產生正確的輸出要么不產生——并且不會給你對設計過程的反饋。這個方法可能會介紹一個新的算法或一個你不熟悉的語言的新功能，但在實踐方面，很弱。比起“實踐”，它更接近于“性能”，并且你處理的是人為的問題，而不是真正的問題。

我發現的一個例外是由@ericwastl的Advent Of Code。編程問題很好地模擬了現實生活中的問題（需求定義明確，但是邊緣情況沒有寫入規范并且必須隱含），并且對于解決方案有多么設計良好具備即時反饋，因為對每個拋出額外需求或一些其他困難的問題有part 2，這意味著你必須重新評估你的原始解決方案有多少精心設計。這并不***，但我喜歡看到我的解決方案具有挑戰性，并且經常不得不重新考慮我的解決方案的結構和設計，當我達到part 2的時候。

做業余項目

做業余項目，如果你有一個的話，將是投入額外編程時間的偉大方式；如果你做一些你喜歡的事情的話，你就不會覺得這像工作。不幸的是，因為項目參差不齊，所以你可能不會真正學到東西。如果你的業余項目與想要學習的編程內容相一致的話，那么恭喜你，這是一個好選擇，否則它只是性能vs實踐的另一個版本。即使在***的情況下，如果主要目標是生產某種東西，那就意味著實踐和學習得排在后面。

閱讀關于編程實踐的書

閱讀編程書籍是一個快速提升知識的很好方式，我認為它應該是幾乎任何“提高編程”方案的一部分。然而，它并非是讓人能夠一勞永逸的銀彈。純粹的知識獲取可以幫助你知道有哪些可用的選項，當你碰到某個問題的時候，但知識不能代替更好的心理模型。

最終建議

不幸的是，我沒有能夠得出具體的結論。也許答案是，需要有編程教練或導師，以便可以得到針對性的反饋和具體的實踐建議。也許這學科還太年輕，沒有正式的性能改進方法，不像古典音樂訓練和運動訓練。

在評論中告訴我你的想法。我特別想聽聽那些通過教學/訓練/指導而高水平產出的程序員的看法，或者在這樣的老師下學習的人。

如果我對程序員的性能改進有任何更明確的想法，一定會再寫一個后續帖子。謝謝閱讀。