[[355494]]

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

一 為什么縮短反饋弧是關(guān)鍵

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

• 減肥。如果每天稱體重，就有助于減肥、有助于控制體重。吃多了，看著體重一天天上去，心里就有壓力了，就會控制。如果不是每天稱體重，就容易放縱自己，一發(fā)而不可收拾。每天稱體重，和每半年稱一次體重，對減(gai)肥(jin)的作用是完全不一樣的。
• 吃飯，如果吃太快，就容易吃太多。原因也是反饋弧太長。人的飽腹感是有delay的，從肚子已經(jīng)吃飽了，到大腦感受到飽腹感，有一個delay。在這個delay這段時間里，如果繼續(xù)吃，就會吃多了。
• 育兒，是反饋弧的另一個很好的例子。家里有小孩的人，都對育兒很焦慮。因為：不知道現(xiàn)在做的這些事情，對小孩將來的上學(xué)、就業(yè)會產(chǎn)生什么影響。在育兒這件事情上面，反饋弧的長度是論年記的。

工作中也有很多例子：

• 線上變更，我們強調(diào)“可監(jiān)控”。做了一個變更，如果能馬上得到高質(zhì)量的反饋(高質(zhì)量的反饋 = 監(jiān)控覆蓋率高、噪音低、閾值設(shè)定合理)，就非常有助于判斷我做的這個變更是好的還是不好的。資損核對，從T+1，到T+H，到TM，也是反饋弧不斷縮短的過程。反饋弧縮短是非常有助于及時發(fā)現(xiàn)問題、及時采取對策的。
• 系統(tǒng)設(shè)計分析的評估遺漏，仍然是反饋的問題。我的這個系分，對不對，有沒有遺漏。我系分的時候做了一個判斷：這個鏈路可以復(fù)用。那么這個判斷對不對?有沒有遺漏、判斷對不對，這些都是反饋。
• 我們平時說 “業(yè)務(wù)試錯”，也是反饋。“試錯”的意思就是：試一下，看看錯不錯，如果錯了就掉頭，如果對了就可以繼續(xù)投入。“快速試錯”就是業(yè)務(wù)效果的反饋弧要縮短。沒有“快速試錯”能力，就是反饋弧長，就不好。我們要有快速試錯能力。
• 晉升，也是很痛苦。因為晉升的反饋弧也很長。辛辛苦苦干兩三年，還要準(zhǔn)備晉升述職，也不知道最后評委會怎么評價。為了解決這個問題，如果能在過程中增加了一些非正式的述職，提供反饋，效果就很好。

二 怎么算反饋弧短?

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

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

反饋本身的耗時。理想狀態(tài)是：反饋本身的耗時很短，結(jié)果立等可取。

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

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

• 反饋不是隨時隨地的，要等。因為不是隨時隨地都可以發(fā)起一筆的。也不是每個人都知道怎么發(fā)起一筆的，只有特定的同學(xué)才知道怎么發(fā)起一筆。
• 反饋不是立等可取的。就算發(fā)起了一筆交易，還要找一個個域的同學(xué)check數(shù)據(jù)。同時，反饋的質(zhì)量也不高，反饋不consistent，因為check是人做的，不同人的做的check不一樣。

持續(xù)集成就是要縮短反饋弧。我們平時一直在做各種事情，比如改代碼、數(shù)據(jù)庫加字段、修改DRM值、數(shù)據(jù)庫里插入數(shù)據(jù)。持續(xù)集成就是每件事情做了以后、每個動作發(fā)生以后，都要盡可能快的給我反饋，告訴我各種場景是不是通的、代碼是不是work。“持續(xù)”了，反饋要隨時隨地都可以給。自動化是縮短反饋弧的必要條件(但不是充要條件，因為自動化了以后，還有覆蓋率、充分性、有效性等要素)。如果還有人工步驟，就不肯能做到反饋弧很短，因為人是不可能隨時隨地都available的，人的動作也是很慢的。

三 縮短反饋弧的成本和投入產(chǎn)出比

要縮短反饋弧、建設(shè)持續(xù)集成，的確是需要投入成本的。要花人花時間去寫自動化、去維護整個基建、去維護持續(xù)集成的良好運行。但是，在縮短反饋弧上投入的成本，是能從其他地方收回來的。很多人只看到了建設(shè)持續(xù)集成需要的投入，但是他們沒有算另一筆賬：這個做好了，能節(jié)省多少時間。

例如，對每個項目來說，把每個聯(lián)(ji)調(diào)(cheng)用例和check都自動化了，這個前期投入，在項目進行的過程中會收到回報。比如，人肉做一次check，算上找人的功夫，加起來每次人肉check可能要15分鐘。而把這個check自動化，需要2小時的工作量(包括自動化、以及后面的維護)。那么，如果整個項目過程中要做的check次數(shù)超過8次，這個自動化就是一筆劃算的買賣。事實上，一個check在一個項目里面何止跑8次。現(xiàn)在，可能一個check在一個項目里面只跑幾次，但這是因為實在沒法再多跑了，因為每次check都非常累。但如果自動化了，check就可以跑很多次很多次。我們是希望check跑很多次很多次的。因為：我們希望我們?nèi)魏螘r候改了代碼，都能隨時隨地的得到反饋。

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

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

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