作者 | 梅雪松

不知道你有沒有注意到，走進(jìn)各個(gè)企業(yè)，總能看到那么幾句振奮人心的標(biāo)語，其中“一次把事情做對(duì)”絕對(duì)是個(gè)高頻詞匯。以前每次看到，我都會(huì)想：這家企業(yè)也太教條了，都什么時(shí)代了，對(duì)失敗這么零容忍，還怎么創(chuàng)新呢？這個(gè)時(shí)代的主旋律不是從錯(cuò)誤中學(xué)習(xí)，快速響應(yīng)、快速迭代嗎？

然而最近一年的嵌入式領(lǐng)域經(jīng)歷，讓我重新反思并意識(shí)到，“一次把事情做對(duì)”不僅是對(duì)工作效率的追求，更是對(duì)質(zhì)量控制的嚴(yán)格要求。在嵌入式產(chǎn)品開發(fā)領(lǐng)域，這一理念的重要性尤為突出。

與Web系統(tǒng)相比，嵌入式產(chǎn)品有其獨(dú)特性。它是軟硬件的緊密結(jié)合體，不易升級(jí)，一旦發(fā)布，出問題的解決成本異常高昂，后果更為嚴(yán)重。所以“一次把事情做對(duì)”就是一個(gè)合理且必要的目標(biāo)了。

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

不做就不錯(cuò)

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

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

你要學(xué)會(huì)拒絕需求。需求來了，你得想想這需求有價(jià)值嗎？合理嗎？如果對(duì)方說不清楚價(jià)值，給不出理由，那就應(yīng)該拒絕。告訴他不要浪費(fèi)你的時(shí)間和公司的金錢。

你得要求明確的需求。當(dāng)業(yè)務(wù)方提出需求時(shí)，BA（需求分析師）就要分析清楚這個(gè)需求的細(xì)節(jié)，一句話的需求太模糊，沒法干，開發(fā)者也要拒絕。這是你的權(quán)利。一旦你干了，出了 bug 那就是你的錯(cuò)。

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

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

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

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

少做就少錯(cuò)

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

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

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

經(jīng)過這樣三步的準(zhǔn)備和驗(yàn)證之后，就可以信心滿滿地開始編寫代碼了。這時(shí)在面對(duì)復(fù)雜問題時(shí)會(huì)從容不迫，出錯(cuò)的概率也大大降低。

讓機(jī)器多干活

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

現(xiàn)在你終于開心地寫著代碼了。這時(shí)要思考的是自己怎么少干活，怎么讓機(jī)器多干活。畢竟，不做就不錯(cuò)，少做就少錯(cuò)。

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

開發(fā)的工作可以分為三大塊：看代碼、寫代碼、調(diào)試驗(yàn)證。

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

驗(yàn)證這部分是最容易交給機(jī)器來做的。完全可以寫個(gè)驗(yàn)證代碼（測(cè)試代碼）來驗(yàn)證程序的輸出對(duì)不對(duì)，是不是想要的結(jié)果。這是個(gè)一勞永逸的方法。驗(yàn)證代碼只要寫一遍，它就在那里，孜孜不倦一遍遍運(yùn)行著。你完全可以放心交給它幫你完成驗(yàn)證的工作。再進(jìn)一步，甚至可以先寫驗(yàn)證代碼，再寫業(yè)務(wù)代碼，這就是極限編程中的測(cè)試驅(qū)動(dòng)開發(fā)（TDD）。

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

比如你的軟件的構(gòu)建，部署，一切能夠自動(dòng)化的工作，都應(yīng)該交給機(jī)器來做。因?yàn)槿硕际菚?huì)犯錯(cuò)誤的。

早糾錯(cuò)、少浪費(fèi)

前面三個(gè)原則講的都是盡量地少干活，但只要干了活，就可能出錯(cuò)。所以最后這個(gè)原則是“早糾錯(cuò)、少浪費(fèi)”，怎么盡早地發(fā)現(xiàn)錯(cuò)誤，減少浪費(fèi)。

對(duì)于產(chǎn)品研發(fā)來說，最大的浪費(fèi)是返工。因?yàn)楣δ茏龅貌粚?duì)返工，因?yàn)橘|(zhì)量問題返工，這些都會(huì)造成品牌受損，成本增加。

問題發(fā)現(xiàn)得越晚，成本越高。所以我們要通過一切手段盡早糾錯(cuò)。極限編程提供了一個(gè)很好的參考機(jī)制：

• 分鐘、小時(shí)級(jí)別的反饋：通過結(jié)對(duì)編程、自動(dòng)化測(cè)試、流水線完成
• 天級(jí)別的反饋：每日站會(huì)、每個(gè)需求的驗(yàn)收測(cè)試
• 周級(jí)別的反饋：每個(gè)迭代的showcase
• 月級(jí)別的反饋：版本發(fā)布后的反饋

（圖片來自網(wǎng)絡(luò)）

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

總結(jié)

質(zhì)量就是生命線！

基于嵌入式產(chǎn)品由于其自身特點(diǎn)，“一次把事情做對(duì)”是每個(gè)研發(fā)人員的追求。通過文中介紹的四個(gè)原則和相應(yīng)的實(shí)踐，建立多維度的反饋機(jī)制，你就能夠最大化實(shí)現(xiàn)質(zhì)量的提升和資源的充分利用。