20年程式設計師經驗分享:怎麼提高工作效率?看這20 條編碼原則!

yilian發表於2020-03-23
20年程式設計師經驗分享:怎麼提高工作效率?看這20 條編碼原則!

英文原文:My guiding principles after 20 years of programming

我從 1999 年就開始了程式設計生涯,到今年已經有 20 多年了。我先是從 Basic 開始,很快轉到了 Pascal 和 C 語言,然後又學習了物件導向程式語言 Delphi 和 C++。2006 年,我開始使用 Java,2011 年開始使用 JavaScript。

我參與過各個行業的軟體開發,從機器人、金融科技、醫療到媒體和通訊。我還擔任過研究員、CTO、TPM(技術產品經理)、老師、系統架構師和技術負責人,但不管怎樣,我一直都在程式設計。

在我參與過的專案當中,有些為數百萬人提供服務,有些在釋出之前就宣告失敗。我做過諮詢顧問,還創辦過自己的公司。我在開源專案、閉源專案和內部開源專案上花了很多時間,從微控制器到移動應用、桌面應用,再到雲服務和無伺服器架構。


我把過去 20 年積累的一些最為重要的程式設計原則總結如下。

  1. 不要糾結於開發工具——不管是庫、程式語言還是平臺。儘可能使用原生的構件。不要歪曲技術,也不要歪曲了問題本身。為要解決的問題選擇合適的工具,否則你要為你所選擇的工具重新安排你的工作。
  2. 你寫的程式碼不是給機器看的,而是給你的同事和未來的你看的(除非你寫的是一次性程式碼或彙編程式碼)。寫程式碼的時候要考慮一下初級開發者,他們會把你的程式碼作為參考。
  3. 優秀的軟體是協作開發的結果。高效溝通,進行開放式的協作。信任他人,並讓他人也信任你。尊重他人勝過尊重程式碼。以身作則,把你的追隨者變成領導者。
  4. 分而治之。為分離的關注點開發單獨的低耦合模組。進行單獨的模組測試和整合測試。儘可能按照實際情況測試,同時也要測試到各種邊界情況。
  5. 不要把自己與程式碼捆綁在一起,要想辦法讓其他人也能修改你的程式碼或者新增新的功能,這樣你才能更容易脫身去參與其他專案,或者去其他公司。不要捆綁自己,否則你很難成長。
  6. 安全性是分層的,每一層需要進行單獨的評估,同時又與整體相關。風險是一個業務決策,與脆弱性和機率有直接的關係。每一個產品或組織都有不同的風險偏好(為了獲得更大的收益,他們願意承擔風險)。通常這三個關注點之間存在相互衝突:使用者體驗、安全性和效能。
  7. 要意識到每一行程式碼都有其生命週期,它們最終都會死掉。有時候,一些程式碼會在釋出之前就死掉,所以要學會放手。程式碼可以分為三種:一種是核心程式碼,就像汽車的引擎,沒有了它,產品就毫無意義;一種是必要的程式碼,就像是汽車的備胎,平時用得少,但一旦需要,它決定了系統的成敗;一種是增值的程式碼,就像汽車的杯託,如果有那是再好不過,但如果沒有也不會影響產品。
  8. 不要把你的個人標識融入到程式碼裡,人和程式碼應該是分離的。不要把其他人對程式碼的評價與你自身聯絡到一起,在評價他人的程式碼時也要十分謹慎。
  9. 技術債務就像快餐一樣,偶爾欠下一點技術債務是可接受的,但如果你習慣了這樣,它會毀掉你的產品(而且是以讓你措手不及的方式)。
  10. 在尋找解決方案時,請按照這樣的優先順序進行決策:安全性 > 可用性(可訪問性和使用者體驗)> 可維護性 > 簡單性(開發者體驗)> 簡潔性(程式碼量)> 效能。但不能盲目照搬,而是要根據產品的特點進行取捨。你積累的經驗越多,就越是能夠在這些因素之間做出權衡。例如,在設計遊戲引擎時,效能享有最高的優先順序,但在開發銀行應用程式時,安全性則最為重要。
  11. 複製貼上是滋生 bug 的溫床。對你所複製或匯入的東西加以審查,bug 一般會藏身在複雜性中。依賴項複雜沒有關係,但不能讓它存在於程式碼中。
  12. 不要只顧著寫正常的程式碼,處理異常的程式碼也要好好寫。讓人們明白為什麼會發生異常、如何檢測到的以及怎樣解決。對所有的系統輸入(包括使用者輸入)進行驗證:儘早失敗,並儘可能從錯誤中恢復。我們要假設使用者手裡握著一把槍:你努力讓使用者輸入一些其他的東西,而不是讓他們 射在你的腦門上。
  13. 不要使用依賴項,除非使用它們的成本比你自己寫程式碼的成本低很多。因為使用依賴項要匯入、維護、處理 bug,在必要的時候還要進行重構,這些都是成本。
  14. 遠離“炒作驅動開發”,但你要去了解它們,做一些嘗試。
  15. 走出舒適區,每天都要學習。把學到的東西分享出來。如果你以大師自居,就不是在學習。接觸更多的程式語言、技術、文化,保持一顆好奇心。
  16. 好程式碼不需要註釋,而優秀的程式碼提供了良好的註釋,可以讓任何一個原先沒有參與程式碼演進、試錯和需求過程的人更容易閱讀、修改它。
  17. 儘量避免使用過載、繼承和隱式的智慧特性。使用純函式,它們更容易測試和診斷,否則的話就使用類。實現不同功能的函式要使用不同的名字。
  18. 在徹底瞭解問題之前不要急著寫程式碼。花在傾聽和了解問題上的時間通常比花在寫程式碼上的時間要多。在寫程式碼之前要先了解問題域。問題就像迷宮一樣,你要循序漸進,反覆進行“編碼 - 測試 - 改進”,直到把問題解決為止。
  19. 不要嘗試去解決不存在的問題。不要進行投機性程式設計。只有在確定程式碼確實需要具備擴充套件性之後才讓程式碼具備可擴充套件性。通常情況下,當程式碼被擴充套件之後,你會發現問題會變得與原先認為的不一樣了。
  20. 大家一起開發軟體會更加有趣。建立可持續發展的社群。傾聽,激發靈感,學習,分享。

我並不是軟體開發方面的權威,但這些都是我一路走來總結出來的原則。我相信,20 年後,這些原則會發生變化,會變得更加成熟。

讀者福利

分享針對位元組跳動的面試題整理的解析PDF,進行了分類,循序漸進,由基礎到深入,由易到簡。

我們將內容整理成了五個章節、計算機基礎面試題、資料結構和演算法面試題、Java面試題、Android面試題、其他擴充套件面試題、非技術面試題總共五個章節354頁。

20年程式設計師經驗分享:怎麼提高工作效率?看這20 條編碼原則!

每個問題都附上1個標準參考答案,都是反覆摸索消化(真心花了很多時間),覺得寫的比較好的文章作為答案。

來節省大家自己去搜尋的時間,把時間用在正確的東西上。。

還整理了全套簡歷製作、春招困惑、HR面試等問題解析參考建議。

20年程式設計師經驗分享:怎麼提高工作效率?看這20 條編碼原則!

位元組跳動面試真題解析&簡歷製作PDF模板可以私 信我【位元組跳動】免費獲取!

分享不易!喜歡的朋友別忘了關注+點贊支援下!


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69952849/viewspace-2682093/,如需轉載,請註明出處,否則將追究法律責任。

相關文章