刚好今天朋友聊到老系统怎么翻新，
大家手上的系统有一天都会变老系统，
如果维护的不够，可能就会变成被讨厌的系统。
做人可以有被讨厌的勇气，系统被讨厌就会被换新。
很多人说老系统换新很难，但我觉得还是有一些方法论的。
几个我自己会处理的做法：
1. 找出最小故障单位
被称之为系统的东西通常是多元件的，每个元件有各自的职责，
所以通常不可能是一次全部都有问题。
一般来说，一个老系统首先需要的是体检，把常失火的地方找出来。
可能是一或多个。
2. 开始切出问题的边界，凡是系统一定是有 input 跟 output 。
再来，仔细读懂这一段的程式码或行为，如果没有程式码，
那就记录这一段足够的input 跟 output 确认逻辑。
3. 建立测试环境
4. 拉出隔离层(中间叠 proxy 或改成透过网络存取等)
5. 局部替换逻辑(由 proxy 导部分流量检查有无异常)。
6. 上线
7. 如果出问题，必须可还原回修改前的模式
=======
其实会难，通常是没有切对结构，
或是没找到 core issue 。
另外多数情况下未必是整个重写，通常是局部的调整可以解决问题。
有一种情况是需要向旧相容，
这种时候接口会同时支援旧的，直到确定不再呼叫。
很多人会认为写新的就不用管旧的接口，
结果上线一测东漏西漏死的乱七八糟。
总之，改老系统时，
保守的多做事多买多层保险才是先进。
改老系统的心法叫做移花接木，
强调的是模仿，与原本的功能行为越像越容易嫁接。
很多人总觉得重做功能就要东加西加，
功能连对照组都没有，当然就会越做越难。
如果是为了加新功能，所以要重写，
这其实不叫重写，这叫杠上开花。
重写是跟系统杠上，加新功能是让脑袋开花。
一般调整系统都会需要明确目的，也能结构化确认问题，
往往是非常多细碎单元的组合，而不是一次万里长征。
拍片也讲求分段拍摄再后制剪接到位，
但重写系统想要长镜头一镜到底，这是高难度技巧。
总之系统重整，单纯就是技能问题跟心态问题。
撇开耍屌、自以为是，认真的面对既有的程式跟需求。
尊重团队已经做到的事情，
想着怎么用新的方法完成，这些才是真正的目标。
多数的失败，肇因于不尊重既有的逻辑，
贸然躁进调整，自然出事。
最可怕的是单行道的改版，
无法还原，一旦出事就大地震。
爬山要确保，写程式也得有备案。
总之，尊敬既有的程式码，与之共存，
并比既有的程式码更理解既有的程式码的目的。
这样要重写程式，很难失败。
而且减少失败次数，就是加速成功。