編譯自： http://matthewrocklin.com/blog/work/2018/01/27/write-dumb-code

作者： Matthew Rocklin

譯者： Tian, Hua

為開源項目作貢獻最好的方式是為它減少代碼，我們應致力於寫出讓新手程序員無需注釋就容易理解的代碼，讓維護者也無需花費太多精力就能著手維護。

在學生時代，我們會更多地用複雜巧妙的技術去挑戰新的難題。首先我們會學習循環，然後是函數啊，類啊，等等。當我們到達一定高的程度，能用更高級的技術寫更長的程序，我們會因此受到稱讚。此刻我們發現老司機們用 monads 而新手們用 loop 作循環。

之後我們畢業找了工作，或者和他人合作開源項目。我們用在學校里學到的各種炫技尋求並驕傲地給出解決方案的代碼實現。

哈哈，我能擴展這個項目，並實現某牛 X 功能啦，我這裡能用繼承啦，我太聰明啦！

我們實現了某個小的功能，並以充分的理由覺得自己做到了。現實項目中的編程卻不是針對某某部分的功能而言。以我個人的經驗而言，以前我很開心的去寫代碼，並驕傲地向世界展示我所知道的事情。有例為證，作為對某種編程技術的偏愛，這是用另一種元編程語言構建的一個 線性代數語言 ，注意，這麼多年以來一直沒人願意碰它。

在維護了更多的代碼後，我的觀點發生了變化。

1. 我們不應去刻意探求如何構建軟體。軟體是我們為解決問題所付出的代價，那才是我們真實的目的。我們應努力為了解決問題而構建較小的軟體。
2. 我們應使用儘可能簡單的技術，那麼更多的人就越可能會使用，並且無需理解我們所知的高級技術就能擴展軟體的功能。當然，在我們不知道如何使用簡單技術去實現時，我們也可以使用高級技術。

所有的這些例子都不是聽來的故事。我遇到的大部分人會認同某些部分，但不知為什麼，當我們向一個新項目貢獻代碼時又會忘掉這個初衷。直覺里用複雜技術去構建的念頭往往會佔據上風。

軟體是種投入

你寫的每行代碼都要花費人力。寫代碼當然是需要時間的，也許你會認為只是你個人在奉獻，然而這些代碼在被審閱的時候也需要花時間理解，對於未來維護和開發人員來說，他們在維護和修改代碼時同樣要花費時間。否則他們完全可以用這時間出去晒晒太陽，或者陪伴家人。

所以，當你向某個項目貢獻代碼時，請心懷謙恭。就像是，你正和你的家人進餐時，餐桌上卻沒有足夠的食物，你只索取你所需的部分，別人對你的自我約束將肅然起敬。以更少的代碼去解決問題是很難的，你肩負重任的同時自然減輕了別人的重負。

技術越複雜越難維護

作為學生，逐漸使用高端技術證明了自己的價值。這體現在，首先我們有能力在開源項目中使用函數，接著是類，然後是高階函數，monads 等等。我們向同行顯示自己的解決方案時，常因自己所用技術高低而感到自豪或卑微。

而在現實中，和團隊去解決問題時，情況發生了逆轉。現在，我們致力於盡可能使用簡單的代碼去解決問題。簡單方式解決問題使新手程序員能夠以此擴展並解決其他問題。簡單的代碼讓別人容易上手，效果立竿見影。我們藉以只用簡單的技術去解決難題，從而展示自己的價值。

看，我用循環替代了遞歸函數並且一樣達到了我們的需求。當然我明白這是不夠聰明的做法，不過我注意到新手同事在這裡會遇上麻煩，我覺得這種改變將有所幫助吧。

如果你是個好的程序員，你不需要證明你知道很多炫技。相應的，你可以通過用一個簡單的方法解決一個問題來顯示你的價值，並激發你的團隊在未來的時間裡去完善它。

當然，也請保持節制

話雖如此，過於遵循 「用簡單的工具去構建」 的教條也會降低生產力。通常用遞歸會比用循環解決問題更簡單，用類或 monad 才是正確的途徑。還有兩種情況另當別論，一是只是只為滿足自我而創建的系統，或者是別人毫無構建經驗的系統。

via: http://matthewrocklin.com/blog/work/2018/01/27/write-dumb-code

作者： Matthew Rocklin 譯者： plutoid 校對： wxy

本文由 LCTT 原創編譯， Linux中國 榮譽推出

點擊「了解更多」可訪問文內鏈接

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！