研發效率破局之道閱讀總結(4)個人效率

Author: Once Day Date: 2025年4月30日

一位熱衷于Linux學習和開發的菜鳥，試圖譜寫一場冒險之旅，也許終點只是一場白日夢…

漫漫長路，有人對你微笑過嘛…

全系列文章可參考專欄: 程序的藝術_Once-Day的博客-CSDN博客

注: 本文內容摘抄于原文，文中"我"代表原作者【葛俊】大佬視角。

參考文章:

• 研發效率破局之道

---

1. 提高個人效能

（1）第一條原則：抽象和分而治之。

把一個系統拆分為幾個有限的子系統，每個子系統涵蓋某一方面的內容，并 將其復雜性隱藏起來，只對外暴露關鍵信息。

這個拆分處理的過程，就是我們常說的分而治之；而用子系統來隱藏一個領域的內部細節， 就是抽象。抽象和分而治之，是我們理解世界的基礎。

拿到一個任務之后，我們要做的首先就是進行模塊的定義，也就是抽象，然后對其分而治之。

提高抽象和分而治之效率的一個技巧是，在設計代碼架構時注意尋找合適的設計模式。

設計模式指的是，設計過程中可以反復使用的、可以解決特定問題的設計方法，最經典的莫過于《設計模式：可復用面向對象軟件的基礎》中列舉的 23 個設計模式，以及針對企業軟件架構的《企業應用架構模式》。同時，我們還要注意公司內部具體的常用模式。這些模式都是經實踐檢驗有效的，且傳播較廣容易理解，都可以作為你進行模塊拆分的參照。

具體實現功能的過程中，也會處處體現分而治之的思想。最主要的一個表現是，每個開發者都會把自己的代碼盡量做到原子性。代碼的原子性指的是，一個提交包含一個不可分割的特性、修復或者優化。

在實際工作中，功能往往比較大。如果只用一個提交完成一個功能，那這個提交往往會比較大，所以我們需要把這個功能再拆分為子功能。

（2）第二條原則：快速迭代。

第一，不要追求完美，不要過度計劃，而是要盡快實現功能，通過不斷迭代來完善。優秀的架構往往不是設計出來的，而是在實現過程中逐步發展、完善起來的。

有些開發者過于追求技術，投入了大量時間去設計精美、復雜的系統。這樣做沒有問題，但 一定要有一個度，切忌殺雞用牛刀。因為復雜的系統雖然精美，但往往不容易理解，維護成 本也比較高，修改起來更是不容易。

第二，在設計的實現中，盡量讓自己的代碼能夠盡快運行起來，從而盡快地驗證結果。我們常常會先實現一個可以運行起來的腳手架，然后再持續地往里面添加內容。

第三，為了能夠快速進行驗證，一個重要實踐是設置好本地的代碼檢驗，包括靜態掃描、相關單元測試的方便運行，以及 IDE 能夠進行的實時檢查等。

第四，代碼寫好之后，盡快提交到主代碼倉并保證不會阻塞其他開發人員。

（3）第三條原則：DRY。

DRY，也就是不要重復你自己，是很多開發模式的基礎，也是我們非常熟悉的一條開發原則了。比如，我們把一段經常使用的代碼封裝到一個函數里，在使用它的地方直接調用這個函數，就是一個最基本的 DRY。

代碼邏輯的重復，不僅僅是工作量的浪費，還會大大降低代碼的質量和可維護性。所以，我 們在開發時，需要留意重復的代碼邏輯，并進行適當的處理。

在編程工作中，除了代碼的重復外，比較常見的還有流程的重復。比如測試中，我們常常需 要重復地產生一些測試數據，運行完測試之后再把這些數據刪除。

2. 聚焦工作

在任務多、干擾多的現狀下，如何最高效地利用時間，去做最重要的事兒，同時有更多的時間來放松和享受生活。

在我看來，這個問題的答案就是深度工作，聚焦最有價值的事兒。 深度工作這個概念，是由 卡爾 · 紐波特（Cal Newport）提出的，指的是在無干擾的狀態下，才能專注地進行的專業 活動。這樣的活動能夠使個人的認知能力發揮到極限，從而讓我們創造出最大價值，成為一個不可替代的人。

（1）以終為始，尋找并聚焦最重要的任務

GTD 的創始人大衛 · 艾倫（David Allen）提出，日常任務可以分為 3 種：

• 預先計劃的任務（Pre-defined Work），比如迭代之初就計劃好了的功能開發任務；
• 臨時產生的任務（Work As It Appears），比如 Bug、郵件、臨時會議等；
• 自己定義的任務（Defining Work），即根據當前狀況，自己決定需要做的任務。

在我看來，我們要把更多的時間和精力放到自己定義的任務上。你可能會覺得，前兩種任務已經夠多了，也非常重要。但其實，我們容易忽略的第 3 種任務，可以幫我們減少前兩種任務中不必要的浪費。

因為，預先計劃好的任務的優先級常常會隨著情況的改變而改變，而臨時產生的任務很可能當時覺得很緊急，但實際上是可以推遲或者甚至不做的。

（2）聚焦目標，以終為始

聚焦目標，以終為始，其實就是在自己定義任務。因為時間有限，為目標服務的任務才最重要。作為高效開發者，常見的目標包括業務成功、幫助團隊，以及個人成長這 3 個。如果能找到三者重合的任務就最好不過了。

日常工作中更常見的情況是，三者不能兼得。這時，我們首先應該關注業務成功，因為它是我們工作的最基本目標，是基礎。在此之上，我推薦先考慮幫助團隊成長。因為幫助團隊的同時，往往會給自己帶來一些直接或間接的成長機會。

（3）無情的篩選，少即是多

生命有限，而工作無限，所以我們必須要無情地排優先級。

很多人都有一個傾向，就是貪多，認為越多越好，我曾經也這樣。在自己的書單里添加了幾 百本書，書簽頁中添加了幾百篇要讀的技術文章，Todo List 里添加的任務也越來越多，還 計劃學習這個語言、那個框架。但實際做起來，卻因為時間有限，不但只能淺嘗而止，還讓 自己很疲倦。痛定思痛，我下決心去做減法。

在我看來，“數字 3 原則”很有效，也就是強制把要做的事、要達到的目標，都限制在 3 個以內。

3. Git使用技巧

毫無疑問，Git 是當前最流行的代碼倉管理系統，可以說是開發者的必備技能。它非常強 大，使用得當的話可以大幅助力個人效能的提升。一個最直接的應用就是，可以幫助我們提 升代碼提交的原子性。如果一個團隊的成員都能熟練使用 Git 的話，可以大大提高團隊代碼 的模塊化、可讀性、可維護性，從而提高團隊的研發效能。

代碼提交的原子性指的是，一個提交包含一個不可分割的特性、 修復或者優化。如果用一個提交完成一個功能，這個提交還是會比較大的話，我們需要把這 個功能再拆分為子功能。

為什么要強調代碼提交的原子性呢？這是因為它有以下 3 大好處：

• 可以讓代碼結構更清晰、更容易理解；
• 出了問題之后方便定位，并可以針對性地對問題提交進行“回滾”；
• 在功能開關的協助下，可以讓開發者盡快把代碼推送到 origin/master 上進行合并。這正是持續集成的基礎。

（1）把工作區里代碼改動的一部分轉變為提交。

如果是把整個文件添加到提交中，操作很簡單：先用 git add <文件名> 把需要的文件添加到 Git 暫存區，然后使用 git commit 命令提交即可。這個操作比較常見，我們應該都比 較熟悉。

但在工作中，一個文件里的改動常常會包含多個提交的內容。比如，開發一個功能時，我們常常會順手修復一些格式規范方面的東西；再比如，一個功能比較大的時候，改動常常會涉及幾個提交內容。那么，在這些情況下，為了實現代碼提交的原子性，我們就需要只把文件里的一部分改動添加到提交中，剩下的部分暫時不產生提交。針對這個需求，Git 提供了 git add -p 命令。

（2）對當前提交進行拆分。

可以先“取消”已有的提交，也就是把提交的代碼重新放回到工作區中，然后再使 用 git add -p 的方法重新產生提交。這里的取消是帶引號的，因為在 Git 里所有的提交都是永久存在的，所謂取消，只不過是把當前分支指到了需要取消的提交的前面而已。

（3）修改當前提交

如果只需要修改 Commit Message 的話，直接使用 git commit --amend 命令，Git 就會 打開你的默認編輯器讓你修改，修改完成之后保存退出即可。

如果要修改的是文件內容，可以使用 git add、git rm 等命令把改動添加到暫存區，再運行 git commit --amend，最后輸入 Commit Message 保存退出即可。

（4）交換多個提交的先后順序

有些時候，我們需要把多個提交交換順序。比如，master 分支上有兩個提交 A 和 B，B 在 A 之上，兩個提交都還沒有推送到 origin/master 上。

這時，我先完成了提交 B，想把它先單獨推送到 origin/master 上去，就需要交換 A 和 B 的位置，使得 A 在 B 之上。我可以使用 git rebase --interactive（選項–interactive 可以 簡寫為 -i）來實現這個功能。

（5）修改非頭部提交

在工作中，為了方便實現原子性，我們常常需要修改歷史提交，也就是修改非頭部提交。對歷史提交操作，最方便的方式依然是使用強大的 git rebase -i。

4. 命令行

GUI 圖形界面的出現是計算機技術的變革，極大方便了用戶。但在這么多年后的今天，命 令行工具為什么仍然有如此強大的生命力呢？

對軟件工程師來說，想要高效開發就必須掌握命令行，主要原因包括：

• 雖然鼠標的移動和點擊比較直觀，但要完成重復性的工作，使用鍵盤會快捷得多。
• 這一點從超市的結算人員就可以看出來，使用鍵盤系統的收銀員總是噼里啪啦地很快就可以完成結算，而使用鼠標點擊的話明顯慢很多。
• 作為開發人員，可以比較容易地使用命令行的腳本，對自己的工作進行自動化，以及和其他系統工具聯動。但使用 GUI 的話，就會困難得多。
• 命令行通常可以暴露更完整的功能，讓使用者對整個系統有更透徹的理解。Git 就是一個 典型的例子，再好的 GUI Git 系統都只能封裝一部分 Git 命令行功能，要想真正了解 Git，我們必須要使用命令行。
• 有一些情況是必須使用命令行的，比如 SSH 到遠程服務器上工作的時候。

5. 高效溝通原則

溝通是高效工作的重要軟技能：

第一個原則是，溝通時要有同理心。我們溝通的目的，是在對方身上起作用，要從別人的角 度考慮怎樣去溝通。所以，我們需要了解以下三個方面的信息：

• 一是，對方的知識背景，從而使用他能理解的語言去溝通；
• 二是，對方想要知道什么，才能不繞彎路高效答復；
• 三是，對方的出發點，根據他的出發點將對話引向雙贏的方向。

第二個原則是，外在表現很關鍵。中國的文化比較內斂，我們從小受到的教育也強調內在美，忽視外表，這就會引導我們形成忽視外在表現的習慣。因此，我在美國工作時吃了不少虧，做出的東西，卻被會表現的人搶走了大部分功勞。這才逐漸認識到，這種“內斂”實際 上是不對的，很多情況下外在表現更重要。

外在表現很關鍵這個原則，在開發工作上表現為我們不但要重視實際的工作，也要重視別人對我們工作成果的感知。很多開發者從內心抵觸 PPT，我覺得這就是高效工作的一個重要阻礙。我們確實需要花一些精力，去考慮如何把我們做出的東西更好地呈現出來。

第三個原則是，冰山原則，是美國軟件界大佬 Joel Spolsky(周思博)提出來的。

這個原則對軟件技術人員和非技術人員間的交流非常有用，指的是一個軟件應用系統比較復雜，就像一座冰山。但是，它表現在外面的只是一小部分，就像冰山露出水面的部分一樣。 如果你溝通的對象對軟件不熟悉的話，他就會認為，冰山上的可見部分就是全部工作，或者說是絕大部分的工作。

這樣的結果就是，軟件開發人員在做項目進展演示的時候，如果演示得很完整、漂亮，對方就會認為你的工作做得差不多了，即使你已經提前強調過這只是在界面上做的一個 Demo，也不會有效果。因為對方在潛意識里，就認為你的工作已經做得差不多了。

所以，我們在做演示的時候，要盡量把界面的完成程度和項目的進展程度對應起來。比如， 不要把界面做得太漂亮，顯示的文字可以用“XXX”，而不要用真實數據等。