創造了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.）敏銳地意識到何時更謹慎地行事並等待更多資訊，因為錯誤決策比延遲決策的成本更高。在不同環境中，最佳速度/質量的決策權衡可以有很大差異。

• 更快地做出決定意味著你在職業生涯中做出更多決策，這將使你對可能選項的正確性有更強的直覺。經驗是提高生產力的關鍵，更高的生產力將為您提供更多的經驗。這是一個良性迴圈。

• 在你意識到缺乏直覺的情況下，堅持抽象的原則。在整個職業生涯中建立可靠且正確的原則列表：原則是形式化的直覺，和原始模式識別（需要直接和廣泛的類似情境經驗）相比，可以推廣到更廣泛的情境。

關注公眾賬號

【飛馬會】

▼

往期福利

關注飛馬會公眾號，回覆對應關鍵詞打包下載學習資料；回覆“入群”，加入飛馬網AI、大資料、專案經理學習群，和優秀的人一起成長！

回覆 數字“1”下載從入門到研究，人工智慧領域最值得一讀的10本資料（附下載）

回覆 數字“2”機器學習 & 資料科學必讀的經典書籍，內附資料包！