Keras作者：給軟體開發者的33條黃金法則

新智元AI WORLD 2018世界人工智慧峰會

倒計時9天

新智元將於9月20日在北京國家會議中心舉辦AI WORLD 2018世界人工智慧峰會，CMU機器學習系創始人、教科書Machine Learning作者、被譽為「機器學習教父」的Tom Mitchell將親臨會場做《人工智慧與我們的未來》主題演講。Mithcell教授表示，這將是一場融入深度思考與偏技術討論的報告。

活動行購票二維碼：

新智元報道

作者：Fran?ois Chollet

編輯：肖琴

【新智元導讀】Keras作者、谷歌大腦的谷歌大腦 Fran?ois Chollet從軟體開發流程、API設計和職業規劃方面給開發者列出的33條注意事項，相信可以讓你避開很多大坑，一起來看看吧。

關於開發流程

1、代碼不僅僅是意味著要執行。代碼也是跨團隊溝通的一種方式，是向他人描述問題解決方案的一種方式。可讀代碼是必須的，是編寫代碼的基本。這包括清晰地分解代碼，選擇一目了然的變數名，以及插入注釋來描述任何隱含的內容。

2、不要問你的pull request能為你的下一次推廣做什麼，而要問你的pull request能為用戶和社區做什麼。不惜一切代價避免「引人注目的貢獻」。如果這個功能對產品的目的沒有明顯的幫助，就不要添加任何功能。

3、品味也適用於代碼。品味是一種約束-滿足的過程，由對簡單性的渴望所規範。保持對簡單性的偏倚。

4、可以拒絕——僅僅因為有人要求某個功能並不意味著你就應該這麼做。每個功能都有一個超出初始實現的成本：維護成本、文檔成本和用戶的認知成本。應該總是問：我們真的應該這樣做嗎？通常，答案是否定的。

5、當你對支持新用例的請求說「是」時，請記住，按字面意思添加用戶請求的內容通常不是最佳選擇。用戶關注的是他們自己的特定用例，你必須以整個項目的整體視角和原則視角來應對這一點。通常，正確的答案是擴展現有的功能。

6、投資於持續集成，並以全面的單元測試覆蓋為目標。確保你處在一個可以自信地編碼的環境中；如果不是，那麼就從構建正確的基礎設施開始。

7、如果沒有事先計劃好一切，沒關係。嘗試一下，看看結果如何。儘早恢復錯誤的選擇。確保創建了一個可行的環境。

8、好的軟體能讓困難的事情變簡單。僅僅因為一開始問題看起來很困難，並不意味著解決方案必須很複雜或者很難使用。工程師們經常採用習慣性思維的解決方案，這種方案會帶來不必要的複雜性和副作用（「讓我們使用ML吧！讓我們構建一個應用程序！讓我們添加區塊鏈！」)，或許還存在可能不那麼明顯，但是更容易的替代方案。在編寫任何代碼之前，請確保你所選擇的解決方案是最簡單的。從第一原則著手。

9、避免隱式規則。你自己開發的隱式規則應該始終是明確的，並與他人共享或能夠自動化。當你發現自己提出了一個重複的、擬演算法的工作流時，應該設法將它形式化為一個文檔化的流程，以便其他團隊成員能夠從經驗中獲益。此外，你應該設法在軟體中自動化任何可以自動化的工作流程（例如正確性檢查）。

10、應該在設計過程中考慮你的選擇的總體影響，而不僅僅考慮你想要關注的方面——比如收入或增長。除了正在監控的度量之外，你的軟體對其用戶、對世界的總體影響是什麼？是否有超出其價值主張的副作用？在保持軟體有用性的同時，你還能做些什麼來解決這些問題？

關於API設計

1、你的API擁有用戶，因此要考慮用戶體驗。在你所做的每一個決定中，始終牢記用戶。對你的用戶感同身受，無論他們是初學者還是經驗豐富的開發人員。

2、始終追求盡量減少用戶在使用API過程中的認知負擔。自動化可以自動化的一切東西，最小化用戶需要的操作和選擇，不要顯示不重要的選項，設計簡單一致的工作流，反映簡單一致的思維模型。

3、簡單的事情應該是簡單的，複雜的事情應該是可能的。不要為了小範圍的用例而增加普通用例的認知負擔，即使是最低限度的。

4、如果工作流的認知負載足夠低，那麼用戶在完成一到兩次工作之後，應該可以從記憶中遍歷工作流（無需查找教程或文檔）。

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

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

7、最強大的心理模型是模塊化和層次化的：在高層次上很簡單，但在細節上很精確。同樣，一個好的API是模塊化和層次化的：易於上手，但富有表現力。一個好的API有合理數量的對象，有相當簡單的簽名。

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

9、設計端到端工作流，而不是一組基本特性。大多數開發人員通過詢問「應該提供哪些功能？讓我們為它們提供配置選項。」相反，要問「這個工具的用例是什麼？對於每個用例，用戶操作的最佳順序是什麼？支持這個工作流的最簡單的API是什麼？」API中的基本選項應該能夠滿足高層次工作流中出現的明顯需求——不應該因為「可能有人需要」而添加它們。

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

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

12、文檔是API用戶體驗的中心。它不是一個附加組件。投入於高質量的文檔；這將比投入更多功能有更高的回報。

13、展示，而非解釋：你的文檔不應該討論軟體如何工作，而應該展示如何使用它。展示端到端工作流的代碼示例；為API的每個常見用例和關鍵特性展示代碼示例。

關於軟體設計師的職業規劃

1、職業發展不在於你管理了多少人，而在於你創造了多少影響。

2、軟體開發是團隊合作；它不僅關乎技術能力，也關乎人際關係。做一個好的隊友。當你走在路上，要和別人保持聯繫。

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

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

5、創造世界所需要的東西，而不僅僅是你自己希望擁有的東西。技術人員往往專註於滿足資深特定需求的產品。尋找機會拓寬你的生活體驗，這將幫助你更好地了解世界需要什麼。

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

7、當我們發現自己陷入衝突時，停下來確認我們共同的價值觀和共同的目標是個好主意，並提醒自己，我們幾乎肯定站在同一條戰線上。

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

9、更快地做出決策意味著你在職業生涯中要做出更多決策，這將使你對可用選項的正確性有更強的直覺。經驗是提高生產力的關鍵，更高的生產力將為你提供更多的經驗：良性循環。

10、在你意識到自己缺乏直覺的情況下，請遵守抽象原則。在整個職業生涯中建立一份可靠且實際的原則列表：原則是形式化的直覺，它適用於比原始模式識別更廣泛的情境。

參考鏈接：

https://medium.com/@francois.chollet/notes-to-myself-on-software-engineering-c890f16f4e4d

新智元AI WORLD 2018世界人工智慧峰會

倒計時9天

門票已開售！

新智元將於9月20日在北京國家會議中心舉辦AI WORLD 2018世界人工智慧峰會，邀請機器學習教父、CMU教授 Tom Mitchell，邁克思·泰格馬克，周志華，陶大程，陳怡然等AI領袖一起關注機器智能與人類命運。

大會官網：

http://www.aiworld2018.com/

活動行購票鏈接：

http://www.huodongxing.com/event/6449053775000

活動行購票二維碼：

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