本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)。

成為一名開發(fā)人員是很難，想要成為一名高效的開發(fā)人員，更是難上加難。你必須得忍受諸多冗長的會議(它們會消耗你本可以用來編寫代碼的時(shí)間)，忍受花費(fèi)大量時(shí)間做決定的管理模式，以及模糊不清的驗(yàn)收標(biāo)準(zhǔn)……這些都是在浪費(fèi)時(shí)間，然而我們幾乎沒有意識到其中最浪費(fèi)時(shí)間的居然是自身習(xí)慣。

這些習(xí)慣可以實(shí)現(xiàn)時(shí)間浪費(fèi)最小化，工作產(chǎn)出最大化。

[[357306]]

每天為自己設(shè)定一個(gè)具體明了的目標(biāo)

我經(jīng)常發(fā)現(xiàn)自己一到中午就變懶散。我本該一分鐘寫很多行代碼，但過了一會兒，卻發(fā)現(xiàn)自己在看摩托車評論。有一次，我必須在一天內(nèi)修復(fù)一個(gè)嚴(yán)重故障，因?yàn)樗绊懙搅舜罅康挠脩簟Ｄ且惶?，我比以往任何時(shí)候工作效率都要高，原因很簡單：我有了一個(gè)具體明了的目標(biāo)。

我現(xiàn)在知道，當(dāng)我應(yīng)該卻沒開始創(chuàng)建解決方案時(shí)，很可能是由于我不知道自己的目標(biāo)是什么。當(dāng)我有了一個(gè)可以用一兩行字寫下來的目標(biāo)時(shí)，我的效率就提高了。

這樣做之所以有用，原因之一是蔡格尼克效應(yīng)，該效應(yīng)認(rèn)為人類是“尋求解脫的動(dòng)物”。換句話說，我們討厭開始一件事，也討厭沒有完成這件事。當(dāng)你明確了標(biāo)準(zhǔn)，你就會確切知道下一步是什么。

例如，當(dāng)我準(zhǔn)備創(chuàng)建一個(gè)新特征時(shí)，我會寫下一行簡單的目標(biāo)：

• 更新持久性代碼，以便其使用AndroidX Room數(shù)據(jù)庫。
• 重構(gòu)特征X(或其中一部分)，以便其使用MVVM模式。
• 為用戶旅程X創(chuàng)建前兩個(gè)UI屏幕”

沒有時(shí)間節(jié)點(diǎn)，就沒有完成的動(dòng)力，也就沒有進(jìn)步。

先創(chuàng)建一個(gè)MVP，然后把需要做的事情具體化

以前，我總想盡可能地編寫出美觀漂亮、運(yùn)行流暢的代碼。我每天要花上幾個(gè)小時(shí)的時(shí)間在10行代碼塊上，僅僅因?yàn)樗鼪]有按照我喜歡的方式運(yùn)行。這種工作方式帶來的結(jié)果與我的初衷完全相反。這不僅讓我的工作效率變低了，而且還讓我的代碼中摻雜著許多神秘難解的符號，代碼沒有解耦，變得更難測試。

我意識到，我所要做的就是交付一些可正常運(yùn)行的產(chǎn)品——MVP(最簡化可實(shí)行產(chǎn)品)。當(dāng)然，你應(yīng)該交付可正常運(yùn)行的產(chǎn)品!但在工作中我可能忘了自己應(yīng)該做一些有助于任務(wù)完成的事情。不多做亦不少做，恰到好處即可。

尤其是作為一名初級開發(fā)人員，我在使用一些驚艷同事們的新奇組件和庫時(shí)，倍感壓力。這不僅會讓自己想太多，而且會影響你當(dāng)前的任務(wù)，如果在這上面花的時(shí)間太多，甚至占用了自我提升的沖刺時(shí)間，可能還會影響到你未來的任務(wù)。

那么怎樣才能知道什么時(shí)候應(yīng)該停止工作呢?當(dāng)一切都進(jìn)展順利的時(shí)候。

顯然，這里需要滿足一些標(biāo)準(zhǔn)：

• 代碼框架是否正確?
• 是否將故障降至最小?
• 別人能否理解發(fā)生了什么?
• 是否覆蓋了所有用例?

盡可能在獨(dú)立分支上工作

[[357307]]

圖源：unsplash

開發(fā)人員承擔(dān)的任務(wù)越復(fù)雜，就越有可能引發(fā)致命性故障。在你把負(fù)責(zé)的工作合并到主分支進(jìn)行全面測試時(shí)，這些致命性故障才可能顯現(xiàn)出來。

當(dāng)?shù)玫降谝粋€(gè)重要開發(fā)任務(wù)時(shí)，我很是興奮。任務(wù)要求重構(gòu)一個(gè)特征以使用MVVM，并用Kotlin語言編寫。然而，我自身經(jīng)驗(yàn)不足，不知道怎樣正確測試自己編寫的代碼，盡管代碼還有很多錯(cuò)誤，但是我還是把代碼發(fā)送并合并到主碼中。

幾天后，團(tuán)隊(duì)測試人員非常生氣，所以我后面連續(xù)兩周都要修復(fù)大量的故障。我拖了團(tuán)隊(duì)的后腿，因?yàn)槲姨珣辛?，沒能正確測試自己的代碼，而且因?yàn)槲宜械母亩急缓喜⒘?，下一個(gè)版本的發(fā)布很可能要推遲。

然后我意識到，如果我使用獨(dú)立特征分支，然后把它交給測試人員，就能為自己和團(tuán)隊(duì)節(jié)省大量的精力和時(shí)間。在全面測試新代碼之前，盡可能將其保存在獨(dú)立分支上。如此一來，你就能更快地修復(fù)故障，并從產(chǎn)品構(gòu)建中分離出致命性故障。

永遠(yuǎn)不要接手含糊不清的任務(wù)

人們無論何時(shí)開始新的任務(wù)，都會受到惰性的影響。我們都有很多類似的經(jīng)歷。當(dāng)準(zhǔn)備起床時(shí)，我們的身體團(tuán)作一團(tuán)，沒有任何反應(yīng)。當(dāng)想要學(xué)習(xí)新東西時(shí)，我們不參加課程。當(dāng)想要給自己規(guī)定飲食時(shí)，又糾結(jié)于應(yīng)該吃什么、多久吃一次等細(xì)節(jié)。

軟件開發(fā)中，開始創(chuàng)建新特征時(shí)的惰性或阻力通常以多種方式呈現(xiàn)出來：必須瀏覽完冗長的SDK文檔，理解了業(yè)務(wù)需求的確切內(nèi)容，甚至試圖找出所需的依賴項(xiàng)。

我不知道你是否也這樣想，但作為一名開發(fā)人員，我想做的就是開發(fā)。我不想爭當(dāng)產(chǎn)品負(fù)責(zé)人，不想檢查UI副本或元素，不想一遍遍地寫驗(yàn)收標(biāo)準(zhǔn)，不想一直不停地詢問后端團(tuán)隊(duì)關(guān)于API的問題……我只想做開發(fā)。

所以我只會接手滿足下面這些條件的任務(wù)：

• 所有的依賴項(xiàng)是否安排并交接完成?
• UI是否確定下來并通過核準(zhǔn)?
• 我是否可以很容易地聯(lián)系到負(fù)責(zé)該特征的人?
• 驗(yàn)收標(biāo)準(zhǔn)是否清晰明了?如果喝醉時(shí)閱讀這些標(biāo)準(zhǔn)，我能理解它們嗎?
• 如果需要，是否能將工具或SDK與許可證一同使用?

希望這些能讓你的效率大大提升!