1. 程式人生 > >“Keras之父”親傳,一個軟體工程師的成長自查清單

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

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

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

關注公眾賬號

飛馬會

 

 

 

往期福利

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

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

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