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

1.文檔：

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

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

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

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

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

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

1.2 常見的問題：

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

1.3 什么時(shí)候需要寫文檔？

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

1.4 文檔書寫規(guī)范

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

2. 項(xiàng)目管理

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

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

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

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

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

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

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

2.4 項(xiàng)目周報(bào)和個(gè)人周報(bào)

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

3. 代碼的藝術(shù)

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

3.1 Coding is NOT so easy

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

3.2 一流代碼的特性

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

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

3.4 模塊切分的原則

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

3.5 切分模塊的方法

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

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

(1) 主要完成數(shù)據(jù)封裝：模塊內(nèi)部變量；類的內(nèi)部變量。(2) 對(duì)外提供明確的數(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. 代碼的評(píng)審(Code Review)

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

4.1 代碼評(píng)審的重要意義

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

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

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

4.3 代碼評(píng)審中的常見問題

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

(5) 缺少必要的注釋。

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

(7) 。。。。。

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

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

4.5 代碼評(píng)審的步驟

(1) 推薦方式：自頂向下，對(duì)代碼進(jìn)行全面掃描。(2) step1：系統(tǒng)全貌：模塊劃分的邏輯，模塊間的關(guān)系。(3) step2：模塊級(jí)別：看清模塊內(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) 沒有空行/注釋的代碼：不會(huì)用段落，不會(huì)寫注釋，肯定不是好的程序員。

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

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

5 技術(shù)的心法

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

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

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

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

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

5.2 如何分析問題

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

5.3 如何解決問題

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

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

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

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

審核編輯黃宇