“Keras之父”親傳，一個軟體工程師的成長自查清單
創造了Keras的 Francois Chollet近期在部落格上分享了他個人的提醒清單,老司機帶我們少走彎路。
在開發過程中
-
程式碼不僅僅是為了被執行的，也是一種團隊內共同交流的方式。我們可以使用程式碼來向別人描述問題的解決方案。程式碼的可讀性包括清晰的分段，易懂的變數名，以及描述隱含內容的註釋。可讀性並不是錦上添花，而是寫程式碼必備的屬性。
-
不要去想這次工作對自己下一次升值有什麼幫助，而要去努力思考可以為自己產品的使用者和社群做些什麼。不惜一切代價避免“顯眼的貢獻”。不是真正對產品有幫助的功能，就不要新增。
-
個人品味也會反映在程式碼上。品味是一種約束－在簡單性的渴望將這種可約束性滿足的品味變得系統化。請保持對簡單性的不懈追求。
-
味道也適用於程式碼。品味是一種約束-對於過程的滿足感和對於程式碼簡約的慾望之間的平衡。請保持你對簡約的傾向。
-
學會拒絕。如果有人要求給程式碼新增新的功能，我們有權利拒絕。實際上，每個功能的成本都超出了最初的設想：維護成本，文件成本和使用者的認知成本。每當被要求新增程式碼功能的時候，記得問問自己：我們真的應該這樣做嗎？通常來說，答案是否定的。
-
當你決定為產品新增新的用例，需要注意的是，如果你按照使用者請求的字面意思去新增內容，這樣反而達不到最佳效果。使用者專注於他們自己的特定用例，而你必須從專案的整體和原則來考慮。通常，我們應該擴充套件現有功能而不是增加一個非常零碎的模組。
-
以持續整合和全面的程式碼單元測試為目標做出投資。始終確保自己處於一個能夠自信地編碼的環境中；如果不能夠擁有靠譜的環境，首先要去建立合適的基礎設施。
-
你可以不用事事都提前做好準備。有時候可以先嚐試一下，看看結果如何，然後儘早更改錯誤的嘗試。確保你建立了一個可以執行上述一切的環境。
-
好的軟體讓事情變得簡單。雖然問題看起來很困難，但是這並不意味著解決方案必須複雜或難以使用。很多時候，我們有一個更容易並且並那麼耀眼的辦法，工程師卻會選擇使用更加複雜的有副作用的解決方案（畫外音：“讓我們使用機器學習吧”！“讓我們構建一個應用！”“讓我們新增區塊鏈！”）在編寫任何程式碼之前，請確保自己選擇的解決方案是最簡單的。從簡單第一的原則著手，給出解決方案。
-
避免一切隱含規則。如果你發現自己開發的程式碼中有一些隱含規則，請用註釋註明並與他人共享或自動化。每當你發現一個可重複的，類似於演算法的工作流程時，應該設法將其文件化，以便其他團隊成員從你的發現中受益。此外，你還應該設法在軟體中自動化該工作流程的任何部分（例如正確性檢查）。
-
從整個產品的設計過程去考慮你程式碼改動將會帶來的影響，而不僅僅是關注你想要的部分-例如收入或增長。除了你正在監控的特定指標之外，您的軟體對全球使用者的總體影響是什麼？是否存在任何副作用？在保留軟體實用性的同時，你可以做些什麼來解決這些問題？
關於API（應用程式介面）設計
-
你的API擁有使用者，因此涉及到使用者體驗。在你做出的每一個決定中，始終牢記使用者。請設身處地去理解你的使用者，無論他們是初學者還是經驗豐富的開發人員。
-
儘量減少使用者在使用API時的認知負擔。自動化可自動化的內容，最大限度地減少使用者所需的操作和選擇量，不要暴露不重要的選項，設計簡單一致的工作流程，以反映簡單一致的心智模型。
-
把簡單的功能保持簡單，讓複雜的功能變成可能。不要為了實現某個特定功能而增加常用功能的認知成本。
-
如果工作流的認知成本足夠低，那麼使用者應該可以在完成一次或兩次之後就可以記住（而無需再次檢視教程或文件）。
-
尋求與領域專家和從業者的心智模型相匹配的API。有領域經驗但沒有API經驗的人應該能夠使用最少的文件來直觀地理解你的API。他們主要會檢視程式碼示例，可用物件及其簽名。
-
即使沒有關於底層實現的任何材料，引數的含義也應該是容易被理解的。而由使用者指定的引數應該與使用者對問題的心智模型有關，而不是與程式碼中的實現細節有關。API只和它解決的問題相關，而與軟體如何在後臺執行無關。
-
最強大的心智模型是模組化和層次化的：總體很簡潔，當你檢視細節時又很精確。同樣，一個好的API也是模組化和分層的：易於著手，但具有表現力。在更少物件上使用複雜簽名，和在更多物件上使用簡單簽名之間存在一個平衡。一個好的API具有合理數量的物件，而且具有合理簡單的簽名。
-
你的API不可避免地反映了你的實現選擇，特別是你選擇的資料結構。要實現直觀的API，你必須選擇自然適合該領域的資料結構。這與該領域專家的心智模型相匹配。
-
深思熟慮地去設計從始到終的工作流程，而不僅僅是一系列原子功能。大多數開發人員去開發API的時候，會通過詢問“應該提供哪些功能？讓我們為他們配置選項。”而不是，請問“這個工具有什麼使用場景？對於每個使用場景，使用者操作的最佳順序是什麼？什麼是最簡單的API可以支援這個工作流程？”API中的原子選項應該滿足高階工作流程中出現的明確需求。“因為有人可能需要它”，並不是新增理由。
-
錯誤訊息，以及通常在與API互動過程中向用戶提供的任何反饋，都是API的一部分。互動性和反饋是使用者體驗不可或缺的一部分。設計API的錯誤訊息請深思熟慮。
-
因為程式碼是為了交流，所以命名很重要-無論是命名專案還是變數。名稱反映了你對問題的看法。避免過於通用的名稱（例如“x，變數，引數”），避免過度長和特定的命名，避免可能產生不必要糾紛的術語（例如“奴隸主/奴隸”），並確保在命名選擇中保持一致。命名一致性意味著內部命名一致性（例如，不要命名“軸”的時候既用“dim”又用“axis”），以及與問題域已建立約定的一致性。在確定名稱之前，請確保查詢域專家（或其他API）使用的現有名稱。
-
文件是API使用者體驗的核心。它不是附加元件。花時間去撰寫高質量的檔案，相較於花時間在其他的功能上，你會看到更高的回報。
-
用"展示"代替＂敘述＂：你的文件不應該談論軟體如何工作，它應該展示如何使用它。展示從頭到尾工作流程的程式碼示例；顯示API的每個常見用例和關鍵功能的程式碼示例。
給軟體工程師職業生涯的建議
-
職業進步並不是你管理的人數，而是你所產生的影響：你的工作是否為世界帶來改變。
-
軟體開發是團隊合作，人際關係和技術能力同樣重要。做個優秀的隊友。當你走在職業道路上時，記得與他人保持聯絡。
-
技術永遠不會中立。如果你的工作對世界有任何影響，那麼這種影響就有道德方向。我們在軟體產品中看似無害的技術選擇調整了技術獲取的條件，技術的使用激勵，誰將受益以及誰將受到影響：技術選擇也是道德選擇。因此，始終謹慎而明確地表達你想通過選擇支援的價值觀。為道德而設計並將你的價值觀融入到你的創作中。永遠不要想“我只是在建立這種功能，這本身就是中立的“：它不是，因為你構建它的方式決定了它的使用方式。
-
建立世界需要的東西，而不僅僅是你希望擁有的東西。很多時候，技術人員過著遠離常人的生活，專注於滿足自身特定需求的產品。尋求擴大生活體驗的機會，讓你更好地瞭解世界需求。
-
在做出有著長期影響的任何選擇時，將你的價值觀置於短期的自身利益和情緒之上，例如貪婪或恐懼。瞭解你的價值觀是什麼，並讓它們指導你。
-
當我們發現自己陷入衝突時，暫停一下，承認我們的共同價值觀和共同目標是個好主意，並提醒自己，我們幾乎肯定是站在同一邊。
-
生產力歸結為高速決策和行動偏見。這需要：1.）來自經驗的良好直覺，以便在給出部分資訊的情況下做出大體正確的決定；2.）敏銳地意識到何時更謹慎地行事並等待更多資訊，因為錯誤決策比延遲決策的成本更高。在不同環境中，最佳速度/質量的決策權衡可以有很大差異。
-
更快地做出決定意味著你在職業生涯中做出更多決策，這將使你對可能選項的正確性有更強的直覺。經驗是提高生產力的關鍵，更高的生產力將為您提供更多的經驗。這是一個良性迴圈。
-
在你意識到缺乏直覺的情況下，堅持抽象的原則。在整個職業生涯中建立可靠且正確的原則列表：原則是形式化的直覺，和原始模式識別（需要直接和廣泛的類似情境經驗）相比，可以推廣到更廣泛的情境。