每個程序員都該知道的10大編碼原則

jopen 10年前發布 | 6K 次閱讀 程序員

英文原文: Coding Principles Every Engineer Should Know

        回顧我的職業生涯,我曾自己單槍匹馬地干過,也和一些特別有才能的人一起共事過,曾解決過一些非常嚴重的技術難題,也見識過一些鼎鼎大名的技術 公司。近期我和我的團隊偶然聊起我的這些經歷,談論的成果是我們在編碼時應該知道一些原則。這不是規矩,也不是指導方針。它們只是我在編寫和運行代碼時總 結出來的一些需要注意的原則。

每個程序員都該知道的10大編碼原則

        1. 偏執

        這一點與我而言幾乎是天生的。我幾乎是靠自學才成為了程序員。

        我從不相信電腦,也不相信我剛剛修復的 bug 真的已經修復好了,總之我不相信任何東西。我甚至連自己都不相信。除非多次檢驗之后,我才會相信我已經如我所愿地理解了問題。

        偏執是我的諍友,而且我認為它也應該成為我們每一個工程師的“左膀右臂”。我們要偏執的是,應該總是想著從另一種方式來證實假設,或者從另一個角度去看我們遺漏了什么。雖然很多時候這顯得很雞肋,但是有時候它能發揮至關重要的作用 。

        2. 不要欺騙電腦

        換言之就是“避免抽象漏洞”(注:抽象泄漏是指任何試圖減少或隱藏復雜性的抽象,其實并不能完全屏蔽細節,試圖被隱藏的復雜細節總是可能會泄漏出來)。系統該怎么用就怎么用,不要別出心裁自創用法。不要指望會出現什么奇跡。

        如果系統使用規模超過當前的三倍,那么就得考慮重新設計。

        電腦是最誠實的孩子,如果你欺騙了它,它絕對會狠狠地反咬一口。

        3. 簡單就好

        我們喜歡創建一些新事物、解決一些疑難雜癥。這也是為什么我們干這一行的原因。但是很多時候,我們發現某個問題可以解決,卻并不意味著現在就是解決它的好時機。

        我總是覺得自己是個愛自找麻煩的程序員——我喜歡干凈簡單易于理解的設計。別以為這很容易,相反這是一個難度不小的挑戰——以一種復雜的方式解 決問題誰都能辦到,但是只有優秀的程序員才能用一種既簡單又易于理解的方式解決問題。特別是要真正直截了當地思考出問題的關鍵就更是難上加難了。

        理解是重點,要知道程序員大部分時間是在維護代碼,而不是寫代碼。

        4. 優化第一戒律就是不要優化

        這一點來自于 John Bentley 所著的經典書籍《編程珠璣》。(它旨在幫助我們像一個經驗豐富的程序員一樣思考。雖然已經發行了好多年,但是上面的很多經驗教訓仍然適用于當今社會。)

        優化可以采取多種形式:速度、后驗形式、潛在規模、可能用途,等等。

        問題在于,大多數的優化最終是沒人用的,而且從定義上看,優化或多或少會使得設計更加復雜。所以,優化的第一戒律就是不要優化,除非你完全理解整個問題。(他的第二戒律依然是:“不要優化”,意即即使你理解了,但是除非你真的需要才能去優化。)

        5. 不要僅僅修復 bug;要修復所有可能發生 bug 的地方

        對于自己犯的錯誤,沒必要耿耿于懷。每個人都討厭出現 bug,我也是。

        我討厭會讓我犯錯的系統。而且我真的非常非常討厭去修復同樣的 bug,所以為了避免這種情況,每當我修復一個 bug 時,我就會思考以下問題:這種 bug 現在還有可能出現在哪里?以后又比較容易出現在什么地方?是什么原因造成了這種模式的 bug?我能不能一下子一網打盡呢?

        6. 不斷地做問題假設

        因為我大部分時間都是在搞我自己的創業公司,所以我養成了一個不斷詢問自己的習慣“為什么要這么做?這能解決什么問題?有沒有更好的方法?有沒有什么更重要的事情是我還沒做到的?”

        我們應該一直保持這種態度,不斷地詢問自己這些假設情況。什么是真正需要解決的問題?是不是只要求解決效果而不必追究根本原因?解決方案完整嗎?完備嗎?值得嗎?

        7. . 從長遠角度思考。放慢腳步,才能跑得更快

        這可能是最重要的一點了。作為工程師,我們享受于高效的工作效率:喜歡不斷地創建、創建、創建。但是如果我們不能用長遠的角度看問題,只會作繭自縛,使得最后越來越難構建任何東西。

        有時候,我們還沒理解問題就直接去寫代碼,最后導致不得不放棄。有時候我們的方案雖然對局部問題很有療效,可卻能讓事情變得更糟或造成更嚴重的 后果。有時候我們匆匆忙忙沒有完成設計,從而導致后期別人需要花更多的時間來修復。有時候我們只是懶得用正確的方式寫,直接就復制或者借鑒了別人的內容, 原因可能是因為忙著趕項目進度不想花時間去好好思考。……

        上面這些情況舉不勝舉。也有人說,這可比我碰到的情況好多了,呵呵。但是我還是想重復一下——我們的目標是建設最多最強大的功能,擁有最廣泛的用戶。所以,目光要看得長遠。

        8. 關心自己的代碼

        我想這一點沒必要過多解釋了吧。不過遺憾的是,現在有很多人時不時地將其拋之腦后。

        為自己的工作驕傲!關心你自己寫的代碼!

        如果我想偷懶抄近路,我就會告訴自己種瓜得瓜種豆得豆,現在偷懶將來可能會面對很多亂七八糟的代碼,最后可憐的還是自己。

        當然你也不必極端——在谷歌公司我經常開玩笑說其他的工程師對待代碼就像對自己的寵物一樣,而我和代碼之間的關系我更像是一個牧場主——務實,不感情用事。話雖然這樣說,但是碰到代碼不聽使喚的時候,我還是忍不住會發脾氣。

        9. 成本、速度、正確率

        這是軟件中的鐵三角關系,也是全世界軟件工程師孜孜以求的目標。但是這不能成為我們裹足不前自滿自得的借口。

        事實上,所謂程序員的優秀和偉大之間的區別往往在于他們駕馭這個鐵三角的能力——偉大的程序員通常會想盡辦法盡可能地達到這三個目標。我們都應該努力成為偉大的程序員。

        不過話說回來,魚與熊掌不可兼得,當我們不得不摒棄這個鐵三角的時候,一定要明白我們要妥協什么,為什么而妥協,是否是當前形勢下最正確的選擇。

        10. 最后,保持好奇心,不斷地學習

        好吧,這可能看上去更像是職業建業。但是如果你沒有了好奇心,不愿意學習新鮮事物,不再關心新技術、新語言,那么你還干這一行干嘛呢?

        上述編碼原則可能并不完美,各位如有不同意見,歡迎指正,在下洗耳恭聽。

        譯文鏈接:http://www.codeceo.com/article/10-coding-principles.html

        翻譯作者:碼農網 – 小峰

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!