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

1.文檔：

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

1.1 項目文檔的重要性

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

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

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

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

1.2 常見的問題：

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

1.3 什么時候需要寫文檔？

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

1.4 文檔書寫規(guī)范

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

2. 項目管理

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

2.1 原則：質(zhì)量第一

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

2.2 項目三要素的權(quán)衡

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

2.3 項目規(guī)劃

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

2.4 項目周報和個人周報

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

3. 代碼的藝術

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

3.1 Coding is NOT so easy

(1) Coding的過程是：從無序變?yōu)橛行颍粚F(xiàn)實世界中的問題轉(zhuǎn)化為數(shù)字世界的模型；一個認識的過程(從未知變?yōu)橐阎?。(2) Coding的過程中，需要把握問題的能力；建立模型的能力；溝通協(xié)作的能力；編碼執(zhí)行的能力。(3) 寫好代碼首先需要建立品味

3.2 一流代碼的特性

3.3 代碼也是一種表達方式

代碼主要是寫給人看的，不是寫給機器看的，代碼的維護成本遠高于開發(fā)成本。理想的場景：看別人的代碼感覺和看自己的代碼一樣；看代碼時能夠?qū)Ｗ⒂谶壿?，而不是格式方面；Don’t make me think。

3.4 模塊切分的原則

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

3.5 切分模塊的方法

(1) 數(shù)據(jù)類模塊（實現(xiàn)對數(shù)據(jù)的封裝）。(2) 過程類模塊（不包含數(shù)據(jù)）。

3.6 數(shù)據(jù)類模塊

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

3.7過程類模塊

(1) 本身不含數(shù)據(jù)。(2) 調(diào)用“數(shù)據(jù)類模塊”或“過程類模塊”。

4. 代碼的評審(Code Review)

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

4.1 代碼評審的重要意義

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

4.2 代碼質(zhì)量差造成的問題

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

4.3 代碼評審中的常見問題

(1) 拼寫錯誤。(2) 未優(yōu)化的代碼實現(xiàn)。(3) 不必要的復雜代碼。(4) 重復實現(xiàn)已經(jīng)存在的邏輯。

(5) 缺少必要的注釋。

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

(7) 。。。。。

4.4 在代碼評審中應有的態(tài)度

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

4.5 代碼評審的步驟

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

4.6 關于壞代碼的簡單判斷

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

4.7 代碼評審的注意事項

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

5 技術的心法

5.1 如何發(fā)現(xiàn)問題

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

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

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

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

5.2 如何分析問題

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

5.3 如何解決問題

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

(4) 一般的過程：發(fā)現(xiàn)問題，分析問題，解決問題。

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

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

審核編輯黃宇