給年輕程序員的33條忠告

作者 | Fran?ois Chollet

譯者 | 小大非

代碼是一種交流方式，Keras 之父 Fran?ois Chollet 在本文中為我們總結了在開發過程中、API 設計中及軟體職業生涯中應該關注哪些要點。原則是形式化的直覺，比原始模式識別適用於更廣泛的情況，Fran?ois Chollet 的這份原則清單帶你領略大師的品味。

關於開發過程

代碼不僅僅是用來運行的。代碼也是跨團隊交流的一種方式，是向他人描述問題解決方案的一種方式。良好的代碼可讀性不是那麼容易做到的，但它是編寫代碼的基本部分。這涉及到清晰地分解代碼，選擇恰當的自解釋變數名，插入注釋來描述任何隱含的內容。

不要渴望你的 pull request 能為你贏得多少名聲，而要多關注你的 pull request 能為你的用戶和社區做些什麼。要不惜一切代價避免「功利性的貢獻」。如果你提交的功能對產品的意圖沒有明顯的幫助，就不要添加任何功能。

品味也適用於代碼。品味是一種受約束的滿足過程，這種滿足是由對簡單的渴望所約束的。保持對簡單性的偏愛。

要學會說「不」——僅僅因為有人要求做某個特性，並不意味著你就應該這麼做。每個特性都有一個超出初始實現的成本：維護成本、文檔成本和用戶的認知成本。我們要時刻提醒自己：我們真的應該這樣做嗎? 通常，答案是否定的。

當你準備答應實現一個新用例時，請記住，僅從字面意思理解實現用戶的需求通常不是最佳選擇。用戶關注的僅僅是他們自己的特定用例，你必須從整個項目的角度出發，兼顧整體性和原則性。通常，正確的做法是擴展現有的特性。

不斷進行持續集成，並以完整的單元測試覆蓋為目標。確保你處在一個可以自信地編寫代碼的環境中；如果不是這樣，那麼你需要從構建正確的基礎設施開始。

事先不做好計劃也是可以的。嘗試一下，看看結果如何。儘早恢復錯誤的選擇。當然前提是確保你的環境可以達到這樣的目的。

好的軟體使困難的事情變得簡單。問題一開始看起來很困難，並不意味著解決方案必須很複雜或者很難操作。工程師經常使用反射式的解決方案，這會在有更簡單解決方案 (雖然可能不太明顯) 的情況下，帶來不必要的複雜性 (我們可以使用 ML! 我們可以嘗試構建一個應用程序! 我們可以使用區塊鏈!)。在編寫任何代碼之前，請確保你所選擇的解決方案不能變得更簡單。做任何事情都要有本源思維。

避免隱式規則。應該明確說明你自己開發的隱式規則，並與他人共享。當你發現自己提出了一個重複的、准演算法的工作流時，你應該設法將它標準化到一個文檔中，以便其他團隊成員能夠從此經驗中獲益。此外，你應該在軟體中嘗試自動化任何可以自動化的工作流 (例如，正確性檢查)。

在設計過程中應該考慮你選擇方案的總體影響，而不僅僅是你希望關注的那些方面——比如收入或成長性。除了你正在監視的度量之外，你的軟體對其用戶、對世界的總體影響是什麼? 是否存在超過價值主張的不良副作用? 在保持軟體可用性的同時，你能做些什麼來解決這些問題呢?

設計倫理，把你的價值觀融入你的作品中。

API 的設計

你的 API 是有用戶的，因此它有用戶體驗。在你做的每一個決定中，都要考慮到用戶。要站在用戶的角度思考問題，無論他們是初學者還是有經驗的開發人員。

要保持讓你用戶使用 API 的過程中盡量減少認知負荷。自動化可以自動化的東西，最小化用戶需要的操作和選擇，不要顯示不重要的選項，設計簡單一致的工作流，反映簡單一致的思維模型。

簡單的事情要簡單的處理，複雜的事情應該盡量簡單化。不要為了小範圍的用例而增加普通用例的認知負荷，即使是最低限度的。

如果工作流的認知負載足夠低，那麼用戶在完成一到兩次工作之後，應該可以靠記憶完成工作了 (無需查找教程或文檔)。

尋求與領域專家和實踐者的心智模型相匹配的 API。有領域經驗但沒有 API 經驗的人應該能夠使用最少的文檔直觀地理解你的 API，主要是通過查看一些代碼示例，看看哪些對象可用，以及它們的特徵是什麼。

一個參數的含義應該是容易理解的，而不需要任何關於底層實現的上下文。必須由用戶指定的參數應該與用戶關於問題的心理模型相關，而不是與代碼中的實現細節相關。一個 API 是關於它解決的問題，而不是關於軟體在後台如何工作。

最強大的心智模型是模塊化和層次化的: 在高層次上很簡單，但在細節上很精確。同樣地，一個好的 API 是模塊化和層次化的: 易於使用，但具有表現力。在更少的對象上有複雜的特性和具有更簡單特性的對象之間有一個平衡。一個好的 API 有合理數量的對象，具有相當簡單的特性。

你的 API 不可避免地反映了你的實現選擇，特別是你對數據結構的選擇。要實現直觀的 API，你必須選擇自然適合其領域的數據結構——與領域專家的心智模型相匹配。

特意設計端到端工作流，而不是一組原子特性。大多數開發人員在進行 API 設計時都會問: 應該提供哪些功能? 讓我們為它們提供配置選項。恰恰相反，他們應該這樣問: 這個工具的用例是什麼? 對於每個用例，用戶操作的最佳順序是什麼? 支持這個工作流的最簡單的 API 是什麼? 你的 API 中的原子選項應該能夠滿足在高級工作流中出現的明顯需求——它們不應該被添加，「因為有人可能需要它」。

錯誤消息，以及在與 API 交互過程中向用戶提供的任何反饋，都是 API 的一部分。交互性和反饋是用戶體驗的一部分。需要謹慎的設計 API 的錯誤消息。

因為代碼是一種交流方式，所以命名很重要——無論是命名項目還是變數。名字反映了你對問題的看法。避免使用過於通用的名稱 (x、變數、參數)，避免使用過於冗長和特定的命名模式，避免使用可能造成不必要誤解的術語 (主、從)，並確保你的命名選擇方式是一致的。命名一致性意味著內部命名一致性 (不要在其他地方將「dim」稱為「axis」) 和與問題域的既定約定的一致性。在確定名稱之前，請確保查找領域專家 (或其他 API) 使用的現有名稱。

文檔是 API 用戶體驗的中心。它不是一個附加組件。著力產出高質量的文檔；你將看到比開發更多的功能更高的回報。

Show, don "t tell：你的文檔不應該討論軟體是如何工作的，它應該展示如何使用它。顯示端到端工作流的代碼示例；為你的 API 的每個常見用例和關鍵特性展示代碼示例。

生產力可以歸結為快速決策和偏好行動。

軟體職業生涯

事業的進步不在於你管理了多少人，而在於你產生了多大的影響：一個有沒有你的工作的世界的差別。

軟體開發是團隊合作 ; 它不僅關乎技術能力，也關乎人際關係。做一個好的隊友。當你開始做事情的時候，要和別人保持溝通。

技術從來都不是中立的。如果你的工作對世界有任何影響，那麼這種影響是有道德導向的。我們在軟體產品中做出的看似無害的技術選擇調整了獲得技術的條件、使用動機、誰將受益、誰將受害。技術選擇也是倫理選擇。因此，對於你希望你的選擇支持的價值，一定要慎重和明確。設計倫理。把你的價值觀融入你的作品中。永遠不要想，我只是在建立能力 ; 它本身是中性的。這並不是因為你構建它的方式決定了它將如何被使用。

自我指導——掌控你的工作和環境——是獲得生活滿足感的關鍵。確保你給你周圍的人足夠的自我導向，確保你的職業選擇為你自己帶來更大的回報。

創造世界所需要的，而不僅僅是你希望擁有的。技術人員往往過著精細化的生活，專註於滿足自己特定需求的產品。尋找機會拓寬你的生活經驗，這將使你更好地看到世界需要什麼。

當做出任何具有長期影響的選擇時，將你的價值觀置於短期的自我利益和短暫的情緒之上——比如貪婪或恐懼。知道你的價值觀是什麼，讓它們來引導你。

當我們發現自己陷入矛盾中時，應該停下來尋找我們共同的價值觀和共同的目標，並提醒自己，我們幾乎肯定站在同一條戰線上。

生產力可以歸結為快速決策和偏好行動。這需要 a) 來自經驗的良好直覺，以便在給出部分信息的情況下做出普遍正確的決定 ; b) 對何時要小心地前進或等待更多信息要有敏銳的意識，因為一個錯誤的決定的代價將大於等待的代價。 在不同的環境中，最佳速度 / 質量決策權衡可能會有很大的差異。

快速的做決定意味著在你的職業生涯中你會做出更多的決定，這會讓你對可用選擇的正確性有更強的直覺。經驗是生產力的關鍵，更高的生產力將為你提供更多的經驗: 一個良性循環。

在你意識到自己缺乏直覺的情況下，堅持抽象的原則。在你的職業生涯中建立一個可靠的原則清單。原則是形式化的直覺，比原始模式識別適用於更廣泛的情況 (這需要對類似情況有直接且廣泛的經驗)。

英文原文

https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d

敲黑板劃重點！

由 InfoQ 中國主辦的 ArchSummit 全球架構師峰會即將於 12 月 7-8 日在北京國際會議中心舉辦，來自 Netflix、LinkedIn、騰訊、阿里、百度、京東等百位知名企業的架構師都將前來分享各自的架構實踐，一線技術大牛將現場與你深入交流。

你們能了解最前沿的國際技術趨勢，也能學習到各互聯網巨頭大浪淘沙後的技術結晶。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！