一位 20 年老程序員分享的編程經(jīng)驗(yàn)突然火了，在 Hacker News 上，一天之內(nèi)就收獲了 467 熱度。
這位老哥從 1999 年就開始編程，從早期的 Basic、Pascal、Delphi，到后來的 C，C++ ，JavaScript 等主流語言都用過。職業(yè)生涯上從研究員、架構(gòu)師一直干到過 CTO，另外也當(dāng)過技術(shù)產(chǎn)品經(jīng)理，技術(shù)指導(dǎo)，老師等角色，可謂經(jīng)驗(yàn)豐富。
其實(shí)這篇帖子所包含的觀點(diǎn)大都是編程圈子里較常見的概念，但是這些年來有的話題一直很具備爭議性。對他的大多數(shù)經(jīng)驗(yàn)，網(wǎng)友很贊同。比如：代碼終究還是給人寫的，注釋是為了讓未來的自己和其他同事能看懂。
不過針對有的觀點(diǎn)，大家各執(zhí)己見。最為突出的是下面這條，網(wǎng)友們對此討論了 60 多樓：
要完全搞清楚要解決的問題，否則就先別急著敲代碼。
一種有代表性的觀點(diǎn)是：
大體上同意，但我發(fā)現(xiàn)要真正完全理解一個(gè)問題，還是至少要先寫一個(gè)解決方案。
因?yàn)楫?dāng)我把一個(gè)問題分解成可編碼的組件時(shí)，我學(xué)到了很多；在實(shí)際實(shí)現(xiàn)這些部分的過程中，我經(jīng)常發(fā)現(xiàn)邊緣情況或未定義的情況；現(xiàn)實(shí)情況下，真正的問題是什么，通常在開始并不清楚。
但也有一些網(wǎng)友認(rèn)為：對于小型的、偏算法的問題，先在紙上或腦海中過一遍，比上來就寫代碼有效率的多。emmm…… 這樣討論下去簡直成了“先有雞還是先有蛋”。這個(gè)問題看來不會有確定的答案了，不過這篇經(jīng)驗(yàn)分享整體上還有更多有價(jià)值的觀點(diǎn)。
下面讓我們具體來看看吧。
20 年濃縮成 20 條經(jīng)驗(yàn)
1. 不要與工具作斗爭
所謂工具，包括庫、語言、平臺等。盡可能多地使用原生的開發(fā)方式。這樣可以保證程序或軟件的數(shù)據(jù)都存在于本地，能夠及時(shí)檢索，保證程序或軟件的合作速度和流暢度。不要被技術(shù)捆綁，也不要被問題捆綁。應(yīng)該為工作選擇合適的工具，而不是為了工具尋找合適的工作。
舉個(gè)例子：編程實(shí)現(xiàn)在一個(gè)文件中找到給定單詞出現(xiàn)的位置并統(tǒng)計(jì)出現(xiàn)次數(shù)。如果用 C++ 寫的話需要 92 行代碼，而使用 Python 的話只用 26 行代碼就可以完成了。
由此可見，對于同一個(gè)問題，換一個(gè)工具也許可以簡化編程，提高效率。
2. 寫讓人可以看懂的代碼
程序員們不是為機(jī)器編寫代碼，而是為了同行們和未來的自己編寫代碼。寫代碼的終極目標(biāo)往往是完成一個(gè)項(xiàng)目或給后來者作為參考。
3. 善于合作
任何重要且有價(jià)值的軟件都是協(xié)作的結(jié)果，有效溝通和公開合作很重要。能用眾智，則無畏于圣人矣。
4. 對各模塊分而治之
編寫相互聯(lián)系卻又彼此保持獨(dú)立的單個(gè)模塊。先分別測試每個(gè)部分，然后一起集成測試。既要保證測試接近實(shí)際，也要測試邊緣實(shí)例。
5. 敢于分享自己的原創(chuàng)代碼
一個(gè)程序員不要成為那位唯一明白某段代碼的人。可以對自己的原創(chuàng)代碼進(jìn)行優(yōu)化，以便人們找到修復(fù) Bug 的方式，和向代碼添加功能的方法。這樣也能使程序員自己輕松點(diǎn)，以早點(diǎn)進(jìn)入下一個(gè)項(xiàng)目或公司。想要提高水平的話，不要使一段代碼僅自己可見。
6. 安全是分層的
分層安全是一種應(yīng)用多種安全措施的實(shí)踐，每一層都與前一層和下一層重疊，以創(chuàng)建一個(gè)安全控制網(wǎng)絡(luò)，這些網(wǎng)絡(luò)可以一起工作以保護(hù)技術(shù)系統(tǒng)。每一層都需要單獨(dú)評估，但也需要與整體相關(guān)。
風(fēng)險(xiǎn)是一種商業(yè)決策，與脆弱性和概率有直接關(guān)系。每個(gè)產(chǎn)品或組織都有不同的風(fēng)險(xiǎn)偏好，通常這三個(gè)關(guān)注點(diǎn)會相互沖突：用戶體驗(yàn)、安全性和性能。
7. 代碼也有生死
要認(rèn)識到，每段代碼都有一個(gè)生命周期，并且會最終失效。有時(shí)，一段代碼甚至還沒上線發(fā)布就被廢棄了。程序員要學(xué)會放手，弄明白 4 類特征的區(qū)別，然后想清楚應(yīng)該在哪些方面投入時(shí)間和精力：
核心：就像汽車的引擎。沒有它，產(chǎn)品就沒有意義。
必要之處：就像汽車的備用輪子。它很少被使用，但當(dāng)需要時(shí)，它的功能決定了系統(tǒng)的成功。
附加值：就像汽車的杯座。有它很好，但產(chǎn)品沒有它也完全可用。
獨(dú)特賣點(diǎn)：人們應(yīng)該購買你的產(chǎn)品而不是你的競爭對手的主要原因。
8. 保護(hù)好個(gè)人信息
程序員不要將個(gè)人身份信息附加到代碼中，也不要把其他人的身份附加到他們的代碼上。人是獨(dú)立于他們的工作產(chǎn)出物之外的。不要把對代碼的批評當(dāng)成是針對個(gè)人的，當(dāng)然也在批評他人的代碼時(shí)也要謹(jǐn)慎。
9. 盡量規(guī)避技術(shù)債務(wù)
技術(shù)債務(wù)是開發(fā)團(tuán)隊(duì)在設(shè)計(jì)或架構(gòu)選型時(shí)，為了快速地解決問題，而采取的不規(guī)范的方案。偶爾的技術(shù)債務(wù)是可以接受的，但如果長期負(fù)債往往會快速地扼殺產(chǎn)品。
10. 可參考以下優(yōu)先級
為解決方案做決定時(shí)，假設(shè)其他條件都是一樣的，可以按照這個(gè)優(yōu)先級：
安全性 > 可用性 (可訪問性和用戶體驗(yàn)) > 可維護(hù)性 > 簡單性（開發(fā)人員體驗(yàn) / DX）> 簡短性（代碼長度） > 性能
但是也不要盲目地遵循這個(gè)規(guī)則，還要考慮到產(chǎn)品的性質(zhì)。例如，在設(shè)計(jì)游戲引擎時(shí)，性能是最重要的；但在創(chuàng)建銀行應(yīng)用程序時(shí)，安全性是最重要的因素。
11. 復(fù)制粘貼會帶來 Bug
有時(shí)復(fù)制粘貼后，會出現(xiàn) Bug，這個(gè)幾乎無法避免。為了檢查是否有問題，每次都需要搞明白復(fù)制過來的內(nèi)容，并審核導(dǎo)入的內(nèi)容。
12. 不要只為樂觀場景寫代碼
還要寫出好的錯(cuò)誤提示，回答其為什么會發(fā)生，如何檢測到它，以及如何解決它。
13. 盡量不要使用依賴庫
若調(diào)用一個(gè)動(dòng)態(tài)庫 A 時(shí)，A 需要調(diào)用動(dòng)態(tài)庫 B，則 B 是 A 的依賴庫。
盡量不要使用依賴庫，除非導(dǎo)入、維護(hù)、處理邊界情況時(shí)出現(xiàn) Bug，或者當(dāng)代碼不滿足需求時(shí)，重構(gòu)的成本遠(yuǎn)遠(yuǎn)低于你擁有的代碼。
14. 不要盲目跟風(fēng)
可以去了解熱炒的新技術(shù)，但不要被拽著走，要堅(jiān)持自己對技術(shù)的品位。
15. 堅(jiān)持學(xué)習(xí)
16. 最好的代碼都有良好的注釋
一些人認(rèn)為，代碼寫的夠好，就不用寫注釋了。但最優(yōu)秀的的代碼中往往都包含著良好的注釋。這樣，即使是沒有經(jīng)歷過這段代碼的調(diào)試、測驗(yàn)過程，且暫時(shí)不具備寫出此代碼能力的人都可以使用它。
可以說，未文檔化的功能是不存在的功能，不存在的功能不該有代碼。
17. 盡量避免重寫、繼承和隱藏信息
寫純函數(shù) (Pure Function)。對于純函數(shù)，相同輸入總是會返回相同的輸出，執(zhí)行過程中不產(chǎn)生副作用，且不依賴于外部狀態(tài)。它們更容易測試和推理。
在執(zhí)行一個(gè)非純函數(shù)時(shí)，除了得到函數(shù)的返回值以外，還在函數(shù)調(diào)用時(shí)產(chǎn)生了附加的影響，如：修改了全局變量的狀態(tài)，修改了傳入的參數(shù)等。
任何非純函數(shù)都應(yīng)該是類，任何具有不同函數(shù)的代碼構(gòu)造都應(yīng)該具有不同的名稱。
18. 弄清楚問題后再開始編程
面對一個(gè)問題，首先要弄清解決思路，再開始編程。在編程過程中還需要逐步經(jīng)歷“編碼-測試-改進(jìn)”周期，并不斷深入探索，直到完成。
19. 不要去解決不存在的問題
不要進(jìn)行投機(jī)性編程。只有在確定代碼將來會被擴(kuò)展時(shí)，才去花功夫提高代碼的擴(kuò)展性。
因?yàn)楫?dāng)代碼要被擴(kuò)展時(shí)，有很大的可能性問題定義已經(jīng)與代碼初次編寫時(shí)不同了。
20. 巧用社區(qū)、積極探討
合作完成一個(gè)程序或軟件往往更有趣。許多程序員包括技術(shù)大牛們都會在一些專業(yè)論壇（如 Github、Stackoverflow 等）上分享自己的原創(chuàng)代碼，供他人參考、提建議以及修復(fù) Bug。
除了利用已有的論壇、網(wǎng)站外，還可以為自己的項(xiàng)目創(chuàng)建一個(gè)良好的社區(qū)。
這 20 條建議中是否有讓你受到啟發(fā)的？你還有哪些編程經(jīng)驗(yàn)可以分享？
參考鏈接
[1]. https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c
[2]. https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22
廣告聲明：文內(nèi)含有的對外跳轉(zhuǎn)鏈接（包括不限于超鏈接、二維碼、口令等形式），用于傳遞更多信息，節(jié)省甄選時(shí)間，結(jié)果僅供參考，IT之家所有文章均包含本聲明。