Keras之父親傳，一個軟件工程師的成長自查清單
轉(zhuǎn)自：大數(shù)據(jù)文摘
編譯：Travis、茶西、Aileen
創(chuàng)造了Keras的 Francois Chollet近期在博客上分享了他個人的提醒清單,老司機帶我們少走彎路。
在開發(fā)過程中
代碼不僅僅是為了被執(zhí)行的，也是一種團隊內(nèi)共同交流的方式。我們可以使用代碼來向別人描述問題的解決方案。代碼的可讀性包括清晰的分段，易懂的變量名，以及描述隱含內(nèi)容的注釋。可讀性并不是錦上添花，而是寫代碼必備的屬性。
不要去想這次工作對自己下一次升值有什么幫助，而要去努力思考可以為自己產(chǎn)品的用戶和社區(qū)做些什么。不惜一切代價避免“顯眼的貢獻”。不是真正對產(chǎn)品有幫助的功能，就不要添加
個人品味也會反映在代碼上。品味是一種約束－在簡單性的渴望將這種可約束性滿足的品味變得系統(tǒng)化。請保持對簡單性的不懈追求。
味道也適用于代碼。品味是一種約束-對于過程的滿足感和對于代碼簡約的欲望之間的平衡。請保持你對簡約的傾向。
學(xué)會拒絕。如果有人要求給代碼添加新的功能，我們有權(quán)利拒絕。實際上，每個功能的成本都超出了最初的設(shè)想：維護成本，文檔成本和用戶的認知成本。每當(dāng)被要求添加代碼功能的時候，記得問問自己：我們真的應(yīng)該這樣做嗎？通常來說，答案是否定的。
當(dāng)你決定為產(chǎn)品添加新的用例，需要注意的是，如果你按照用戶請求的字面意思去添加內(nèi)容，這樣反而達不到最佳效果。用戶專注于他們自己的特定用例，而你必須從項目的整體和原則來考慮。通常，我們應(yīng)該擴展現(xiàn)有功能而不是增加一個非常零碎的模塊。
以持續(xù)集成和全面的代碼單元測試為目標(biāo)做出投資。始終確保自己處于一個能夠自信地編碼的環(huán)境中；如果不能夠擁有靠譜的環(huán)境，首先要去建立合適的基礎(chǔ)設(shè)施。
你可以不用事事都提前做好準(zhǔn)備。有時候可以先嘗試一下，看看結(jié)果如何，然后盡早更改錯誤的嘗試。確保你建立了一個可以執(zhí)行上述一切的環(huán)境。
好的軟件讓事情變得簡單。雖然問題看起來很困難，但是這并不意味著解決方案必須復(fù)雜或難以使用。很多時候，我們有一個更容易并且并那么耀眼的辦法，工程師卻會選擇使用更加復(fù)雜的有副作用的解決方案（畫外音：“讓我們使用機器學(xué)習(xí)吧”！“讓我們構(gòu)建一個應(yīng)用！”“讓我們添加區(qū)塊鏈！”）在編寫任何代碼之前，請確保自己選擇的解決方案是最簡單的。從簡單第一的原則著手，給出解決方案。
避免一切隱含規(guī)則。如果你發(fā)現(xiàn)自己開發(fā)的代碼中有一些隱含規(guī)則，請用注釋注明并與他人共享或自動化。每當(dāng)你發(fā)現(xiàn)一個可重復(fù)的，類似于算法的工作流程時，應(yīng)該設(shè)法將其文檔化，以便其他團隊成員從你的發(fā)現(xiàn)中受益。此外，你還應(yīng)該設(shè)法在軟件中自動化該工作流程的任何部分（例如正確性檢查）。
從整個產(chǎn)品的設(shè)計過程去考慮你代碼改動將會帶來的影響，而不僅僅是關(guān)注你想要的部分-例如收入或增長。除了你正在監(jiān)控的特定指標(biāo)之外，您的軟件對全球用戶的總體影響是什么？是否存在任何副作用？在保留軟件實用性的同時，你可以做些什么來解決這些問題？
關(guān)于API（應(yīng)用程序接口）設(shè)計
你的API擁有用戶，因此涉及到用戶體驗。在你做出的每一個決定中，始終牢記用戶。請設(shè)身處地去理解你的用戶，無論他們是初學(xué)者還是經(jīng)驗豐富的開發(fā)人員。
盡量減少用戶在使用API時的認知負擔(dān)。自動化可自動化的內(nèi)容，最大限度地減少用戶所需的操作和選擇量，不要暴露不重要的選項，設(shè)計簡單一致的工作流程，以反映簡單一致的心智模型。
把簡單的功能保持簡單，讓復(fù)雜的功能變成可能。不要為了實現(xiàn)某個特定功能而增加常用功能的認知成本。
如果工作流的認知成本足夠低，那么用戶應(yīng)該可以在完成一次或兩次之后就可以記住（而無需再次查看教程或文檔）。
尋求與領(lǐng)域?qū)＜液蛷臉I(yè)者的心智模型相匹配的API。有領(lǐng)域經(jīng)驗但沒有API經(jīng)驗的人應(yīng)該能夠使用最少的文檔來直觀地理解你的API。他們主要會查看代碼示例，可用對象及其簽名。
即使沒有關(guān)于底層實現(xiàn)的任何材料，參數(shù)的含義也應(yīng)該是容易被理解的。而由用戶指定的參數(shù)應(yīng)該與用戶對問題的心智模型有關(guān)，而不是與代碼中的實現(xiàn)細節(jié)有關(guān)。API只和它解決的問題相關(guān)，而與軟件如何在后臺運行無關(guān)。
最強大的心智模型是模塊化和層次化的：總體很簡潔，當(dāng)你查看細節(jié)時又很精確。同樣，一個好的API也是模塊化和分層的：易于著手，但具有表現(xiàn)力。在更少對象上使用復(fù)雜簽名，和在更多對象上使用簡單簽名之間存在一個平衡。一個好的API具有合理數(shù)量的對象，而且具有合理簡單的簽名。
你的API不可避免地反映了你的實現(xiàn)選擇，特別是你選擇的數(shù)據(jù)結(jié)構(gòu)。要實現(xiàn)直觀的API，你必須選擇自然適合該領(lǐng)域的數(shù)據(jù)結(jié)構(gòu)。這與該領(lǐng)域?qū)＜业男闹悄Ｐ拖嗥ヅ洹?/span>
深思熟慮地去設(shè)計從始到終的工作流程，而不僅僅是一系列原子功能。大多數(shù)開發(fā)人員去開發(fā)API的時候，會通過詢問“應(yīng)該提供哪些功能？讓我們?yōu)樗麄兣渲眠x項。”而不是，請問“這個工具有什么使用場景？對于每個使用場景，用戶操作的最佳順序是什么？什么是最簡單的API可以支持這個工作流程？”API中的原子選項應(yīng)該滿足高級工作流程中出現(xiàn)的明確需求。“因為有人可能需要它”，并不是添加理由。
錯誤消息，以及通常在與API交互過程中向用戶提供的任何反饋，都是API的一部分。交互性和反饋是用戶體驗不可或缺的一部分。設(shè)計API的錯誤消息請深思熟慮。
因為代碼是為了交流，所以命名很重要-無論是命名項目還是變量。名稱反映了你對問題的看法。避免過于通用的名稱（例如“x，變量，參數(shù)”），避免過度長和特定的命名，避免可能產(chǎn)生不必要糾紛的術(shù)語（例如“奴隸主/奴隸”），并確保在命名選擇中保持一致。命名一致性意味著內(nèi)部命名一致性（例如，不要命名“軸”的時候既用“dim”又用“axis”），以及與問題域已建立約定的一致性。在確定名稱之前，請確保查找域?qū)＜遥ɑ蚱渌鸄PI）使用的現(xiàn)有名稱。
文檔是API用戶體驗的核心。它不是附加組件。花時間去撰寫高質(zhì)量的文件，相較于花時間在其他的功能上，你會看到更高的回報。
用"展示"代替＂敘述＂：你的文檔不應(yīng)該談?wù)撥浖绾喂ぷ鳎鼞?yīng)該展示如何使用它。展示從頭到尾工作流程的代碼示例；顯示API的每個常見用例和關(guān)鍵功能的代碼示例。
給軟件工程師職業(yè)生涯的建議
職業(yè)進步并不是你管理的人數(shù)，而是你所產(chǎn)生的影響：你的工作是否為世界帶來改變。
軟件開發(fā)是團隊合作，人際關(guān)系和技術(shù)能力同樣重要。做個優(yōu)秀的隊友。當(dāng)你走在職業(yè)道路上時，記得與他人保持聯(lián)系。
技術(shù)永遠不會中立。如果你的工作對世界有任何影響，那么這種影響就有道德方向。我們在軟件產(chǎn)品中看似無害的技術(shù)選擇調(diào)整了技術(shù)獲取的條件，技術(shù)的使用激勵，誰將受益以及誰將受到影響：技術(shù)選擇也是道德選擇。因此，始終謹慎而明確地表達你想通過選擇支持的價值觀。為道德而設(shè)計并將你的價值觀融入到你的創(chuàng)作中。永遠不要想“我只是在建立這種功能，這本身就是中立的“：它不是，因為你構(gòu)建它的方式?jīng)Q定了它的使用方式。
建立世界需要的東西，而不僅僅是你希望擁有的東西。很多時候，技術(shù)人員過著遠離常人的生活，專注于滿足自身特定需求的產(chǎn)品。尋求擴大生活體驗的機會，讓你更好地了解世界需求。
在做出有著長期影響的任何選擇時，將你的價值觀置于短期的自身利益和情緒之上，例如貪婪或恐懼。了解你的價值觀是什么，并讓它們指導(dǎo)你。
當(dāng)我們發(fā)現(xiàn)自己陷入沖突時，暫停一下，承認我們的共同價值觀和共同目標(biāo)是個好主意，并提醒自己，我們幾乎肯定是站在同一邊。
生產(chǎn)力歸結(jié)為高速決策和行動偏見。這需要：1.）來自經(jīng)驗的良好直覺，以便在給出部分信息的情況下做出大體正確的決定；2.）敏銳地意識到何時更謹慎地行事并等待更多信息，因為錯誤決策比延遲決策的成本更高。在不同環(huán)境中，最佳速度/質(zhì)量的決策權(quán)衡可以有很大差異。
更快地做出決定意味著你在職業(yè)生涯中做出更多決策，這將使你對可能選項的正確性有更強的直覺。經(jīng)驗是提高生產(chǎn)力的關(guān)鍵，更高的生產(chǎn)力將為您提供更多的經(jīng)驗。這是一個良性循環(huán)。
在你意識到缺乏直覺的情況下，堅持抽象的原則。在整個職業(yè)生涯中建立可靠且正確的原則列表：原則是形式化的直覺，和原始模式識別（需要直接和廣泛的類似情境經(jīng)驗）相比，可以推廣到更廣泛的情境。
相關(guān)報道：
https://medium.com/@francois.chollet/notes-to-myself-on-software-engineering-c890f16f4e4d
往期精彩：
【原創(chuàng)首發(fā)】機器學(xué)習(xí)公式推導(dǎo)與代碼實現(xiàn)30講.pdf
【原創(chuàng)首發(fā)】深度學(xué)習(xí)語義分割理論與實戰(zhàn)指南.pdf