作者 | 梅雪松

不知道你有沒有注意到，走進各個企業，總能看到那么幾句振奮人心的標語，其中“一次把事情做對”絕對是個高頻詞匯。以前每次看到，我都會想：這家企業也太教條了，都什么時代了，對失敗這么零容忍，還怎么創新呢？這個時代的主旋律不是從錯誤中學習，快速響應、快速迭代嗎？

然而最近一年的嵌入式領域經歷，讓我重新反思并意識到，“一次把事情做對”不僅是對工作效率的追求，更是對質量控制的嚴格要求。在嵌入式產品開發領域，這一理念的重要性尤為突出。

與Web系統相比，嵌入式產品有其獨特性。它是軟硬件的緊密結合體，不易升級，一旦發布，出問題的解決成本異常高昂，后果更為嚴重。所以“一次把事情做對”就是一個合理且必要的目標了。

但是怎么做到一次把事情做對呢？我們從四個原則來聊聊。

不做就不錯

在生活中，我們常說“不做就不錯”。在工作中，我也要把這個原則送給你，它仍然是真理。說白了就是：沒代碼，無bug。

我不是說讓大家不干活，而是在沒搞清楚需求之前，千萬別急著動手。你想想，畫畫草圖、寫寫文檔總比直接寫代碼來得輕松吧？而且成本也低多了。如果錯了大不了重畫重寫，可是寫成了代碼，那就叫 bug。

你要學會拒絕需求。需求來了，你得想想這需求有價值嗎？合理嗎？如果對方說不清楚價值，給不出理由，那就應該拒絕。告訴他不要浪費你的時間和公司的金錢。

你得要求明確的需求。當業務方提出需求時，BA（需求分析師）就要分析清楚這個需求的細節，一句話的需求太模糊，沒法干，開發者也要拒絕。這是你的權利。一旦你干了，出了 bug 那就是你的錯。

但你可能要問了，有些需求在初期就是模糊的，只能在做的過程中慢慢摸索，那怎么辦呢？

記住，不做就不錯，不寫代碼就沒 bug！你捫心自問，需求是模糊的，可代碼能模糊嗎？計算機只能分清0和1，根本就不會模糊處理。所以即使需求是模糊的，我們卻無法寫出模糊的代碼。如果在這種情況下寫出了代碼，必然是把模糊的東西變成了確定的東西，那大概率就寫了個bug。

正確的做法是，需求必須明確，不能模糊。如果在產品初期，摸索階段，那么BA應該提出假設，進行驗證。提出假設后，需求就是明確的。我們假設是這種情況，代碼就這么開發，先驗證，不斷迭代就能逐漸找到更好的答案。

這種通過假設來明確需求的方法叫試錯，你拿著模糊需求寫成不模糊的代碼，那叫 bug，這兩者的區別自己體會一下。

少做就少錯

現在我們把能拒絕的工作拒絕了，把模糊的需求明確了，剩下的就是不得不做的了。接下來的第二個原則是，少做就少錯。

怎么做到呢？千萬別急著動手寫代碼，否則你很可能要走不少彎路才能做對。這里提供一個三步法，讓你少走彎路、少寫代碼，少出錯。

• 第一步，腦中做一遍。先在腦海中預演整個實現過程，這類似于一種虛擬的模擬運行。要想清楚每一步的輸入輸出是什么，處理過程是什么。這一步很重要，它能確保你真正理解了需求，并提前發現潛在的問題和難點。
• 第二步，紙上畫一遍。把腦中預演的過程在紙上畫個草圖。這個過程不僅有助于整理思路，還有助于和別人溝通討論。記住，一定要畫出來。有時候你以為你想清楚了，畫出來才發現沒想清楚。
• 第三步，找人問一遍。經過前兩步，你對需求理解透了，實現方案也想清楚了。這時候要找人問一遍。這個人最好是個有經驗的人。他能對你的方案提出建議，也能發現你沒注意到的、可能對原來的功能有影響的地方。即使對方沒有經驗，也要找人問一遍。因為在講的過程中，自己就能發現一些問題。

經過這樣三步的準備和驗證之后，就可以信心滿滿地開始編寫代碼了。這時在面對復雜問題時會從容不迫，出錯的概率也大大降低。

讓機器多干活

前面鋪墊那么多，你可能都覺得那不是好好工作，只有寫代碼才是真正工作。其實你寫的代碼是非常寶貴的東西。產品的價值都是靠你一行行代碼實現的。前面的鋪墊就是為了讓你能真正寫好代碼。

現在你終于開心地寫著代碼了。這時要思考的是自己怎么少干活，怎么讓機器多干活。畢竟，不做就不錯，少做就少錯。

這里我們暫且不提讓AI來幫你寫代碼。想想在開發過程中，哪些工作是可以交給機器來做的呢？

開發的工作可以分為三大塊：看代碼、寫代碼、調試驗證。

驗證對你來說既無聊又耗時間。你打著斷點，看著變量是不是你想要的值，邏輯跳轉對不對。這樣的工作不停地重復著，有時候一抬頭發現周圍人都走光了，一天很快就過去而你還沒定位到問題。

驗證這部分是最容易交給機器來做的。完全可以寫個驗證代碼（測試代碼）來驗證程序的輸出對不對，是不是想要的結果。這是個一勞永逸的方法。驗證代碼只要寫一遍，它就在那里，孜孜不倦一遍遍運行著。你完全可以放心交給它幫你完成驗證的工作。再進一步，甚至可以先寫驗證代碼，再寫業務代碼，這就是極限編程中的測試驅動開發（TDD）。

機器還可以幫你干其它活，那些重復的活都可以讓它干。所以這第三個原則“讓機器多干活”還有另一個名字：自動化一切能夠自動化的工作。

比如你的軟件的構建，部署，一切能夠自動化的工作，都應該交給機器來做。因為人都是會犯錯誤的。

早糾錯、少浪費

前面三個原則講的都是盡量地少干活，但只要干了活，就可能出錯。所以最后這個原則是“早糾錯、少浪費”，怎么盡早地發現錯誤，減少浪費。

對于產品研發來說，最大的浪費是返工。因為功能做得不對返工，因為質量問題返工，這些都會造成品牌受損，成本增加。

問題發現得越晚，成本越高。所以我們要通過一切手段盡早糾錯。極限編程提供了一個很好的參考機制：

• 分鐘、小時級別的反饋：通過結對編程、自動化測試、流水線完成
• 天級別的反饋：每日站會、每個需求的驗收測試
• 周級別的反饋：每個迭代的showcase
• 月級別的反饋：版本發布后的反饋

（圖片來自網絡）

如果我們能建立極限編程這樣的從分鐘到月級別的多維度反饋機制，就能夠在早期階段及時察覺問題、糾正錯誤，從而顯著提高工作質量并減少不必要的浪費。

總結

質量就是生命線！

基于嵌入式產品由于其自身特點，“一次把事情做對”是每個研發人員的追求。通過文中介紹的四個原則和相應的實踐，建立多維度的反饋機制，你就能夠最大化實現質量的提升和資源的充分利用。