編者按:今天,Keras作者、Google深度學(xué)習(xí)Fran?ois Chollet又發(fā)表了一篇新文章。他把里面的內(nèi)容稱為“自我提醒清單”,這是他多年來目睹、親身經(jīng)歷的軟件工程師經(jīng)驗(yàn)總結(jié)。雖然在實(shí)際操作中,不少人會(huì)被公司管理層的各種要求逼上歧途,但凡事重在不忘初心。值此秋招之際,論智也把這篇佳作分享給大家。
關(guān)于開發(fā)過程
代碼不僅僅意味著運(yùn)行,它也是團(tuán)隊(duì)人員之間的一種溝通方式,是向他人描述問題解決方案的一種方式。代碼的可閱讀性不應(yīng)是軟件工程師的優(yōu)點(diǎn),它該是所有人的基礎(chǔ)能力。這包括清楚地分解代碼,選擇不言自明的變量名,以及插入注釋來描述隱含的任何內(nèi)容。
pull request的時(shí)候,不要糾結(jié)代碼能怎么幫你營(yíng)銷自己,多想想它可以為讀者和社區(qū)做什么。你必須不惜一切避免“招搖的貢獻(xiàn)”,如果這么做對(duì)你的產(chǎn)品毫無(wú)用處,就不要去畫蛇添足。
個(gè)人品位也適用于代碼。它是一種約束,如果你追求代碼的簡(jiǎn)潔優(yōu)雅,你就會(huì)規(guī)范自己的編碼過程。因此,要始終對(duì)簡(jiǎn)潔性保持偏愛。
學(xué)會(huì)拒絕——?jiǎng)e人提出需求不等于你就應(yīng)該照他們的想法去做。他們每提出一個(gè)新功能,它的成本就會(huì)超出最初的實(shí)施范圍:維護(hù)成本,文檔成本和用戶的認(rèn)知成本。所以要一直問自己:我們真的應(yīng)該這樣做嗎?通常情況下,這個(gè)問題的回答是否定的。
當(dāng)你答應(yīng)按照用戶請(qǐng)求開發(fā)新功能塊(use case)時(shí),記住,只按字面理解開發(fā)新功能是不夠的。用戶只關(guān)心自己用的特定功能塊,但你必須站在全局性和原則性的視角下去看待這項(xiàng)更新,一般情況下,這意味著擴(kuò)展現(xiàn)有功能。
向持續(xù)集成和所有代碼的單元測(cè)試全覆蓋“投資”。時(shí)刻確保自己處于優(yōu)質(zhì)編程環(huán)境中,如果這點(diǎn)都做不到,先關(guān)注怎么準(zhǔn)備正確設(shè)備。
如果沒有做計(jì)劃,沒關(guān)系。你可以多多嘗試,看看結(jié)果如何。要盡早發(fā)現(xiàn)錯(cuò)誤選擇,確保自己最終能發(fā)現(xiàn)一種可行的方法。
好的軟件可以化難為易。問題看起來可以很復(fù)雜,但這并不意味著它的解決方案一定是復(fù)雜的、難以實(shí)現(xiàn)的。有時(shí)工程師們會(huì)忽視簡(jiǎn)單易用但不怎么明顯的解決方案,轉(zhuǎn)而投向另外一些復(fù)雜的、有副作用的方法(我們用機(jī)器學(xué)習(xí)吧!寫個(gè)APP吧!加上區(qū)塊鏈吧?。?。在編寫任何代碼之前,請(qǐng)確保你選擇的解決方案不能更簡(jiǎn)單,牢記編程首要原則:Keep It Simple。
避免隱含規(guī)則。如果你自己開發(fā)了一些隱含規(guī)則,請(qǐng)確保它們是共享的,可以被其他開發(fā)者明確理解,或是可以自動(dòng)化。當(dāng)你想出了一些頻繁出現(xiàn)的、類似算法的東西,你應(yīng)該設(shè)法將其形式化為一個(gè)文檔化的流程,以便其他團(tuán)隊(duì)成員從中受益。此外,你也應(yīng)該設(shè)法尋找一些工具,使這個(gè)方法的任何部分都能被自動(dòng)化(如debug)。
這么做會(huì)有什么影響?這才是你在程序設(shè)計(jì)過程中應(yīng)該考慮的事,而不是收入怎么樣,會(huì)帶來什么個(gè)人成長(zhǎng)。除了正在監(jiān)控的指標(biāo)之外,你的軟件對(duì)全球用戶的總體影響是什么?是否存在預(yù)期之外的不良副作用?在保留實(shí)用性的同時(shí),你能做什么改善?
關(guān)于API設(shè)計(jì)
你設(shè)計(jì)的API會(huì)有用戶,所以時(shí)刻關(guān)注用戶體驗(yàn)。每當(dāng)你做出一個(gè)決定,你都應(yīng)該關(guān)注用戶的感受,關(guān)注他們中的每一個(gè)人,無(wú)論是他們是初學(xué)者還是資深開發(fā)人員。
降低用戶在使用你的API時(shí)的認(rèn)知負(fù)荷。自動(dòng)化一切可自動(dòng)化的內(nèi)容,最大限度地減少用戶所需的操作和選擇量,不要暴露不重要的選項(xiàng),設(shè)計(jì)簡(jiǎn)單一致的工作流程,以反映簡(jiǎn)單一致的心智模型。
簡(jiǎn)單的事應(yīng)該是簡(jiǎn)單的,復(fù)雜的事應(yīng)該是有可能性的。不要為了利基功能塊把簡(jiǎn)單問題復(fù)雜化,即便是最低限度。
如果工作流的認(rèn)知負(fù)荷足夠低,那么用戶應(yīng)該能在一次或兩次親身事件后就掌握整個(gè)流程(無(wú)需查閱教程或文檔)。
設(shè)計(jì)一個(gè)符合領(lǐng)域?qū)<液蛷臉I(yè)者心智模型的API。有這個(gè)領(lǐng)域經(jīng)驗(yàn)但沒有API經(jīng)驗(yàn)的人應(yīng)該能通過閱讀最少的文檔直觀地理解你的API,比如查看代碼示例、查找可用對(duì)象和它們的簽名。
在沒有任何關(guān)于底層實(shí)現(xiàn)的上下文的情況下,參數(shù)的含義應(yīng)該是直觀的、易于理解的。用戶指定的參數(shù)應(yīng)該和他們的需求有關(guān),而不是和代碼中的實(shí)現(xiàn)細(xì)節(jié)有關(guān)。API就是解決問題的工具,它不需要涉及軟件如何在后臺(tái)運(yùn)行。
最強(qiáng)大的心智模型是模塊化和層次化的:既注重高級(jí)別的簡(jiǎn)潔性,又兼顧精確性,包含需要了解詳細(xì)信息。同樣的,一個(gè)好的API也應(yīng)該是模塊化和層次化的:易于連接,又具有相當(dāng)?shù)谋憩F(xiàn)力。它內(nèi)部應(yīng)該保持平衡,在較少對(duì)象上具有復(fù)雜簽名,并且在簡(jiǎn)單簽名上具有更多對(duì)象。
你的API會(huì)不可避免地反映你的實(shí)現(xiàn)選擇,特別是數(shù)據(jù)結(jié)構(gòu)。為了實(shí)現(xiàn)直觀的API,你選擇的數(shù)據(jù)結(jié)構(gòu)必須適合對(duì)應(yīng)的領(lǐng)域——這也是符合專家心智模型的一個(gè)方面。
設(shè)計(jì)一個(gè)端到端的工作流程,而不是一系列atomic features。大多數(shù)開發(fā)人員在設(shè)計(jì)API時(shí),遵循的思路是“應(yīng)該提供哪些功能?讓我們?yōu)樗麄兣渲眠x項(xiàng)”。這并不合適,相反地,你應(yīng)該問問自己“這個(gè)工具有哪些功能塊?”“對(duì)于每個(gè)功能塊,用戶操作的最佳順序是什么?”“為了支持整個(gè)工作流程,最方便的API是哪個(gè)?”API中的Atomic options應(yīng)該能滿足高級(jí)工作流程中出現(xiàn)的明確需求——所以,切記不要出現(xiàn)“人們也許需要它”的東西。
在用戶使用API的過程中,錯(cuò)誤信息是對(duì)他們操作的一種重要反饋。交互性和反饋是用戶體驗(yàn)不可或缺的一部分,因此,設(shè)計(jì)它們時(shí)務(wù)必深思熟慮。
代碼即通信,命名很重要——無(wú)論是項(xiàng)目還是變量,名稱反映了你對(duì)問題的看法。在設(shè)計(jì)過程中,你不應(yīng)使用過于通用的名稱(如x, variable, parameter),也不要用過長(zhǎng)、有特指含義的術(shù)語(yǔ),或是會(huì)產(chǎn)生不必要誤解的詞(如master/slave)。遵循命名一致性,這意味著內(nèi)部命名的一致性(如dim/axis)以及和問題內(nèi)容保持一致。在確定名稱前,參考其他API的命名方式是一種好辦法。
文檔是API用戶體驗(yàn)的核心,它不是附加組件。在文檔寫作上花費(fèi)一點(diǎn)精力,你也許會(huì)收獲意料之外的驚喜。
圖像是生動(dòng)的,言語(yǔ)是蒼白的:你的文檔不應(yīng)該只是介紹軟件如何工作,它應(yīng)該顯示如何使用它。比如顯示端到端工作流的代碼示例,顯示API的每個(gè)常見用例和關(guān)鍵功能的代碼示例。
關(guān)于職業(yè)發(fā)展
職業(yè)發(fā)展并不是指你管理的人數(shù),而是指你的工作所產(chǎn)生的影響,它能否對(duì)世界造成些許改變。
軟件開發(fā)需要團(tuán)隊(duì)合作,其中人際關(guān)系與技術(shù)能力同樣重要。當(dāng)你在職業(yè)道路上前行時(shí),請(qǐng)保持團(tuán)隊(duì)間聯(lián)系,做好團(tuán)隊(duì)中的一員。
技術(shù)永遠(yuǎn)不會(huì)是中立的。如果你的工作對(duì)世界產(chǎn)生了影響,那么這種影響就會(huì)存在道德取向。在軟件產(chǎn)品中看似無(wú)害的技術(shù)選擇會(huì)導(dǎo)致技術(shù)獲取條件的調(diào)整,它決定著誰(shuí)將受益、誰(shuí)將受害:技術(shù)選擇也是道德選擇。因此,在道德設(shè)計(jì)上請(qǐng)始終謹(jǐn)慎而明確地表達(dá)你的價(jià)值觀,并把你的價(jià)值觀融入創(chuàng)作中。永遠(yuǎn)不要想“我只是搞技術(shù),它是中立的”,因?yàn)槟銟?gòu)建它的方式?jīng)Q定了它將被如何使用。
自我導(dǎo)向——為你工作和環(huán)境提供指引——它是生活滿意度的關(guān)鍵。幫助身邊的人建立起屬于他們的自我導(dǎo)向,并確保你的職業(yè)選擇能夠讓你成為更好的自己。
構(gòu)建這個(gè)世界需要的東西,而不僅僅是你個(gè)人的小希望。很多時(shí)候,技術(shù)人員過著單純的生活,只專注于滿足產(chǎn)品的特定需求。但你應(yīng)該嘗試去尋求擴(kuò)大生活體驗(yàn)的機(jī)會(huì),讓自己更好地了解世界的需求。
在面對(duì)長(zhǎng)期問題時(shí),你在做任何選擇之前都應(yīng)該進(jìn)行長(zhǎng)遠(yuǎn)打算,并把價(jià)值觀置于短期自身利益和情緒之上,例如貪婪或恐懼。明確你的價(jià)值觀,并讓它指導(dǎo)你。
當(dāng)發(fā)現(xiàn)自己和他人產(chǎn)生矛盾時(shí),停一停,反思一下雙方是否有著相同的價(jià)值觀和共同目標(biāo),請(qǐng)?zhí)嵝炎约?,大家是戮力同心的?/p>
生產(chǎn)力由決策力和工作重心決定。這需要 a)良好的直覺,它來自經(jīng)驗(yàn),以便你可以在知之甚少的情況下做出盡可能靠譜的決定; b)能敏銳地意識(shí)到什么時(shí)候該謹(jǐn)慎行事,保持觀望,因?yàn)橐粋€(gè)錯(cuò)誤決策的成本可能會(huì)比延期的成本更高。在不同環(huán)境中,時(shí)間至上和質(zhì)量至上的決策權(quán)衡可能會(huì)帶來很大的差異。
更快地決策意味著你在職業(yè)生涯中可以做出更多決策,這能鍛煉你的“直覺”。經(jīng)驗(yàn)是提高生產(chǎn)力的關(guān)鍵,而更高的生產(chǎn)力可以為你提供更多經(jīng)驗(yàn),這是一個(gè)良性循環(huán)。
如果你感覺自己不具備“直覺”,那么請(qǐng)把經(jīng)驗(yàn)抽象成理論。你可以在整個(gè)職業(yè)生涯中建立一系列可靠且真實(shí)的原則:原則是形式化的直覺,它所適應(yīng)的情景比原始的模式識(shí)別(需要大量直接的、類似的經(jīng)驗(yàn))更廣泛。
-
Google
+關(guān)注
關(guān)注
5文章
1748瀏覽量
57182 -
API
+關(guān)注
關(guān)注
2文章
1461瀏覽量
61489 -
深度學(xué)習(xí)
+關(guān)注
關(guān)注
73文章
5422瀏覽量
120590
原文標(biāo)題:Fran?ois Chollet:關(guān)于軟件工程的幾個(gè)注意事項(xiàng)
文章出處:【微信號(hào):jqr_AI,微信公眾號(hào):論智】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論