20年編程老兵的代碼價值觀:從蘋果公司的一次嚴重安全漏洞說起
2014 年 2 月,安全研究人員爆出蘋果公司旗下的 iOS 和 OS X 操作系統出現了嚴重的安全漏洞,黑客可以利用這一漏洞輕鬆獲取用戶的數據。下面的這段 C 語言偽代碼簡單描述了當時的漏洞情況。
相信你一眼就能看出來,在這段代碼的第三行出現了多餘的代碼,導致後面的其他代碼「失效」,這一低級錯誤也讓所有的安全人員大跌眼鏡。你可能會說,這開發人員真是太粗心了,是不是他複製代碼的時候,多複製了一行,然後忘記刪除了?
可能是這個原因,但問題的源頭肯定不是粗心。有專家在看完了代碼文件之後,發現相關的 Bug 代碼沒有正確使用縮進,也沒有正確使用括弧,並且其中的空格、製表符和代碼注釋也都不統一。
換句話說,這段代碼就是所謂的「爛代碼」。
工作中,對於爛代碼和好代碼的定義,真的是千人千面。現實環境的變化,也影響著你我對於代碼「好」與「壞」的判斷標準。
比如說你有沒有遇到過這樣的場景:當你看到一段不符合自己價值觀的代碼,理所當然認為寫的爛,於是刪掉了那段代碼,用自己認為更好的方法重新寫了一遍,覺得挽救了這個項目。但當對這部分業務邏輯熟悉了之後,發現所刪代碼中的處理方式是最恰當的。
雖然對於「什麼是優秀的代碼「難以形成一致看法,但多年經驗,讓我對代碼「好」與「壞」,有一些明確的判斷。下面一些最關鍵的要素:
如果用一句話來概括,「最適合當前現實環境的代碼,才是最優秀的代碼。」我會在專欄中通過案例結合我的多年經驗詳細闡述這句話的真正含義。
我是誰?
我是范學雷,現在是 Oracle 的主任工程師,也是 OpenJDK 和 Java 安全的評審成員。自從 1998 年參加工作以來,我一直跑在編程的第一線,我喜歡並且也熱愛代碼。2004 年的時候,我就加入了 Java SE 團隊,這一干就是 15 年,這些年,我完整經歷了 JDK 從 1.5.0 到 9.0 的整個迭代過程,同時我自己也是 OpenJDK 和 Java Security 的評審成員。
作為一個代碼評審者,不是簡簡單單的批准或者拒絕提交的代碼,而是根據自己過往的編碼經驗提出合理的建議,幫助代碼提交者規避這些失誤或者錯誤,編寫出更優秀的代碼。
代碼看得多了,我對代碼就有了更深的理解,比如:
什麼樣的代碼更容易出問題?
什麼樣的代碼會招惹麻煩?
什麼樣的代碼出力不討好?
什麼樣的代碼小問題闖大禍?
對程序員也有了更多的了解,比如:
為什麼我們不願意寫注釋呢?
為什麼代碼寫完就不願意修改了呢?
為什麼我們不願意做測試呢?
為什麼我們嚮往自由而不願意遵守規範呢?
對我來說,審閱代碼的工作是一個收穫大於付出的過程。每一行代碼,都體現著程序員的修為,思考問題的深度,甚至是處理問題的習慣和態度。現在我把過往 20 年的經驗沉澱下來,通過專欄呈現給你。我希望,我能教會你下面這些東西:
1、摒棄編碼壞習慣,找到高效規範的代碼編寫方法。
2、提升編程敏感度,擁有專家級編碼思維和全局觀。
3、重塑代碼價值觀,找到最適合現實環境的代碼設計邏輯。
4、緊貼工作實際場景,明確高頻代碼問題的最優處理和預防方案。
5、消除代碼安全隱患,為團隊交付最佳性能的代碼。
專欄目錄
現在有什麼優惠呢?
1、限時優惠¥68(原價¥99),兩杯咖啡的價格。
2、每邀請一位好友購買,你可獲得24 元現金返現,邀請 3 人就相當於免費學習本專欄。( 在App 中提現)
掃碼試讀或者訂閱,踏上你的代碼精進之路
新年彩蛋,往下看:
凡訂閱的用戶,附贈「極客時間 2018 年度全年的資料集錦(共 50G)」(包含十年架構師文集 100 本,20 套程序員必備技能知識圖譜,20 專欄精華內容提煉,近 100 位 CTO 的問談實錄)。
部分資料展示


※用Flink取代JStorm,今日頭條的遷移過程與後續計劃
※一個基礎學科,為啥這麼硬核?
TAG:InfoQ |