業(yè)界 | Keras之父親傳，一個(gè)軟件工程師的成長(zhǎng)自查清單

轉(zhuǎn)自：大數(shù)據(jù)文摘

編譯：Travis、茶西、Aileen

• 代碼不僅僅是為了被執(zhí)行的，也是一種團(tuán)隊(duì)內(nèi)共同交流的方式。我們可以使用代碼來(lái)向別人描述問(wèn)題的解決方案。代碼的可讀性包括清晰的分段，易懂的變量名，以及描述隱含內(nèi)容的注釋。可讀性并不是錦上添花，而是寫代碼必備的屬性。

  
  

• 不要去想這次工作對(duì)自己下一次升值有什么幫助，而要去努力思考可以為自己產(chǎn)品的用戶和社區(qū)做些什么。不惜一切代價(jià)避免“顯眼的貢獻(xiàn)”。不是真正對(duì)產(chǎn)品有幫助的功能，就不要添加

  
  

• 個(gè)人品味也會(huì)反映在代碼上。品味是一種約束－在簡(jiǎn)單性的渴望將這種可約束性滿足的品味變得系統(tǒng)化。請(qǐng)保持對(duì)簡(jiǎn)單性的不懈追求。

  
  

• 味道也適用于代碼。品味是一種約束-對(duì)于過(guò)程的滿足感和對(duì)于代碼簡(jiǎn)約的欲望之間的平衡。請(qǐng)保持你對(duì)簡(jiǎn)約的傾向。

  
  

• 學(xué)會(huì)拒絕。如果有人要求給代碼添加新的功能，我們有權(quán)利拒絕。實(shí)際上，每個(gè)功能的成本都超出了最初的設(shè)想：維護(hù)成本，文檔成本和用戶的認(rèn)知成本。每當(dāng)被要求添加代碼功能的時(shí)候，記得問(wèn)問(wèn)自己：我們真的應(yīng)該這樣做嗎？通常來(lái)說(shuō)，答案是否定的。

  
  

• 當(dāng)你決定為產(chǎn)品添加新的用例，需要注意的是，如果你按照用戶請(qǐng)求的字面意思去添加內(nèi)容，這樣反而達(dá)不到最佳效果。用戶專注于他們自己的特定用例，而你必須從項(xiàng)目的整體和原則來(lái)考慮。通常，我們應(yīng)該擴(kuò)展現(xiàn)有功能而不是增加一個(gè)非常零碎的模塊。

  
  

• 以持續(xù)集成和全面的代碼單元測(cè)試為目標(biāo)做出投資。始終確保自己處于一個(gè)能夠自信地編碼的環(huán)境中；如果不能夠擁有靠譜的環(huán)境，首先要去建立合適的基礎(chǔ)設(shè)施。

  
  

• 你可以不用事事都提前做好準(zhǔn)備。有時(shí)候可以先嘗試一下，看看結(jié)果如何，然后盡早更改錯(cuò)誤的嘗試。確保你建立了一個(gè)可以執(zhí)行上述一切的環(huán)境。

  
  

• 好的軟件讓事情變得簡(jiǎn)單。雖然問(wèn)題看起來(lái)很困難，但是這并不意味著解決方案必須復(fù)雜或難以使用。很多時(shí)候，我們有一個(gè)更容易并且并那么耀眼的辦法，工程師卻會(huì)選擇使用更加復(fù)雜的有副作用的解決方案（畫(huà)外音：“讓我們使用機(jī)器學(xué)習(xí)吧”！“讓我們構(gòu)建一個(gè)應(yīng)用！”“讓我們添加區(qū)塊鏈！”）在編寫任何代碼之前，請(qǐng)確保自己選擇的解決方案是最簡(jiǎn)單的。從簡(jiǎn)單第一的原則著手，給出解決方案。

  
  

• 避免一切隱含規(guī)則。如果你發(fā)現(xiàn)自己開(kāi)發(fā)的代碼中有一些隱含規(guī)則，請(qǐng)用注釋注明并與他人共享或自動(dòng)化。每當(dāng)你發(fā)現(xiàn)一個(gè)可重復(fù)的，類似于算法的工作流程時(shí)，應(yīng)該設(shè)法將其文檔化，以便其他團(tuán)隊(duì)成員從你的發(fā)現(xiàn)中受益。此外，你還應(yīng)該設(shè)法在軟件中自動(dòng)化該工作流程的任何部分（例如正確性檢查）。

  
  

• 從整個(gè)產(chǎn)品的設(shè)計(jì)過(guò)程去考慮你代碼改動(dòng)將會(huì)帶來(lái)的影響，而不僅僅是關(guān)注你想要的部分-例如收入或增長(zhǎng)。除了你正在監(jiān)控的特定指標(biāo)之外，您的軟件對(duì)全球用戶的總體影響是什么？是否存在任何副作用？在保留軟件實(shí)用性的同時(shí)，你可以做些什么來(lái)解決這些問(wèn)題？

• 你的API擁有用戶，因此涉及到用戶體驗(yàn)。在你做出的每一個(gè)決定中，始終牢記用戶。請(qǐng)?jiān)O(shè)身處地去理解你的用戶，無(wú)論他們是初學(xué)者還是經(jīng)驗(yàn)豐富的開(kāi)發(fā)人員。

  
  

• 盡量減少用戶在使用API時(shí)的認(rèn)知負(fù)擔(dān)。自動(dòng)化可自動(dòng)化的內(nèi)容，最大限度地減少用戶所需的操作和選擇量，不要暴露不重要的選項(xiàng)，設(shè)計(jì)簡(jiǎn)單一致的工作流程，以反映簡(jiǎn)單一致的心智模型。

  
  

• 把簡(jiǎn)單的功能保持簡(jiǎn)單，讓復(fù)雜的功能變成可能。不要為了實(shí)現(xiàn)某個(gè)特定功能而增加常用功能的認(rèn)知成本。

  
  

• 如果工作流的認(rèn)知成本足夠低，那么用戶應(yīng)該可以在完成一次或兩次之后就可以記?。ǘ鵁o(wú)需再次查看教程或文檔）。

  
  

• 尋求與領(lǐng)域?qū)＜液蛷臉I(yè)者的心智模型相匹配的API。有領(lǐng)域經(jīng)驗(yàn)但沒(méi)有API經(jīng)驗(yàn)的人應(yīng)該能夠使用最少的文檔來(lái)直觀地理解你的API。他們主要會(huì)查看代碼示例，可用對(duì)象及其簽名。

  
  

• 即使沒(méi)有關(guān)于底層實(shí)現(xiàn)的任何材料，參數(shù)的含義也應(yīng)該是容易被理解的。而由用戶指定的參數(shù)應(yīng)該與用戶對(duì)問(wèn)題的心智模型有關(guān)，而不是與代碼中的實(shí)現(xiàn)細(xì)節(jié)有關(guān)。API只和它解決的問(wèn)題相關(guān)，而與軟件如何在后臺(tái)運(yùn)行無(wú)關(guān)。

  
  

• 最強(qiáng)大的心智模型是模塊化和層次化的：總體很簡(jiǎn)潔，當(dāng)你查看細(xì)節(jié)時(shí)又很精確。同樣，一個(gè)好的API也是模塊化和分層的：易于著手，但具有表現(xiàn)力。在更少對(duì)象上使用復(fù)雜簽名，和在更多對(duì)象上使用簡(jiǎn)單簽名之間存在一個(gè)平衡。一個(gè)好的API具有合理數(shù)量的對(duì)象，而且具有合理簡(jiǎn)單的簽名。

  
  

• 你的API不可避免地反映了你的實(shí)現(xiàn)選擇，特別是你選擇的數(shù)據(jù)結(jié)構(gòu)。要實(shí)現(xiàn)直觀的API，你必須選擇自然適合該領(lǐng)域的數(shù)據(jù)結(jié)構(gòu)。這與該領(lǐng)域?qū)＜业男闹悄Ｐ拖嗥ヅ洹?/span>

  
  

• 深思熟慮地去設(shè)計(jì)從始到終的工作流程，而不僅僅是一系列原子功能。大多數(shù)開(kāi)發(fā)人員去開(kāi)發(fā)API的時(shí)候，會(huì)通過(guò)詢問(wèn)“應(yīng)該提供哪些功能？讓我們?yōu)樗麄兣渲眠x項(xiàng)?！倍皇?，請(qǐng)問(wèn)“這個(gè)工具有什么使用場(chǎng)景？對(duì)于每個(gè)使用場(chǎng)景，用戶操作的最佳順序是什么？什么是最簡(jiǎn)單的API可以支持這個(gè)工作流程？”API中的原子選項(xiàng)應(yīng)該滿足高級(jí)工作流程中出現(xiàn)的明確需求?！耙?yàn)橛腥丝赡苄枰?，并不是添加理由?/span>

  
  

• 錯(cuò)誤消息，以及通常在與API交互過(guò)程中向用戶提供的任何反饋，都是API的一部分。交互性和反饋是用戶體驗(yàn)不可或缺的一部分。設(shè)計(jì)API的錯(cuò)誤消息請(qǐng)深思熟慮。

  
  

• 因?yàn)榇a是為了交流，所以命名很重要-無(wú)論是命名項(xiàng)目還是變量。名稱反映了你對(duì)問(wèn)題的看法。避免過(guò)于通用的名稱（例如“x，變量，參數(shù)”），避免過(guò)度長(zhǎng)和特定的命名，避免可能產(chǎn)生不必要糾紛的術(shù)語(yǔ)（例如“奴隸主/奴隸”），并確保在命名選擇中保持一致。命名一致性意味著內(nèi)部命名一致性（例如，不要命名“軸”的時(shí)候既用“dim”又用“axis”），以及與問(wèn)題域已建立約定的一致性。在確定名稱之前，請(qǐng)確保查找域?qū)＜遥ɑ蚱渌鸄PI）使用的現(xiàn)有名稱。

  
  

• 文檔是API用戶體驗(yàn)的核心。它不是附加組件?；〞r(shí)間去撰寫高質(zhì)量的文件，相較于花時(shí)間在其他的功能上，你會(huì)看到更高的回報(bào)。

  
  

• 用"展示"代替＂敘述＂：你的文檔不應(yīng)該談?wù)撥浖绾喂ぷ?，它?yīng)該展示如何使用它。展示從頭到尾工作流程的代碼示例；顯示API的每個(gè)常見(jiàn)用例和關(guān)鍵功能的代碼示例。

• 職業(yè)進(jìn)步并不是你管理的人數(shù)，而是你所產(chǎn)生的影響：你的工作是否為世界帶來(lái)改變。

  
  

• 軟件開(kāi)發(fā)是團(tuán)隊(duì)合作，人際關(guān)系和技術(shù)能力同樣重要。做個(gè)優(yōu)秀的隊(duì)友。當(dāng)你走在職業(yè)道路上時(shí)，記得與他人保持聯(lián)系。

  
  

• 技術(shù)永遠(yuǎn)不會(huì)中立。如果你的工作對(duì)世界有任何影響，那么這種影響就有道德方向。我們?cè)谲浖a(chǎn)品中看似無(wú)害的技術(shù)選擇調(diào)整了技術(shù)獲取的條件，技術(shù)的使用激勵(lì)，誰(shuí)將受益以及誰(shuí)將受到影響：技術(shù)選擇也是道德選擇。因此，始終謹(jǐn)慎而明確地表達(dá)你想通過(guò)選擇支持的價(jià)值觀。為道德而設(shè)計(jì)并將你的價(jià)值觀融入到你的創(chuàng)作中。永遠(yuǎn)不要想“我只是在建立這種功能，這本身就是中立的“：它不是，因?yàn)槟銟?gòu)建它的方式?jīng)Q定了它的使用方式。

  
  

• 建立世界需要的東西，而不僅僅是你希望擁有的東西。很多時(shí)候，技術(shù)人員過(guò)著遠(yuǎn)離常人的生活，專注于滿足自身特定需求的產(chǎn)品。尋求擴(kuò)大生活體驗(yàn)的機(jī)會(huì)，讓你更好地了解世界需求。

  
  

• 在做出有著長(zhǎng)期影響的任何選擇時(shí)，將你的價(jià)值觀置于短期的自身利益和情緒之上，例如貪婪或恐懼。了解你的價(jià)值觀是什么，并讓它們指導(dǎo)你。

  
  

• 當(dāng)我們發(fā)現(xiàn)自己陷入沖突時(shí)，暫停一下，承認(rèn)我們的共同價(jià)值觀和共同目標(biāo)是個(gè)好主意，并提醒自己，我們幾乎肯定是站在同一邊。

  
  

• 生產(chǎn)力歸結(jié)為高速?zèng)Q策和行動(dòng)偏見(jiàn)。這需要：1.）來(lái)自經(jīng)驗(yàn)的良好直覺(jué)，以便在給出部分信息的情況下做出大體正確的決定；2.）敏銳地意識(shí)到何時(shí)更謹(jǐn)慎地行事并等待更多信息，因?yàn)殄e(cuò)誤決策比延遲決策的成本更高。在不同環(huán)境中，最佳速度/質(zhì)量的決策權(quán)衡可以有很大差異。

  
  

• 更快地做出決定意味著你在職業(yè)生涯中做出更多決策，這將使你對(duì)可能選項(xiàng)的正確性有更強(qiáng)的直覺(jué)。經(jīng)驗(yàn)是提高生產(chǎn)力的關(guān)鍵，更高的生產(chǎn)力將為您提供更多的經(jīng)驗(yàn)。這是一個(gè)良性循環(huán)。

  
  

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

相關(guān)報(bào)道：

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

往期精彩：
 男人30歲，不該有暮氣
【原創(chuàng)首發(fā)】機(jī)器學(xué)習(xí)公式推導(dǎo)與代碼實(shí)現(xiàn)30講.pdf
【原創(chuàng)首發(fā)】深度學(xué)習(xí)語(yǔ)義分割理論與實(shí)戰(zhàn)指南.pdf
 談中小企業(yè)算法崗面試
 算法工程師研發(fā)技能表
 真正想做算法的，不要害怕內(nèi)卷
 算法工程師的日常，一定不能脫離產(chǎn)業(yè)實(shí)踐
 技術(shù)學(xué)習(xí)不能眼高手低
 技術(shù)人要學(xué)會(huì)自我營(yíng)銷
 做人不能過(guò)擬合
求個(gè)在看