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

1.文檔：

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

1.1 項(xiàng)目文檔的重要性

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

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

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

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

1.2 常見的問題：

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

1.3 什么時候需要寫文檔？

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

1.4 文檔書寫規(guī)范

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

2. 項(xiàng)目管理

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

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

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

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

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

2.3 項(xiàng)目規(guī)劃

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

2.4 項(xiàng)目周報和個人周報

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

3. 代碼的藝術(shù)

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

3.1 Coding is NOT so easy

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

3.2 一流代碼的特性

3.3 代碼也是一種表達(dá)方式

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

3.4 模塊切分的原則

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

3.5 切分模塊的方法

(1) 數(shù)據(jù)類模塊（實(shí)現(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)

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

4.1 代碼評審的重要意義

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

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

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

4.3 代碼評審中的常見問題

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

(5) 缺少必要的注釋。

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

(7) 。。。。。

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

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

4.5 代碼評審的步驟

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

4.6 關(guān)于壞代碼的簡單判斷

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

4.7 代碼評審的注意事項(xiàng)

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

5 技術(shù)的心法

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

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

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

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

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

5.2 如何分析問題

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

5.3 如何解決問題

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

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

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

感謝關(guān)注微信公眾號“芯片驗(yàn)證日記”，我們一起學(xué)習(xí)。

審核編輯黃宇