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

關于開發過程

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

pull request的時候，不要糾結代碼能怎么幫你營銷自己，多想想它可以為讀者和社區做什么。你必須不惜一切避免“招搖的貢獻”，如果這么做對你的產品毫無用處，就不要去畫蛇添足。

個人品位也適用于代碼。它是一種約束，如果你追求代碼的簡潔優雅，你就會規范自己的編碼過程。因此，要始終對簡潔性保持偏愛。

學會拒絕——別人提出需求不等于你就應該照他們的想法去做。他們每提出一個新功能，它的成本就會超出最初的實施范圍：維護成本，文檔成本和用戶的認知成本。所以要一直問自己：我們真的應該這樣做嗎？通常情況下，這個問題的回答是否定的。

當你答應按照用戶請求開發新功能塊（use case）時，記住，只按字面理解開發新功能是不夠的。用戶只關心自己用的特定功能塊，但你必須站在全局性和原則性的視角下去看待這項更新，一般情況下，這意味著擴展現有功能。

向持續集成和所有代碼的單元測試全覆蓋“投資”。時刻確保自己處于優質編程環境中，如果這點都做不到，先關注怎么準備正確設備。

如果沒有做計劃，沒關系。你可以多多嘗試，看看結果如何。要盡早發現錯誤選擇，確保自己最終能發現一種可行的方法。

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

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

這么做會有什么影響？這才是你在程序設計過程中應該考慮的事，而不是收入怎么樣，會帶來什么個人成長。除了正在監控的指標之外，你的軟件對全球用戶的總體影響是什么？是否存在預期之外的不良副作用？在保留實用性的同時，你能做什么改善？

關于API設計

你設計的API會有用戶，所以時刻關注用戶體驗。每當你做出一個決定，你都應該關注用戶的感受，關注他們中的每一個人，無論是他們是初學者還是資深開發人員。

降低用戶在使用你的API時的認知負荷。自動化一切可自動化的內容，最大限度地減少用戶所需的操作和選擇量，不要暴露不重要的選項，設計簡單一致的工作流程，以反映簡單一致的心智模型。

簡單的事應該是簡單的，復雜的事應該是有可能性的。不要為了利基功能塊把簡單問題復雜化，即便是最低限度。

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

設計一個符合領域專家和從業者心智模型的API。有這個領域經驗但沒有API經驗的人應該能通過閱讀最少的文檔直觀地理解你的API，比如查看代碼示例、查找可用對象和它們的簽名。

在沒有任何關于底層實現的上下文的情況下，參數的含義應該是直觀的、易于理解的。用戶指定的參數應該和他們的需求有關，而不是和代碼中的實現細節有關。API就是解決問題的工具，它不需要涉及軟件如何在后臺運行。

最強大的心智模型是模塊化和層次化的：既注重高級別的簡潔性，又兼顧精確性，包含需要了解詳細信息。同樣的，一個好的API也應該是模塊化和層次化的：易于連接，又具有相當的表現力。它內部應該保持平衡，在較少對象上具有復雜簽名，并且在簡單簽名上具有更多對象。

你的API會不可避免地反映你的實現選擇，特別是數據結構。為了實現直觀的API，你選擇的數據結構必須適合對應的領域——這也是符合專家心智模型的一個方面。

設計一個端到端的工作流程，而不是一系列atomic features。大多數開發人員在設計API時，遵循的思路是“應該提供哪些功能？讓我們為他們配置選項”。這并不合適，相反地，你應該問問自己“這個工具有哪些功能塊？”“對于每個功能塊，用戶操作的最佳順序是什么？”“為了支持整個工作流程，最方便的API是哪個？”API中的Atomic options應該能滿足高級工作流程中出現的明確需求——所以，切記不要出現“人們也許需要它”的東西。

在用戶使用API的過程中，錯誤信息是對他們操作的一種重要反饋。交互性和反饋是用戶體驗不可或缺的一部分，因此，設計它們時務必深思熟慮。

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

文檔是API用戶體驗的核心，它不是附加組件。在文檔寫作上花費一點精力，你也許會收獲意料之外的驚喜。

圖像是生動的，言語是蒼白的：你的文檔不應該只是介紹軟件如何工作，它應該顯示如何使用它。比如顯示端到端工作流的代碼示例，顯示API的每個常見用例和關鍵功能的代碼示例。

關于職業發展

職業發展并不是指你管理的人數，而是指你的工作所產生的影響，它能否對世界造成些許改變。

軟件開發需要團隊合作，其中人際關系與技術能力同樣重要。當你在職業道路上前行時，請保持團隊間聯系，做好團隊中的一員。

技術永遠不會是中立的。如果你的工作對世界產生了影響，那么這種影響就會存在道德取向。在軟件產品中看似無害的技術選擇會導致技術獲取條件的調整，它決定著誰將受益、誰將受害：技術選擇也是道德選擇。因此，在道德設計上請始終謹慎而明確地表達你的價值觀，并把你的價值觀融入創作中。永遠不要想“我只是搞技術，它是中立的”，因為你構建它的方式決定了它將被如何使用。

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

構建這個世界需要的東西，而不僅僅是你個人的小希望。很多時候，技術人員過著單純的生活，只專注于滿足產品的特定需求。但你應該嘗試去尋求擴大生活體驗的機會，讓自己更好地了解世界的需求。

在面對長期問題時，你在做任何選擇之前都應該進行長遠打算，并把價值觀置于短期自身利益和情緒之上，例如貪婪或恐懼。明確你的價值觀，并讓它指導你。

當發現自己和他人產生矛盾時，停一停，反思一下雙方是否有著相同的價值觀和共同目標，請提醒自己，大家是戮力同心的。

生產力由決策力和工作重心決定。這需要 a）良好的直覺，它來自經驗，以便你可以在知之甚少的情況下做出盡可能靠譜的決定; b）能敏銳地意識到什么時候該謹慎行事，保持觀望，因為一個錯誤決策的成本可能會比延期的成本更高。在不同環境中，時間至上和質量至上的決策權衡可能會帶來很大的差異。

更快地決策意味著你在職業生涯中可以做出更多決策，這能鍛煉你的“直覺”。經驗是提高生產力的關鍵，而更高的生產力可以為你提供更多經驗，這是一個良性循環。

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