就總結下吧。
1. 修改上游系統如何確保系統內的其他模塊以及下游系統運行正常
（1）最近兩週接連發現兩個問題：
一個是因爲上游系統修改某個模塊，由於沒注意到對於其他模塊的影響以及沒有做完整測試，導致上線之後，另外一個模塊徹底用不了，處理不了上線之後的新改動。
另一個是因爲修改這個模塊，抽出了某些屬性數據，導致下游拿不到這些抽出來的屬性數據，也就是同步數據有了問題。
原因有很多：分析和測試不充分，首先，大家對系統的瞭解度不夠，當時最瞭解這個系統的人在忙其他，沒抽出時間來分析，導致沒到這些可能發生的問題。另外從一開始沒有把依賴關係和測試用例想好（類似TDD）。當然，考慮現實因素，這這個改動很趕，所以考慮不多，這個和項目管理也有關係。
可以優化：
其實需求發出來的比較早，只不過當時沒引起重視，被拖了一下，導致很趕，所以項目管理上可以優化；
另外大家在分析需求的時候，一定要把系統改動導致的影響分析清楚，不要含糊，沒想清楚就做很容易崩；
其實還有一種叫做契約測試的東東，曾經在公司培訓時講師有提到過，這個針對某些case（接口等）應該有好處，不過沒試過。
2. 用新的技術重做項目時，需要分析的粒度
（1）首先要明確這個revamp上面給的時間，如果有明確的deadline而且比較緊，則分析的粒度可以粗些，然後基本照搬舊代碼去寫，保證邏輯是對的，快速上線，後面有問題再fix。
（2）當然有足夠的時間而且上面不急的話，則可以先分析充分，基本上可以把原來項目完整分析一遍，幾乎分析到代碼每個細節，然後把業務先都寫出來，然後組內share業務需求，不急着做。等分析充分後，基本上給的task可以估計的比較準確而且不用完全按照舊代碼，可以提前想某些優化（N年過去了，總得有進步吧）以及提前做些POC（驗證性開發練習，驗證某種方案/技術的可行性）。另外，基本上想好了測試方案，這樣就大大減小了風險（估計不準/開發質量不高/需求做的不完全/難以測試/bug比較多等）。
我們這邊正好有個項目是有足夠的時間，然後大佬發現分析不足我們就開始做了，就被叫停，基本一週在進行業務分析了。分析下來，才發現其用處，也就是我上面寫的那些，後期收益是蠻大的。