就总结下吧。
1. 修改上游系统如何确保系统内的其他模块以及下游系统运行正常
（1）最近两周接连发现两个问题：
一个是因为上游系统修改某个模块，由于没注意到对于其他模块的影响以及没有做完整测试，导致上线之后，另外一个模块彻底用不了，处理不了上线之后的新改动。
另一个是因为修改这个模块，抽出了某些属性数据，导致下游拿不到这些抽出来的属性数据，也就是同步数据有了问题。
原因有很多：分析和测试不充分，首先，大家对系统的了解度不够，当时最了解这个系统的人在忙其他，没抽出时间来分析，导致没到这些可能发生的问题。另外从一开始没有把依赖关系和测试用例想好（类似TDD）。当然，考虑现实因素，这这个改动很赶，所以考虑不多，这个和项目管理也有关系。
可以优化：
其实需求发出来的比较早，只不过当时没引起重视，被拖了一下，导致很赶，所以项目管理上可以优化；
另外大家在分析需求的时候，一定要把系统改动导致的影响分析清楚，不要含糊，没想清楚就做很容易崩；
其实还有一种叫做契约测试的东东，曾经在公司培训时讲师有提到过，这个针对某些case（接口等）应该有好处，不过没试过。
2. 用新的技术重做项目时，需要分析的粒度
（1）首先要明确这个revamp上面给的时间，如果有明确的deadline而且比较紧，则分析的粒度可以粗些，然后基本照搬旧代码去写，保证逻辑是对的，快速上线，后面有问题再fix。
（2）当然有足够的时间而且上面不急的话，则可以先分析充分，基本上可以把原来项目完整分析一遍，几乎分析到代码每个细节，然后把业务先都写出来，然后组内share业务需求，不急着做。等分析充分后，基本上给的task可以估计的比较准确而且不用完全按照旧代码，可以提前想某些优化（N年过去了，总得有进步吧）以及提前做些POC（验证性开发练习，验证某种方案/技术的可行性）。另外，基本上想好了测试方案，这样就大大减小了风险（估计不准/开发质量不高/需求做的不完全/难以测试/bug比较多等）。
我们这边正好有个项目是有足够的时间，然后大佬发现分析不足我们就开始做了，就被叫停，基本一周在进行业务分析了。分析下来，才发现其用处，也就是我上面写的那些，后期收益是蛮大的。