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

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

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

[[357306]]

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

我經(jīng)常發(fā)現(xiàn)自己一到中午就變懶散。我本該一分鐘寫很多行代碼，但過了一會兒，卻發(fā)現(xiàn)自己在看摩托車評論。有一次，我必須在一天內(nèi)修復(fù)一個嚴重故障，因為它影響到了大量的用戶。那一天，我比以往任何時候工作效率都要高，原因很簡單：我有了一個具體明了的目標。

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

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

例如，當(dāng)我準備創(chuàng)建一個新特征時，我會寫下一行簡單的目標：

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

沒有時間節(jié)點，就沒有完成的動力，也就沒有進步。

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

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

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

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

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

顯然，這里需要滿足一些標準：

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

盡可能在獨立分支上工作

[[357307]]

圖源：unsplash

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

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

幾天后，團隊測試人員非常生氣，所以我后面連續(xù)兩周都要修復(fù)大量的故障。我拖了團隊的后腿，因為我太懶了，沒能正確測試自己的代碼，而且因為我所有的更改都被合并了，下一個版本的發(fā)布很可能要推遲。

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

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

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

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

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

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

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

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