在別人寫的代碼上做修改我是這樣保證正確性

引子

9年前我入職一家公司，團隊里都是之前公司的原同事，彼此都很熟，對各人的能力也都很了解，我當時負責整個公司的搜索引擎，上班第一天，我在看之前的遺留代碼，原同事過來問我：“你是打算用這個老系統改造還是重寫？”我笑了笑說：“我還是重寫吧，” 原同事也意會的笑了笑說：“我就知道，”當時我們都多少帶著些技術高人一籌的傲氣，而我那位同事成長的更快，我們第三次做同事的時候，他整個人更加成熟謙虛，而那時我還在路上，9年來我再也沒有接手可以毫無負擔，直接推倒重寫的代碼，就算有，不搞清楚以前的邏輯和背景，就直接拋掉這些歷史包袱是不對的，在修改別人寫的代碼的時候，我們需要信奉黑格爾的名言：“存在即合理”，一定要弄清楚之前這樣撰寫代碼是出于什么樣的考慮，
專案背景
這段時間我們團隊在修改之前的一個功能，在我接觸到這個專案的時候，設計方案已經被討論了多次，已經到了詳細設計的階段，在我視角需求是這樣的：就是一個查詢介面的改造，改造前代碼邏輯被前人做復雜了，這次一些從下游拿資料來拼接回傳值的邏輯可以改成從下游(資料基礎服務)簡單取部分資料，另外一部分寫死，

聽起來是不是很簡單，這么一件事，總有也就幾百行代碼的開發量，有兩個團隊領導分別做專案經理和技術經理，由領導親自做的設計方案；我作為團隊架構師也被指派親自負責查詢服務模塊的開發；一名一直做基礎資料服務的同學做基礎服務部分的改造；一個同學專門負責白盒測驗；一個同學負責黑盒測驗；還有一個對之前邏輯了解的同學負責方案評審和投產步驟撰寫，能看得出來這個功能重要且有其特殊性，引起了高度的重視，因為這是修改之前幾年前撰寫的幾經易手、十分核心且之前沒怎么敢改動的代碼，

詳細方案設計在別人寫的代碼上做修改，做詳細設計時，第一步要做的是充分評估改動影響；第二步是畫流程圖梳理改動前后的呼叫鏈和資料流，列出修改點；第三步是定好測驗關鍵案例，確保結果的正確性，評估影響

出現故障，第二要做的是什么呀？是止血，那第一要做的是什么呀？是評估影響，要開展一個新專案，第一要做的是什么呀？是規劃目標，那第二要做的是什么呀？是評估影響，做方案設計，第一要做的是什么呀？是制定目標，那第二要做的是什么呀？是評估影響，一言以蔽之，評估影響是在任何行動開始前，除了制定目標之外最重要的事，在很多方案設計中，往往沒有將這一步規劃到明確的流程中去，草率的實施，是日后出現問題的根源，
具體要怎么做呢？舉個例子來說，之前做過很多http介面，常有需求說要在回傳值里添加欄位，很多剛剛出入編程這一江湖的新人，會覺得添加欄位還能有什么影響，15年的老江湖告訴你：大錯特錯了！
添加欄位，首先對容量可能會有影響，需要額外的日志等存盤空間，占更多的帶寬；其次，下游有可能有校驗，所以評估影響重要的一步是要確認影響，和所有的呼叫方溝通確認，確認沒有影響再進行下一步，
邏輯梳理從這一步做的好壞，我直接可以判斷你的高考分數，在本周答辯會上，在對我的提問環節，HR小姐姐說不是單單問我，要問我們在場所有人一個問題：“代碼都讀過了，為什么有些人還對邏輯不清楚？”其中一個架構師回答到：“就是你上學的時候讀魯迅的書和現在讀魯迅的書的區別，”其實我想說：“治學三境界了解一下”，但是想想為這句話我要解釋兩分鐘詩詞，在述職評分現場，肉眼可見的在拽，豈不是在給自己減分，所以我選擇了沉默，這里自己的地盤提一嘴，晚清國學大師王國維在其不朽之作《人間詞話》中曾用形象的比喻提出了治學的三種境界或說是三個程序：

古今之成大事業、大學問者，罔不經過三種之境界：“昨夜西風凋碧樹，獨上高樓，望盡天涯路，”此第一境界也，“衣帶漸寬終不悔，為伊消得人憔悴，”此第二境界也，“眾里尋他千百度，驀然回首，那人卻在燈火闌珊處，”此第三境界也，

第一境界表達的本意是高瞻遠矚，立志高遠，在讀代碼這件事上，可以理解為了解基本框架結構和代碼基本實作的功能，第二境界是刻苦鉆研深入的程序，第三境界是頓悟，了解之前梳理中沒有想明白或忽略的細節或問題，

而我們動手改別人代碼之前，至少要做到第二境界，一個可用工具就是流程圖，將每個步驟對資料做的轉換，并標識出每一步資料格式，

最后，總結一下修改點，方便形成測驗案例和checklist，

制定測驗案例

在評估影響和邏輯梳理時，關鍵案例其實已經出來了，這個階段是個整理階段，同時，也是從另外的視角，看看是否能達到“驀然回首”的境界，補齊之前邏輯上的疏漏，

以上三步完成之后，就是設計方案評審階段，千人千問，多視角審視方案，也增進理解，

撰寫代碼

在寫代碼之初，自認對代碼做了深入的分析，加上15年代碼撰寫經驗，覺得自己寫這段代碼豈不是降維打擊，結果代碼提交之后，真的是被打擊了，Code Review同學直接在群里說給我找出來7個問題，開會的時候，其他同學也開玩笑的提了一嘴，就這么被年輕同事弄沒了排面，雖說知道格局境界要高，心里也確有不爽，關鍵是他提的7個問題，他提之前我都有認真思考過，代碼是刻意為之，

后來我們就語音溝通了一下這些問題，雖說有些我還是不認同，但是也能明白他提的問題的道理，

有一條，是我新定了一個錯誤碼，我的思考是是這個查詢介面非常重要，希望出現問題和其他系統做區別，而這是我們內部錯誤碼，外部錯誤碼沒有變，所以不會對外部產生影響，而Code Review的同事說出了我之前沒有了解到的資訊：他之前為老錯誤碼單獨做了監控，我新定義的錯誤碼，監控就不生效了，

另外一條，說我缺少非空判斷，這個非空我是加了的，底層加了非空判斷，邏輯是沒有問題的，但是他覺得代碼上層不加，語意上不連貫，我覺得邏輯應該內聚，自己做好的事情不應該讓上層來做，這種問題，我統歸為風格問題，每個人寫文章的思路是不同的，寫代碼的思路也是不同的，別人覺得那樣更好理解，其實換一個人就不這么認為，《有效的Java》這本名著，現在很多理論在被啪啪啪打臉，所以我遇到這種問題的時候都是不愿意糾結的，我Review Code別人代碼的時候也從不去糾結別人這種問題，我只說自己的考慮，別人是否接受我都不會因為這個把別人代碼打回去，這里Code Review的同事糾結，非要我遵從他的思路，我不同意改，也覺得沒有爭論的必要，我提出加個注釋作為妥協，結束這個爭論，

其中最重要的一條，涉及一個日志列印，結構化日志的列印，整個工程用了前人寫的一個“輪子”，在jar包里不好改，改了怕影響太大，因為使用的日志，日志涉及其他兩個非常重要的功能，這兩個功能要借助日志分析，用戶來進行自動操作，所以我的處理方式是新定義了一個模板，來確保不影響原有功能，Code Review同事讓我將共用模板改一下，不要新建模板，模板多了不好維護，我的擔心是上線排期非常緊，老邏輯沒有人徹底清楚，之前的測驗用例并不完善，所以求小心，而Code Review的同事說沒問題的，出了問題他承擔，真要出了問題，上面一層層的扛著擔子，我也責無旁貸的，不會落到他身上，我也不建議他這樣的保證，后來，我自己想了一下，如果用兩個模板，兩個append同時寫一個日志檔案，之前也沒有這么用過，也有風險，所以還是按照他說的改了，但是開會Diff代碼的時候(上線前將上一個版本的代碼和這個版本的代碼做比較)，我開玩笑還提了一嘴，說同事說了“出問題他承擔”，其實是隱含的勸誡一下，這句話有些慷他人之慨，其實本質上我同事的意思就是：“我和你一起保證修改的正確性”，用心是非常好的，

最終提的7條每條我們都爭論了，那是因為每一條我們兩個都真正思考過，這種氛圍我覺得是非常好的，

測驗

我的代碼CodeReview的同事有找出來問題，專業的QA白盒測驗和黑盒測驗都沒有發現問題，這個和我預期的一致，因為在編碼階段，不僅我自己用心了，CodeReview的同事也用心了，沒有問題才是正常的，這也應該是撰寫提交后最普遍的結果，因為一旦問題讓測驗發現了，那這通常只是冰山一角，底下會隱藏更多的問題，

后記

道、法、術，做任何事情的道理都是一樣的，用心是第一位，《山河令》里體現用心的地方很多，其中一項就是留白，

比如溫周二人在龍淵閣掉落谷底，面對藥人的圍攻，周說：“得君為友不枉此生”，溫言：“幸得君心似我心，”很多人都知道：“幸得君心似我”心出自《卜算子·我住長江頭》，下一句是：“定不負相思意”，在生死存亡之際，下面一句要是說出來，馬上共生共死的兄弟情就變質了，所以情商高的周接了一句：“聽你念詩我頭疼，”面對死亡的坦然樂觀，情緒就烘托出來了，

再比如，片尾曲《天涯客》里，一句歌詞是“把古道西風瘦馬換小橋流水人家，”這也是個留白，《天凈沙秋思》之前教兒子寫作文的時候，我教過他：“你想把本來可以寫100字的作文寫成400字可以先羅列一堆景物描寫，最后一句才是你真正要表達的內容”，而《天凈沙秋思》最后一句是“斷腸人在天涯”正好對曲名的天涯客，

編程和其他事情一樣，用心是出好作品的關鍵，

推薦閱讀

mybatis優秀的設計總結

最近做code review的5點經驗分享

Java的強參考、軟參考、弱參考、虛參考

懂了！國際演算法體系對稱演算法DES原理

標籤：其他

上一篇：C中的神經網路

下一篇：云效自建測驗自動化最佳實踐