編者按：今天，Keras作者、Google深度學(xué)習(xí)Fran?ois Chollet又發(fā)表了一篇新文章。他把里面的內(nèi)容稱為“自我提醒清單”，這是他多年來目睹、親身經(jīng)歷的軟件工程師經(jīng)驗(yàn)總結(jié)。雖然在實(shí)際操作中，不少人會(huì)被公司管理層的各種要求逼上歧途，但凡事重在不忘初心。值此秋招之際，論智也把這篇佳作分享給大家。

關(guān)于開發(fā)過程

代碼不僅僅意味著運(yùn)行，它也是團(tuán)隊(duì)人員之間的一種溝通方式，是向他人描述問題解決方案的一種方式。代碼的可閱讀性不應(yīng)是軟件工程師的優(yōu)點(diǎn)，它該是所有人的基礎(chǔ)能力。這包括清楚地分解代碼，選擇不言自明的變量名，以及插入注釋來描述隱含的任何內(nèi)容。

pull request的時(shí)候，不要糾結(jié)代碼能怎么幫你營(yíng)銷自己，多想想它可以為讀者和社區(qū)做什么。你必須不惜一切避免“招搖的貢獻(xiàn)”，如果這么做對(duì)你的產(chǎn)品毫無用處，就不要去畫蛇添足。

個(gè)人品位也適用于代碼。它是一種約束，如果你追求代碼的簡(jiǎn)潔優(yōu)雅，你就會(huì)規(guī)范自己的編碼過程。因此，要始終對(duì)簡(jiǎn)潔性保持偏愛。

學(xué)會(huì)拒絕——?jiǎng)e人提出需求不等于你就應(yīng)該照他們的想法去做。他們每提出一個(gè)新功能，它的成本就會(huì)超出最初的實(shí)施范圍：維護(hù)成本，文檔成本和用戶的認(rèn)知成本。所以要一直問自己：我們真的應(yīng)該這樣做嗎？通常情況下，這個(gè)問題的回答是否定的。

當(dāng)你答應(yīng)按照用戶請(qǐng)求開發(fā)新功能塊（use case）時(shí)，記住，只按字面理解開發(fā)新功能是不夠的。用戶只關(guān)心自己用的特定功能塊，但你必須站在全局性和原則性的視角下去看待這項(xiàng)更新，一般情況下，這意味著擴(kuò)展現(xiàn)有功能。

向持續(xù)集成和所有代碼的單元測(cè)試全覆蓋“投資”。時(shí)刻確保自己處于優(yōu)質(zhì)編程環(huán)境中，如果這點(diǎn)都做不到，先關(guān)注怎么準(zhǔn)備正確設(shè)備。

如果沒有做計(jì)劃，沒關(guān)系。你可以多多嘗試，看看結(jié)果如何。要盡早發(fā)現(xiàn)錯(cuò)誤選擇，確保自己最終能發(fā)現(xiàn)一種可行的方法。

好的軟件可以化難為易。問題看起來可以很復(fù)雜，但這并不意味著它的解決方案一定是復(fù)雜的、難以實(shí)現(xiàn)的。有時(shí)工程師們會(huì)忽視簡(jiǎn)單易用但不怎么明顯的解決方案，轉(zhuǎn)而投向另外一些復(fù)雜的、有副作用的方法（我們用機(jī)器學(xué)習(xí)吧！寫個(gè)APP吧！加上區(qū)塊鏈吧?。Ｔ诰帉懭魏未a之前，請(qǐng)確保你選擇的解決方案不能更簡(jiǎn)單，牢記編程首要原則：Keep It Simple。

避免隱含規(guī)則。如果你自己開發(fā)了一些隱含規(guī)則，請(qǐng)確保它們是共享的，可以被其他開發(fā)者明確理解，或是可以自動(dòng)化。當(dāng)你想出了一些頻繁出現(xiàn)的、類似算法的東西，你應(yīng)該設(shè)法將其形式化為一個(gè)文檔化的流程，以便其他團(tuán)隊(duì)成員從中受益。此外，你也應(yīng)該設(shè)法尋找一些工具，使這個(gè)方法的任何部分都能被自動(dòng)化（如debug）。

這么做會(huì)有什么影響？這才是你在程序設(shè)計(jì)過程中應(yīng)該考慮的事，而不是收入怎么樣，會(huì)帶來什么個(gè)人成長(zhǎng)。除了正在監(jiān)控的指標(biāo)之外，你的軟件對(duì)全球用戶的總體影響是什么？是否存在預(yù)期之外的不良副作用？在保留實(shí)用性的同時(shí)，你能做什么改善？

關(guān)于API設(shè)計(jì)

你設(shè)計(jì)的API會(huì)有用戶，所以時(shí)刻關(guān)注用戶體驗(yàn)。每當(dāng)你做出一個(gè)決定，你都應(yīng)該關(guān)注用戶的感受，關(guān)注他們中的每一個(gè)人，無論是他們是初學(xué)者還是資深開發(fā)人員。

降低用戶在使用你的API時(shí)的認(rèn)知負(fù)荷。自動(dòng)化一切可自動(dòng)化的內(nèi)容，最大限度地減少用戶所需的操作和選擇量，不要暴露不重要的選項(xiàng)，設(shè)計(jì)簡(jiǎn)單一致的工作流程，以反映簡(jiǎn)單一致的心智模型。

簡(jiǎn)單的事應(yīng)該是簡(jiǎn)單的，復(fù)雜的事應(yīng)該是有可能性的。不要為了利基功能塊把簡(jiǎn)單問題復(fù)雜化，即便是最低限度。

如果工作流的認(rèn)知負(fù)荷足夠低，那么用戶應(yīng)該能在一次或兩次親身事件后就掌握整個(gè)流程（無需查閱教程或文檔）。

設(shè)計(jì)一個(gè)符合領(lǐng)域?qū)＜液蛷臉I(yè)者心智模型的API。有這個(gè)領(lǐng)域經(jīng)驗(yàn)但沒有API經(jīng)驗(yàn)的人應(yīng)該能通過閱讀最少的文檔直觀地理解你的API，比如查看代碼示例、查找可用對(duì)象和它們的簽名。

在沒有任何關(guān)于底層實(shí)現(xiàn)的上下文的情況下，參數(shù)的含義應(yīng)該是直觀的、易于理解的。用戶指定的參數(shù)應(yīng)該和他們的需求有關(guān)，而不是和代碼中的實(shí)現(xiàn)細(xì)節(jié)有關(guān)。API就是解決問題的工具，它不需要涉及軟件如何在后臺(tái)運(yùn)行。

最強(qiáng)大的心智模型是模塊化和層次化的：既注重高級(jí)別的簡(jiǎn)潔性，又兼顧精確性，包含需要了解詳細(xì)信息。同樣的，一個(gè)好的API也應(yīng)該是模塊化和層次化的：易于連接，又具有相當(dāng)?shù)谋憩F(xiàn)力。它內(nèi)部應(yīng)該保持平衡，在較少對(duì)象上具有復(fù)雜簽名，并且在簡(jiǎn)單簽名上具有更多對(duì)象。

你的API會(huì)不可避免地反映你的實(shí)現(xiàn)選擇，特別是數(shù)據(jù)結(jié)構(gòu)。為了實(shí)現(xiàn)直觀的API，你選擇的數(shù)據(jù)結(jié)構(gòu)必須適合對(duì)應(yīng)的領(lǐng)域——這也是符合專家心智模型的一個(gè)方面。

設(shè)計(jì)一個(gè)端到端的工作流程，而不是一系列atomic features。大多數(shù)開發(fā)人員在設(shè)計(jì)API時(shí)，遵循的思路是“應(yīng)該提供哪些功能？讓我們?yōu)樗麄兣渲眠x項(xiàng)”。這并不合適，相反地，你應(yīng)該問問自己“這個(gè)工具有哪些功能塊？”“對(duì)于每個(gè)功能塊，用戶操作的最佳順序是什么？”“為了支持整個(gè)工作流程，最方便的API是哪個(gè)？”API中的Atomic options應(yīng)該能滿足高級(jí)工作流程中出現(xiàn)的明確需求——所以，切記不要出現(xiàn)“人們也許需要它”的東西。

在用戶使用API的過程中，錯(cuò)誤信息是對(duì)他們操作的一種重要反饋。交互性和反饋是用戶體驗(yàn)不可或缺的一部分，因此，設(shè)計(jì)它們時(shí)務(wù)必深思熟慮。

代碼即通信，命名很重要——無論是項(xiàng)目還是變量，名稱反映了你對(duì)問題的看法。在設(shè)計(jì)過程中，你不應(yīng)使用過于通用的名稱（如x, variable, parameter），也不要用過長(zhǎng)、有特指含義的術(shù)語(yǔ)，或是會(huì)產(chǎn)生不必要誤解的詞（如master/slave）。遵循命名一致性，這意味著內(nèi)部命名的一致性（如dim/axis）以及和問題內(nèi)容保持一致。在確定名稱前，參考其他API的命名方式是一種好辦法。

文檔是API用戶體驗(yàn)的核心，它不是附加組件。在文檔寫作上花費(fèi)一點(diǎn)精力，你也許會(huì)收獲意料之外的驚喜。

圖像是生動(dòng)的，言語(yǔ)是蒼白的：你的文檔不應(yīng)該只是介紹軟件如何工作，它應(yīng)該顯示如何使用它。比如顯示端到端工作流的代碼示例，顯示API的每個(gè)常見用例和關(guān)鍵功能的代碼示例。

關(guān)于職業(yè)發(fā)展

職業(yè)發(fā)展并不是指你管理的人數(shù)，而是指你的工作所產(chǎn)生的影響，它能否對(duì)世界造成些許改變。

軟件開發(fā)需要團(tuán)隊(duì)合作，其中人際關(guān)系與技術(shù)能力同樣重要。當(dāng)你在職業(yè)道路上前行時(shí)，請(qǐng)保持團(tuán)隊(duì)間聯(lián)系，做好團(tuán)隊(duì)中的一員。

技術(shù)永遠(yuǎn)不會(huì)是中立的。如果你的工作對(duì)世界產(chǎn)生了影響，那么這種影響就會(huì)存在道德取向。在軟件產(chǎn)品中看似無害的技術(shù)選擇會(huì)導(dǎo)致技術(shù)獲取條件的調(diào)整，它決定著誰將受益、誰將受害：技術(shù)選擇也是道德選擇。因此，在道德設(shè)計(jì)上請(qǐng)始終謹(jǐn)慎而明確地表達(dá)你的價(jià)值觀，并把你的價(jià)值觀融入創(chuàng)作中。永遠(yuǎn)不要想“我只是搞技術(shù)，它是中立的”，因?yàn)槟銟?gòu)建它的方式?jīng)Q定了它將被如何使用。

自我導(dǎo)向——為你工作和環(huán)境提供指引——它是生活滿意度的關(guān)鍵。幫助身邊的人建立起屬于他們的自我導(dǎo)向，并確保你的職業(yè)選擇能夠讓你成為更好的自己。

構(gòu)建這個(gè)世界需要的東西，而不僅僅是你個(gè)人的小希望。很多時(shí)候，技術(shù)人員過著單純的生活，只專注于滿足產(chǎn)品的特定需求。但你應(yīng)該嘗試去尋求擴(kuò)大生活體驗(yàn)的機(jī)會(huì)，讓自己更好地了解世界的需求。

在面對(duì)長(zhǎng)期問題時(shí)，你在做任何選擇之前都應(yīng)該進(jìn)行長(zhǎng)遠(yuǎn)打算，并把價(jià)值觀置于短期自身利益和情緒之上，例如貪婪或恐懼。明確你的價(jià)值觀，并讓它指導(dǎo)你。

當(dāng)發(fā)現(xiàn)自己和他人產(chǎn)生矛盾時(shí)，停一停，反思一下雙方是否有著相同的價(jià)值觀和共同目標(biāo)，請(qǐng)?zhí)嵝炎约海蠹沂锹玖ν牡摹?/p>

生產(chǎn)力由決策力和工作重心決定。這需要 a）良好的直覺，它來自經(jīng)驗(yàn)，以便你可以在知之甚少的情況下做出盡可能靠譜的決定; b）能敏銳地意識(shí)到什么時(shí)候該謹(jǐn)慎行事，保持觀望，因?yàn)橐粋€(gè)錯(cuò)誤決策的成本可能會(huì)比延期的成本更高。在不同環(huán)境中，時(shí)間至上和質(zhì)量至上的決策權(quán)衡可能會(huì)帶來很大的差異。

更快地決策意味著你在職業(yè)生涯中可以做出更多決策，這能鍛煉你的“直覺”。經(jīng)驗(yàn)是提高生產(chǎn)力的關(guān)鍵，而更高的生產(chǎn)力可以為你提供更多經(jīng)驗(yàn)，這是一個(gè)良性循環(huán)。

如果你感覺自己不具備“直覺”，那么請(qǐng)把經(jīng)驗(yàn)抽象成理論。你可以在整個(gè)職業(yè)生涯中建立一系列可靠且真實(shí)的原則：原則是形式化的直覺，它所適應(yīng)的情景比原始的模式識(shí)別（需要大量直接的、類似的經(jīng)驗(yàn)）更廣泛。