前段時間聽了百度技術培訓中心章淼博士講的《代碼的藝術》直播課，章老師是業界大牛，課講得娓娓道來，內容很豐富，很多點都戳到了我以前或現在的痛點，也激發了自己很多反思，總之收獲很多，現在簡單總結一下，主要分以下幾點吧。

1.文檔：

關于文檔，很多工程師最討厭兩點：沒有文檔和自己寫文檔。我以前對文檔也有很深的誤解，比如經常覺得寫文檔有點兒浪費時間，總覺得碼代碼和Debug才更能顯示出一名工程師的能力和價值。這其實是一個嚴重的錯誤。文檔的重要性被嚴重低估了。

1.1 項目文檔的重要性

(1) 文檔的目的：提高溝通效率；提升對“思考過程”的管理。(2) 項目中超過50%的時間用于溝通，溝通的方式:口頭，文檔，代碼。(3) 沒有文檔的設計不是設計。(4) 不會寫文檔 = 不會做設計。(5) 文檔本身也是產出：coding的時間少于30%。(6) 寫文檔是整理思路的過程。(7) 沒有文檔，后期會浪費更多的時間，維護成本遠高于寫文檔的時間。

(8) 修改文檔，比修改代碼的成本小的多。

(9) 沒寫文檔，就開始寫code，是極其錯誤的。

(10)簡單的項目和問題，也需要寫文檔：項目的延續時間和復雜性往往超出預期；早期的“偷懶”，往往在后期付出更大的代價。

1.2 常見的問題：

(1) 沒有接口文檔：多人協作出現問題。(2) 需求文檔沒寫好：多次反復討論同樣的問題。(3) 沒有系統總體架構文檔：每一個人都需要重新看代碼，還不一定能看清。(4) 缺少文檔：新人無從入手；人員變動時，不好交接；團隊內溝通效率很低；自己過兩個月后，痛苦的回憶之前的思路。

1.3 什么時候需要寫文檔？

(1) 必須的文檔：需求設計文檔：需求，重點，取舍過程；接口文檔：函數，參數，返回值；關鍵性的算法文檔：思路，關鍵點；系統總體框架：全局的思路。(2) 凡是不那么“顯而易見”的地方。(3) 不僅留下設計結果(what),也留下思考過程(why)：留下決策的依據，便于后面的工作。(4) 文檔不是寫完代碼后補出來的：文檔是設計過程中使用的工具、和設計過程的結果。

1.4 文檔書寫規范

關于書寫規范，每家公司的要求都不太一樣，大家遵守就好。國內芯片行業在文檔這方面做的最好的應該就是海思了，我個人覺得海思芯片的成功，跟他的文檔和管理密不可分。

2. 項目管理

項目管理是另一個被忽視的重要的問題。引用《軟件開發的201個原則》中的一句話，所有偉大的技術（CASE工具、技術、計算機、文字處理器等）都彌補不了拙劣的管理。好的管理，即使是在資源匱乏的情況下，也能產生巨大的效果。事實上，懂項目管理的工程師特別少。每一位工程師其實都是管理者（做好自己的管理），所有的工程師都應該懂項目管理。

2.1 原則：質量第一

質量必須放在首位，沒有權衡的余地。無論如何定義質量，客戶都不會容忍低質量的產品。質量必須量化，并建立可實施落地的機制，以促進和激勵質量目標的達成。即使質量差、也按時交付產品，這似乎是政治正確的行為，但這是短視的。從中長期來看，這樣做是自殺。

2.2 項目三要素的權衡

鎖定1-2個要素，改變其他要素。人和月不能簡單互換。

2.3 項目規劃

(1) 明確項目約束(質量、范圍、時間、成本)，做出取舍。(2) 制定項目里程碑計劃，和相關方達成一致。(3) 分配任務并制定進度表：梳理關鍵任務；搞清關鍵任務間的依賴關系；識別項目的關鍵路徑。

2.4 項目周報和個人周報

(1) 做好下周計劃，抓住重點。(2) 每周對照計劃，即使有變化，也應努力按計劃執行。(3) 反映工作量，周報首先是給自己看的。(4) 周報需要目標和計劃，也需要回顧和總結。

3. 代碼的藝術

代碼反映了一個人/團隊的精神面貌。一個優秀的工程師應該具有很高的綜合素質。編碼能力只是表象，不僅要懂驗證，還要懂腳本，懂運維，懂設計、懂架構，懂產品。真正優秀的工程師任何時候都是稀缺的。

3.1 Coding is NOT so easy

(1) Coding的過程是：從無序變為有序；將現實世界中的問題轉化為數字世界的模型；一個認識的過程(從未知變為已知)。(2) Coding的過程中，需要把握問題的能力；建立模型的能力；溝通協作的能力；編碼執行的能力。(3) 寫好代碼首先需要建立品味

3.2 一流代碼的特性

3.3 代碼也是一種表達方式

代碼主要是寫給人看的，不是寫給機器看的，代碼的維護成本遠高于開發成本。理想的場景：看別人的代碼感覺和看自己的代碼一樣；看代碼時能夠專注于邏輯，而不是格式方面；Don’t make me think。

3.4 模塊切分的原則

緊內聚，松耦合，有利于代碼的復用:單一目的；明確對外接口；以數據為中心。

3.5 切分模塊的方法

(1) 數據類模塊（實現對數據的封裝）。(2) 過程類模塊（不包含數據）。

3.6 數據類模塊

(1) 主要完成數據封裝：模塊內部變量；類的內部變量。(2) 對外提供明確的數據訪問接口：數據結構和算法屬于模塊內部工作。(3) 寫程序要以數據為中心考慮：首先考慮有哪些數據類的模塊。

3.7過程類模塊

(1) 本身不含數據。(2) 調用“數據類模塊”或“過程類模塊”。

4. 代碼的評審(Code Review)

定義：通過閱讀代碼來檢查源代碼與編碼標準的符合性以及代碼質量的活動。在編寫代碼之外，代碼評審和單元測試是兩個最重要的工作。

4.1 代碼評審的重要意義

(1) 提升代碼質量：code review是提升代碼質量最重要的方法。(2) 有助于知識傳遞：code review是輔導他人編碼最好的方法。

4.2 代碼質量差造成的問題

(1) 重復編寫類似的邏輯，缺少可復用的代碼。(2) 定位bug和修復bug。(3) 代碼的可讀性差，閱讀代碼困難，費時。(4) 踩坑/填坑，挖坑容易，從坑里爬出來難。(5) 重構也需要時間。(6) 無休止的加班的源泉。(7) 職業危機，生存困境。

4.3 代碼評審中的常見問題

(1) 拼寫錯誤。(2) 未優化的代碼實現。(3) 不必要的復雜代碼。(4) 重復實現已經存在的邏輯。

(5) 缺少必要的注釋。

(6) 缺少必要的單元測試。

(7) 。。。。。

4.4 在代碼評審中應有的態度

(1) 對所審代碼完全看懂：yes:掌握情況就像自己寫的一樣；no: 對代碼邏輯和背后的原因任很模糊。(2) 不僅可以運行：優秀代碼的標準：正確，可維護，可重用，可運維。google的標準：差一個空格也不行。(3) 評審和編碼一樣重要：評審也有產出：更高質量的代碼；評審比編碼更辛苦：理解&找出問題。(4) 以提升代碼質量為最終目標：評審雙方共同努力。

4.5 代碼評審的步驟

(1) 推薦方式：自頂向下，對代碼進行全面掃描。(2) step1：系統全貌：模塊劃分的邏輯，模塊間的關系。(3) step2：模塊級別：看清模塊內的邏輯；關鍵數據，關鍵的類/函數（重點：功能，接口定義）。(4) step3：類/函數的內部邏輯：邏輯正確性，實現合理性，段落劃分合理性。

4.6 關于壞代碼的簡單判斷

(1) 如果5分鐘內不能看懂的代碼，大概率有問題。(2) 需要思考才能看懂的代碼：好的代碼：Don’t make me think。(3) 需要來回翻屏才能看懂得代碼：好的代碼：在一屏內就是完整的邏輯。(4) 沒有空行/注釋的代碼：不會用段落，不會寫注釋，肯定不是好的程序員。

4.7 代碼評審的注意事項

(1) 建立ower制度：所有提交的代碼，必須由ower做最終確認；很多問題來源于“責任不明確”。(2) 綜合多種溝通機制：yes:面對面的溝通；提供設計文檔；提交代碼評審評論；no: 直接大規模評審會；僅口頭溝通。(3) 不放過任何一行代碼：問題：只看大問題，不管小問題；推薦：對評審中發現的問題，一追到底。

5 技術的心法

5.1 如何發現問題

(1) 問題的發現常常需要經驗，尤其是方向的指出。(2) 寫綜述(survey)，是一個很好的鍛煉方法。(3) 從自己的親身體會去發現問題。

(4) 要有挑戰權威的精神，別人說的不一定是對的。

(5) 一定不要有“想當然”的思想，書本上的不一定是正確的。

(6) 沒有任何事情是完美的，實際工程中經常做“trade off”。

5.2 如何分析問題

(1) 概念（磚塊）：問題首先要有準確定義(正名)；概念是大家的共識，是進行科學交流的基礎；在搞清概念的過程中，也能發現機會。(2) 邏輯(水泥)：分析問題應言之有理，讓人信服。(3) 分而治之：大問題(無從下手)=>小問題(能夠處理)；細分和專業化是人類社會發展的趨勢。(4) 分類和比較：在過程中加深認識。(5) 注意聯系：問題之間的聯系也包含信息；揭示事物之間的聯系也很有意義。

5.3 如何解決問題

(1) 先解決重要問題：精力有限：不可能徹底解決所有問題；列出問題，然后再排序。(2) 保持聚焦：在一定的階段，要keep focus。(3) 先易后難：解決簡單問題=>解決復雜問題；模型方法：對問題進行簡化

(4) 一般的過程：發現問題，分析問題，解決問題。

一流高手提問題，二流高手解問題，三流高手炒問題(炒冷飯)最后的最后，好好學習，天天向上，行勝于言，與君共勉。

感謝關注微信公眾號“芯片驗證日記”，我們一起學習。

審核編輯黃宇