阿裡研究員：縮短軟體開發中的回報弧

作者 | 鄭子穎

來源 | 阿裡技術公衆号

一 為什麼縮短回報弧是關鍵

都說“沒有度量就沒改進”。但這句話還不完整。度量對于改進的作用是給回報，但單單有度量還不夠，還要度量得足夠頻繁、度量得足夠快，這樣才能更有效的進行改進。縮短回報弧（feedback loop）的價值在生活中有很多例子：

• 減肥。如果每天稱體重，就有助于減肥、有助于控制體重。吃多了，看着體重一天天上去，心裡就有壓力了，就會控制。如果不是每天稱體重，就容易放縱自己，一發而不可收拾。每天稱體重，和每半年稱一次體重，對減（gai）肥（jin）的作用是完全不一樣的。
• 吃飯，如果吃太快，就容易吃太多。原因也是回報弧太長。人的飽腹感是有delay的，從肚子已經吃飽了，到大腦感受到飽腹感，有一個delay。在這個delay這段時間裡，如果繼續吃，就會吃多了。
• 育兒，是回報弧的另一個很好的例子。家裡有小孩的人，都對育兒很焦慮。因為：不知道現在做的這些事情，對小孩将來的上學、就業會産生什麼影響。在育兒這件事情上面，回報弧的長度是論年記的。

工作中也有很多例子：

• 線上變更，我們強調“可監控”。做了一個變更，如果能馬上得到高品質的回報（高品質的回報 = 監控覆寫率高、噪音低、門檻值設定合理），就非常有助于判斷我做的這個變更是好的還是不好的。資損核對，從T+1，到T+H，到TM，也是回報弧不斷縮短的過程。回報弧縮短是非常有助于及時發現問題、及時采取對策的。
• 系統設計分析的評估遺漏，仍然是回報的問題。我的這個系分，對不對，有沒有遺漏。我系分的時候做了一個判斷：這個鍊路可以複用。那麼這個判斷對不對？有沒有遺漏、判斷對不對，這些都是回報。
• 我們平時說 “業務試錯”，也是回報。“試錯”的意思就是：試一下，看看錯不錯，如果錯了就掉頭，如果對了就可以繼續投入。“快速試錯”就是業務效果的回報弧要縮短。沒有“快速試錯”能力，就是回報弧長，就不好。我們要有快速試錯能力。
• 晉升，也是很痛苦。因為晉升的回報弧也很長。辛辛苦苦幹兩三年，還要準備晉升述職，也不知道最後評委會怎麼評價。為了解決這個問題，如果能在過程中增加了一些非正式的述職，提供回報，效果就很好。

二 怎麼算回報弧短？

回報弧短不短，有兩個方面：

1. 回報的前置等待時間。理想狀态是：回報不需要等，任何時候想要回報都可以。
2. 回報本身的耗時。理想狀态是：回報本身的耗時很短，結果立等可取。

打個比方，二三十年前，那時候量血壓（量血壓就是一種回報）是要去醫院量的，隻有等早上醫院開門了、挂個号、排隊等，輪到你了醫生給你量血壓。是以不是任何時候想量血壓就能量血壓的，量血壓的前置等待時間很長。但量血壓這個事情本身，耗時很短，一分鐘就知道結果了。後來，有了家用血壓計，量血壓就不用等了，也不需要求助于醫生，自己在家裡任何時候都可以量，可以每天早中晚量三次，甚至可以每小時都量一下。有了家用血壓計，雖然量血壓這個回報動作本身的耗時并沒有縮短很多，但提高了頻次，任何時候想要回報就可以給回報，前置等待時間縮短到幾乎為零。這個變化就大大的有助于病人控制自己的血壓。類似的，控制血糖也是類似的道理。以前要知道血糖是要去醫院驗血的，現在有一些新技術，可以讓病人自己就可以測量血糖，手指尖夾一下就可以了。這個變化就大大的有助于控制自己的血糖。

軟體開發活動中的回報也是類似的。我是一個開發，我改了一行代碼，我想知道這行代碼有沒有問題。這就是給我回報。我是一個開發，我寫了大半天代碼，把某個功能需要的代碼寫好了，我現在想知道這個功能是不是能work了、我的代碼還要不要再改。這也是回報。今天，在有些團隊，一個開發要得到這些回報，回報弧還很長，長在兩個方面：1）要等，不是任何時候想要回報都可以。2）回報本身的耗時長、成本高，結果也不是立等可取的。回報弧一長，開發效率就降低了。在一些團隊裡，回報弧長，在他們的開發聯調中的展現就是：

• 回報不是随時随地的，要等。因為不是随時随地都可以發起一筆的。也不是每個人都知道怎麼發起一筆的，隻有特定的同學才知道怎麼發起一筆。
• 回報不是立等可取的。就算發起了一筆交易，還要找一個個域的同學check資料。同時，回報的品質也不高，回報不consistent，因為check是人做的，不同人的做的check不一樣。

持續內建就是要縮短回報弧。我們平時一直在做各種事情，比如改代碼、資料庫加字段、修改DRM值、資料庫裡插入資料。持續內建就是每件事情做了以後、每個動作發生以後，都要盡可能快的給我回報，告訴我各種場景是不是通的、代碼是不是work。“持續”了，回報要随時随地都可以給。自動化是縮短回報弧的必要條件（但不是充要條件，因為自動化了以後，還有覆寫率、充分性、有效性等要素）。如果還有人工步驟，就不肯能做到回報弧很短，因為人是不可能随時随地都available的，人的動作也是很慢的。

三 縮短回報弧的成本和投入産出比

要縮短回報弧、建設持續內建，的确是需要投入成本的。要花人花時間去寫自動化、去維護整個基建、去維護持續內建的良好運作。但是，在縮短回報弧上投入的成本，是能從其他地方收回來的。很多人隻看到了建設持續內建需要的投入，但是他們沒有算另一筆賬：這個做好了，能節省多少時間。

例如，對每個項目來說，把每個聯（ji）調（cheng）用例和check都自動化了，這個前期投入，在項目進行的過程中會收到回報。比如，人肉做一次check，算上找人的功夫，加起來每次人肉check可能要15分鐘。而把這個check自動化，需要2小時的工作量（包括自動化、以及後面的維護）。那麼，如果整個項目過程中要做的check次數超過8次，這個自動化就是一筆劃算的買賣。事實上，一個check在一個項目裡面何止跑8次。現在，可能一個check在一個項目裡面隻跑幾次，但這是因為實在沒法再多跑了，因為每次check都非常累。但如果自動化了，check就可以跑很多次很多次。我們是希望check跑很多次很多次的。因為：我們希望我們任何時候改了代碼，都能随時随地的得到回報。

另外，随時随地跑一下check、随時随地的得到回報，還有一個很大的好處，就是：能使得排查問題變得很友善。九十年代的時候，IDE還沒有今天這麼好，比如那時候在Turbo C 2.0裡面寫代碼，當時很多程式員的習慣是每寫幾分鐘代碼就編譯一下。因為當時的IDE比較“簡陋”，不像今天的IDE，哪個地方如果有typo，比如變量名打錯了、關鍵字打錯了，都會馬上有波浪線提示。當時的IDE是沒有這種提示的。如果寫了半個小時、一個小時的代碼，寫了幾百行，然後再編譯，如果編譯有問題，排查起來就比較辛苦（雖然編譯錯誤會告訴我哪行錯了，但是真正的問題根源未必就在報錯的那一行）。是以，當時大家每寫幾分鐘代碼就編譯一下，一旦有錯就知道了，問題就出在剛才那幾分鐘寫的代碼裡面。這就是為什麼縮短回報弧能讓排查問題變得更友善。

投入在建設持續內建上的成本，不能孤立的看。如果隻從單個開發同學的視角看，我的投入産出比未必很高，也許在某些情況下，用原來的方式反而對個人更友善。但在很多情況下，個體受益，往往會導緻群體受損，進而導緻每個個體都受損。個體做一些小的付出，會導緻整個群體受益，進而讓每個個體受益。

這樣的例子在生活中也很多。如果每個人開車都不遵守秩序，都亂變道、亂加塞，那麼整體的道路秩序就會很混亂，進而導緻整個高速上面的車速都降下來，進而導緻每個人都更晚回家。疫情防控也是這個道理。局部的一些隔離措施對個體來說是一個付出。但這些個體的付出，換來的是群體的受益，我們整個社會的疫情防控就做好了，整個社會的經濟恢複了，進而讓每個個體都受益。