一位 20 年老程式設計師分享的程式設計經驗突然火了，在 Hacker News 上，一天之內就收穫了 467 熱度。

這位老哥從 1999 年就開始程式設計，從早期的 Basic、Pascal、Delphi，到後來的 C，C++ ，Javasript 等主流語言都用過。職業生涯上從研究員、架構師一直幹到過 CTO，另外也當過技術產品經理，技術指導，老師等角色，可謂經驗豐富。

其實這篇帖子所包含的觀點大都是程式設計圈子裡較常見的概念，但是這些年來有的話題一直很具備爭議性。對他的大多數經驗，網友很贊同。比如：程式碼終究還是給人寫的，註釋是為了讓未來的自己和其他同事能看懂。

不過針對有的觀點，大家各執己見。最為突出的是下面這條，網友們對此討論了 60 多樓：

要完全搞清楚要解決的問題，否則就先別急著敲程式碼。

一種有代表性的觀點是：

大體上同意，但我發現要真正完全理解一個問題，還是至少要先寫一個解決方案。

因為當我把一個問題分解成可編碼的元件時，我學到了很多；在實際實現這些部分的過程中，我經常發現邊緣情況或未定義的情況；現實情況下，真正的問題是什麼，通常在開始並不清楚。

但也有一些網友認為：對於小型的、偏演算法的問題，先在紙上或腦海中過一遍，比上來就寫程式碼有效率的多。emmm…… 這樣討論下去簡直成了“先有雞還是先有蛋”。這個問題看來不會有確定的答案了，不過這篇經驗分享整體上還有更多有價值的觀點。

下面讓我們具體來看看吧。

20 年濃縮成 20 條經驗

1. 不要與工具作鬥爭

所謂工具，包括庫、語言、平臺等。儘可能多地使用原生的開發方式。這樣可以保證程式或軟體的資料都存在於本地，能夠及時檢索，保證程式或軟體的合作速度和流暢度。不要被技術捆綁，也不要被問題捆綁。應該為工作選擇合適的工具，而不是為了工具尋找合適的工作。

舉個例子：程式設計實現在一個檔案中找到給定單詞出現的位置並統計出現次數。如果用 C++ 寫的話需要 92 行程式碼，而使用 Python 的話只用 26 行程式碼就可以完成了。

由此可見，對於同一個問題，換一個工具也許可以簡化程式設計，提高效率。

2. 寫讓人可以看懂的程式碼

程式設計師們不是為機器編寫程式碼，而是為了同行們和未來的自己編寫程式碼。寫程式碼的終極目標往往是完成一個專案或給後來者作為參考。

3.善於合作

任何重要且有價值的軟體都是協作的結果，有效溝通和公開合作很重要。能用眾智，則無畏於聖人矣。

4.對各模組分而治之

編寫相互聯絡卻又彼此保持獨立的單個模組。先分別測試每個部分，然後一起整合測試。既要保證測試接近實際，也要測試邊緣例項。

5. 敢於分享自己的原創程式碼

一個程式設計師不要成為那位唯一明白某段程式碼的人。可以對自己的原創程式碼進行優化，以便人們找到修復 Bug 的方式，和向程式碼新增功能的方法。這樣也能使程式設計師自己輕鬆點，以早點進入下一個專案或公司。想要提高水平的話，不要使一段程式碼僅自己可見。

6. 安全是分層的

分層安全是一種應用多種安全措施的實踐，每一層都與前一層和下一層重疊，以建立一個安全控制網路，這些網路可以一起工作以保護技術系統。每一層都需要單獨評估，但也需要與整體相關。

風險是一種商業決策，與脆弱性和概率有直接關係。每個產品或組織都有不同的風險偏好，通常這三個關注點會相互衝突：使用者體驗、安全性和效能。

7. 程式碼也有生死

要認識到，每段程式碼都有一個生命週期，並且會最終失效。有時，一段程式碼甚至還沒上線釋出就被廢棄了。程式設計師要學會放手，弄明白 4 類特徵的區別，然後想清楚應該在哪些方面投入時間和精力：

• 核心：就像汽車的引擎。沒有它，產品就沒有意義。

• 必要之處：就像汽車的備用輪子。它很少被使用，但當需要時，它的功能決定了系統的成功。

• 附加值：就像汽車的杯座。有它很好，但產品沒有它也完全可用。

• 獨特賣點：人們應該購買你的產品而不是你的競爭對手的主要原因。

8. 保護好個人資訊

程式設計師不要將個人身份資訊附加到程式碼中，也不要把其他人的身份附加到他們的程式碼上。人是獨立於他們的工作產出物之外的。不要把對程式碼的批評當成是針對個人的，當然也在批評他人的程式碼時也要謹慎。

9. 儘量規避技術債務

技術債務是開發團隊在設計或架構選型時，為了快速地解決問題，而採取的不規範的方案。偶爾的技術債務是可以接受的，但如果長期負債往往會快速地扼殺產品。

10. 可參考以下優先順序

為解決方案做決定時，假設其他條件都是一樣的，可以按照這個優先順序：

安全性 > 可用性 (可訪問性和使用者體驗) > 可維護性 > 簡單性（開發人員體驗 / DX）> 簡短性（程式碼長度） > 效能

但是也不要盲目地遵循這個規則，還要考慮到產品的性質。例如，在設計遊戲引擎時，效能是最重要的；但在建立銀行應用程式時，安全性是最重要的因素。

11. 複製貼上會帶來 Bug

有時複製粘貼後，會出現 Bug，這個幾乎無法避免。為了檢查是否有問題，每次都需要搞明白複製過來的內容，並稽核匯入的內容。

12. 不要只為樂觀場景寫程式碼

還要寫出好的錯誤提示，回答其為什麼會發生，如何檢測到它，以及如何解決它。

13. 儘量不要使用依賴庫

若呼叫一個動態庫 A 時，A 需要呼叫動態庫 B，則 B 是 A 的依賴庫。

儘量不要使用依賴庫，除非匯入、維護、處理邊界情況時出現 Bug，或者當代碼不滿足需求時，重構的成本遠遠低於你擁有的程式碼。

14. 不要盲目跟風

可以去了解熱炒的新技術，但不要被拽著走，要堅持自己對技術的品位。

15. 堅持學習

16. 最好的程式碼都有良好的註釋

一些人認為，程式碼寫的夠好，就不用寫註釋了。但最優秀的的程式碼中往往都包含著良好的註釋。這樣，即使是沒有經歷過這段程式碼的除錯、測驗過程，且暫時不具備寫出此程式碼能力的人都可以使用它。

可以說，未文件化的功能是不存在的功能，不存在的功能不該有程式碼。

17. 儘量避免重寫、繼承和隱藏資訊

寫純函式 (Pure Function)。對於純函式，相同輸入總是會返回相同的輸出，執行過程中不產生副作用，且不依賴於外部狀態。它們更容易測試和推理。

在執行一個非純函式時，除了得到函式的返回值以外，還在函式呼叫時產生了附加的影響，如：修改了全域性變數的狀態，修改了傳入的引數等。

任何非純函式都應該是類，任何具有不同函式的程式碼構造都應該具有不同的名稱。

18. 弄清楚問題後再開始程式設計

面對一個問題，首先要弄清解決思路，再開始程式設計。在程式設計過程中還需要逐步經歷“編碼-測試-改進”週期，並不斷深入探索，直到完成。

19. 不要去解決不存在的問題

不要進行投機性程式設計。只有在確定程式碼將來會被擴充套件時，才去花功夫提高程式碼的擴充套件性。

因為當代碼要被擴充套件時，有很大的可能性問題定義已經與程式碼初次編寫時不同了。

20. 巧用社群、積極探討

合作完成一個程式或軟體往往更有趣。許多程式設計師包括技術大牛們都會在一些專業論壇（如 Github、Stackoverflow 等）上分享自己的原創程式碼，供他人蔘考、提建議以及修復 Bug。

除了利用已有的論壇、網站外，還可以為自己的專案建立一個良好的社群。

這 20 條建議中是否有讓你受到啟發的？你還有哪些程式設計經驗可以分享？

參考連結

[1].https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c

[2].https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22