開發者寫好了某個功能的代碼，想知道這個功能是不是實現了，代碼還需不需要再改，這就是一種反饋。在軟件開發中，尤其是聯調時，縮短反饋弧有助于及時發現問題、采取對策，提高開發效率。那么什么樣的反饋弧才算短?如何看待縮短反饋弧的投入產出比?本文分享阿里巴巴研究員南門對軟件開發中反饋弧的相關思考和看法。

一 為什么縮短反饋弧是關鍵

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

減肥。如果每天稱體重，就有助于減肥、有助于控制體重。吃多了，看著體重一天天上去，心里就有壓力了，就會控制。如果不是每天稱體重，就容易放縱自己，一發而不可收拾。每天稱體重，和每半年稱一次體重，對減(gai)肥(jin)的作用是完全不一樣的。

吃飯，如果吃太快，就容易吃太多。原因也是反饋弧太長。人的飽腹感是有delay的，從肚子已經吃飽了，到大腦感受到飽腹感，有一個delay。在這個delay這段時間里，如果繼續吃，就會吃多了。

育兒，是反饋弧的另一個很好的例子。家里有小孩的人，都對育兒很焦慮。因為：不知道現在做的這些事情，對小孩將來的上學、就業會產生什么影響。在育兒這件事情上面，反饋弧的長度是論年記的。

工作中也有很多例子：

線上變更，我們強調“可監控”。做了一個變更，如果能馬上得到高質量的反饋(高質量的反饋 = 監控覆蓋率高、噪音低、閾值設定合理)，就非常有助于判斷我做的這個變更是好的還是不好的。資損核對，從T+1，到T+H，到TM，也是反饋弧不斷縮短的過程。反饋弧縮短是非常有助于及時發現問題、及時采取對策的。

系統設計分析的評估遺漏，仍然是反饋的問題。我的這個系分，對不對，有沒有遺漏。我系分的時候做了一個判斷：這個鏈路可以復用。那么這個判斷對不對?有沒有遺漏、判斷對不對，這些都是反饋。

我們平時說 “業務試錯”，也是反饋。“試錯”的意思就是：試一下，看看錯不錯，如果錯了就掉頭，如果對了就可以繼續投入。“快速試錯”就是業務效果的反饋弧要縮短。沒有“快速試錯”能力，就是反饋弧長，就不好。我們要有快速試錯能力。

晉升，也是很痛苦。因為晉升的反饋弧也很長。辛辛苦苦干兩三年，還要準備晉升述職，也不知道最后評委會怎么評價。為了解決這個問題，如果能在過程中增加了一些非正式的述職，提供反饋，效果就很好。

二 怎么算反饋弧短?

反饋弧短不短，有兩個方面：

反饋的前置等待時間。理想狀態是：反饋不需要等，任何時候想要反饋都可以。

反饋本身的耗時。理想狀態是：反饋本身的耗時很短，結果立等可取。

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

軟件開發活動中的反饋也是類似的。我是一個開發，我改了一行代碼，我想知道這行代碼有沒有問題。這就是給我反饋。我是一個開發，我寫了大半天代碼，把某個功能需要的代碼寫好了，我現在想知道這個功能是不是能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是沒有這種提示的。如果寫了半個小時、一個小時的代碼，寫了幾百行，然后再編譯，如果編譯有問題，排查起來就比較辛苦(雖然編譯錯誤會告訴我哪行錯了，但是真正的問題根源未必就在報錯的那一行)。所以，當時大家每寫幾分鐘代碼就編譯一下，一旦有錯就知道了，問題就出在剛才那幾分鐘寫的代碼里面。這就是為什么縮短反饋弧能讓排查問題變得更方便。

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

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