本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。

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

這些習慣可以實現時間浪費最小化，工作產出最大化。

[[357306]]

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

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

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

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

例如，當我準備創建一個新特征時，我會寫下一行簡單的目標：

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

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

先創建一個MVP，然后把需要做的事情具體化

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

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

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

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

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

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

盡可能在獨立分支上工作

[[357307]]

圖源：unsplash

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

當得到第一個重要開發任務時，我很是興奮。任務要求重構一個特征以使用MVVM，并用Kotlin語言編寫。然而，我自身經驗不足，不知道怎樣正確測試自己編寫的代碼，盡管代碼還有很多錯誤，但是我還是把代碼發送并合并到主碼中。

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

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

永遠不要接手含糊不清的任務

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

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

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

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

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

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