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

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