**是一種交流方式，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 的錯誤訊息。
因為**是一種交流方式，所以命名很重要——無論是命名專案還是變數。名字反映了你對問題的看法。避免使用過於通用的名稱 (x、變數、引數)，避免使用過於冗長和特定的命名模式，避免使用可能造成不必要誤解的術語 (主、從)，並確保你的命名選擇方式是一致的。命名一致性意味著內部命名一致性 (不要在其他地方將「dim」稱為「axis」) 和與問題域的既定約定的一致性。在確定名稱之前，請確保查詢領域專家 (或其他 api) 使用的現有名稱。
show, don 't tell：你的文件不應該討論軟體是如何工作的，它應該展示如何使用它。顯示端到端工作流的**示例；為你的 api 的每個常見用例和關鍵特性展示**示例。
生產力可以歸結為快速決策和偏好行動。事業的進步不在於你管理了多少人，而在於你產生了多大的影響：乙個有沒有你的工作的世界的差別。
軟體開發是團隊合作 ; 它不僅關乎技術能力，也關乎人際關係。做乙個好的隊友。當你開始做事情的時候，要和別人保持溝通。
技術從來都不是中立的。如果你的工作對世界有任何影響，那麼這種影響是有道德導向的。我們在軟體產品中做出的看似無害的技術選擇調整了獲得技術的條件、使用動機、誰將受益、誰將受害。技術選擇也是倫理選擇。因此，對於你希望你的選擇支援的價值，一定要慎重和明確。設計倫理。把你的價值觀融入你的作品中。永遠不要想，我只是在建立能力 ; 它本身是中性的。這並不是因為你構建它的方式決定了它將如何被使用。
自我指導——掌控你的工作和環境——是獲得生活滿足感的關鍵。確保你給你周圍的人足夠的自我導向，確保你的職業選擇為你自己帶來更大的回報。
創造世界所需要的，而不僅僅是你希望擁有的。技術人員往往過著精細化的生活，專注於滿足自己特定需求的產品。尋找機會拓寬你的生活經驗，這將使你更好地看到世界需要什麼。
當做出任何具有長期影響的選擇時，將你的價值觀置於短期的自我利益和短暫的情緒之上——比如貪婪或恐懼。知道你的價值觀是什麼，讓它們來引導你。
當我們發現自己陷入矛盾中時，應該停下來尋找我們共同的價值觀和共同的目標，並提醒自己，我們幾乎肯定站在同一條戰線上。
生產力可以歸結為快速決策和偏好行動。這需要 a) 來自經驗的良好直覺，以便在給出部分資訊的情況下做出普遍正確的決定 ; b) 對何時要小心地前進或等待更多資訊要有敏銳的意識，因為乙個錯誤的決定的代價將大於等待的代價。 在不同的環境中，最佳速度 / 質量決策權衡可能會有很大的差異。
快速的做決定意味著在你的職業生涯中你會做出更多的決定，這會讓你對可用選擇的正確性有更強的直覺。經驗是生產力的關鍵，更高的生產力將為你提供更多的經驗: 乙個良性迴圈。
給年輕程式設計師的33條忠告
作者 fran ois chollet 譯者 小大非 是一種交流方式，keras 之父 fran ois chollet 在本文中為我們總結了在開發過程中 api 設計中及軟體職業生涯中應該關注哪些要點。原則是形式化的直覺，比原始模式識別適用於更廣泛的情況，fran ois chollet 的這份原...
文摘加感悟 中年程式設計師給年輕程式設計師的忠告
好 就是能夠自解釋的 沒有注釋，就是最好的注釋。但是做到這一點，很難。keras 之父 francois chollet 說過 不僅僅是用來執行的，也是團隊交流的一種方式，是向他人描述問題解決方案的一種方式。所以命名很重要，避免使用過於籠統的名稱，避免使用過於冗長的命名，避免歧義。盡量使用業內常見的...
給新入坑的程式設計師十條忠告
1.明確職業規劃和學習計畫，針對性的去學習，摟原始碼，深入底層，效能，架構，提高技術深度和廣度,把寫程式當做一種愛好 2.多鍛鍊身體，畢竟網際網路加班會比較多，身體是本錢，沒有健康一切夢想都免談 3.豐富自己的業餘生活，培養自己的興趣愛好，堅決杜絕死宅 4.多讀書，提高自身修養與氣質，養成良好的閱讀...