給飛馳的法拉利換引擎 - 談邊做業務邊做架構重構（2）

架構重構是大動作，持續時間比較長，而且會占用一定的研發資源，包括開發和測試，是以不可避免的會影響業務功能的開發。是以，要想真正推動一個架構重構項目啟動，需要花費大量的精力進行遊說和溝通。注意這裡我不是指要談辦公室政治，而是指要和利益相關方溝通好，讓大家對于重構能夠達成一緻共識，避免重構過程中不必要的反複和争執。

道理很簡單，但如何做才是關鍵！

一般的技術同學談到架構重構的時候，就會搬出一大堆技術術語：可擴充性、可靠性、性能、耦合、代碼很亂。。。。。。但以我的實際經驗來看，如果和非技術同學這樣溝通，效果如同雞同鴨講，沒有技術背景的同學很難了解，甚至有可能擔心我們是在忽悠ta。例如：

技術同學說：我們系統現在的可擴充性太差了，改都改不動！

産品同學想：咦，可擴充性，和擴胸運動有關麼？。。。。。擴充什麼呢，怎麼會改不動呢，不就是找個地方寫代碼嘛。。。。。。

技術同學說：我們的可靠性太差，現在才3個9，業界都是4個9！

項目經理想：啥是3個9，三九感冒靈？。。。。。。4個9和3個9不就是差個9嘛，和可靠有什麼關系。。。。。。

技術同學說：我們系統設計不合理，a業務和b業務耦合！

營運同學想：咦，耦合，蓮藕還是藕斷絲連？。。。。。。a業務和b業務本來就是互相依賴的呀。。。。。。耦合為什麼不合理呢？。。。。。

以上的樣例并無嘲笑産品營運和項目同學不懂技術的意思，而是說明有的技術術語并不是很好了解，在跨領域溝通的時候，很難達成一緻共識。

除此以外，在溝通時還經常遇到的一個問題是憑感覺而不是憑資料說話。比如說：技術同學說“系統耦合導緻我們的開發效率很低”，但是沒有資料，也沒有樣例，單純這樣說，其他同學很難有直覺的印象。

是以在溝通協調的時候，将技術語言轉換為通俗語言，以事實說話，以資料說話，是溝通的關鍵！

以m系統為例，我們把“可擴充性”轉換為“版本開發速度很慢，每次設計都要考慮是否對門戶有影響，是否要考慮對其它業務有影響”，然後我們還收集了1個月裡面的版本情況，發現有幾個版本設計階段讨論1周甚至2周時間，但開發隻有2天時間；而且一個月才做了4個版本，最極端的一個版本，讨論2周，開發2天，然後等了1個月才和門戶系統一起上線，項目經理和産品經理一聽都被吓到了。

以s系統為例，我們并沒有直接說可靠性是幾個9，而是整理線上故障的次數、每次影響的時長，影響的使用者，客服的回報意見等。。。。。。然後再拿其它系統的資料一對比，無論是産品還是項目還是營運，明顯就看出系統的可靠性有問題了。

當然，如果以上技巧還不奏效，或者遇到極端情況，那就要考慮一些更加有效的手段了！比如說我們遇到一個産品人員，他認為技術優化和架構重構是研發的事情，他不關注，安排開發資源的時候也不考慮重構和優化的投入，要研發自己解決！沒辦法，隻能上升到上級上司層面協調，甚至我們都放出狠話“如果你不同意安排資源進行優化，下次出故障我們就說産品不給人力進行優化和重構”。

除了以上讨論的和上下遊溝通協調外，有的重構還需要和其它相關或者配合的系統的溝通協調。由于大家都是做技術的，有比較多的共同語言，是以這部分的溝通協調其實相對來說要容易一些，但也不是說想推動就能推動的，主要的阻力來自“這對我有什麼好處”和“這部分我這邊現在不急”。

對于“這對我有什麼好處”這個問題，有的人會簡單了解為這是自私的表現，認為對方不顧大局，于是溝通的時候将問題人為拔高，例如“你應該站在部門的角度來考慮這個問題”、“這對公司整體利益有幫助”。。。。。。等等。這種溝通效果其實很差，首先是這種拔高一般都比較虛，沒法明确，不同的人了解不一樣，無法達成共識；其次是如果對公司和部門有利，但對某個小組沒用甚至不利，那麼可能是因為目前的方案不夠好，還可以考慮另外的方案。

那如何才能有效的推動呢？我們的政策是“換位思考、合作雙赢、關注長期”。簡單來說就是站在對方的角度思考，重構對他有什麼好處，能夠幫他解決什麼問題，帶來什麼收益。

以m系統為例，當時有另外一個c系統和m系統通過資料庫直連共用資料庫，我們的重構方案是要去掉兩個系統同時在底層操作資料庫，改為c系統通過調用m系統接口來寫入資料庫。這個方案對c系統來說，很明顯的一點就是c系統短期的改動比較大，要将10幾個讀寫資料庫的地方改為接口調用，剛開始c系統也是覺得重構對他們沒有什麼作用，後來我們經過分析和溝通，了解到c系統其實也深受目前這種架構之苦，主要展現在“資料經常出錯要排查”（因為c系統和m系統都在寫同一個資料庫，邏輯很難保證完全一緻），“要跟着m系統同步開發”（因為m系統增加表或者字段，c系統要從資料庫自己讀取出來，還要了解邏輯）、“c系統要連兩個資料庫，出問題不好查”（因為c系統自己還有資料庫）。。。。。。這些問題其實在m系統重構後都可以解決，雖然短期内c系統有一定的開發工作量，但從中長期來看，c系統肯定可以省很多事情，例如：資料問題排查主要是m系統的事情了，通過m系統的接口擷取資料，無需關注資料相關的業務邏輯等等。通過這種方式溝通協調，c系統很樂意跟我們一起做重構，而且事實也證明重構後對c系統和m系統都有很大好處。

當然如果真的出現了對公司或者部門有利，對某個小組不利的情況，那可能需要協調更高層

級的管理者才能夠推動，平級推動是比較難的。

對于“這部分我們現在不急”這個問題，有的人可能會認為這是在找借口問題，我也不排除這種可能性。但就算真的是找借口，那也是因為大家沒有達成一緻意見，可能對方不好意思直接拒絕。是以這種情況就可以參考上面“這對我有什麼好處”這個問題的處理方法來處理。

如果對方真的是因為有其它更重要的業務，此時勉為其難也不好，還是那句話：“換位思考”！因為大部分重構的系統并不是到了火燒眉毛非常緊急的時候才開始啟動的，而是有一定前瞻性的規劃，如果對方真的有其它更加重要的事情，采取等待的政策也未嘗不可，但要明确正式啟動的時間，例如3個月後開始、6月份開始，千萬不能說“以後”、“等不忙的時候”這種無法明确的時間點。

除了計劃上靈活一點，方案上也可以靈活一點：我們可以先不做這個系統相關的重構，先把其它需要重構的做完。因為大部分需要重構的系統，需要做的事情很多，分階段處理，在風險規避、計劃安排等方面更加靈活可控。