Refactor?or Patching?

郑昀 20090925

1、

几十年前，一帮钻研国外开源代码、研究过各个国家杰出软件工程理论的程序员们，产生了建立一个自主架构的愿望。

这些人有的在外企底层做过coding或者打杂，其中一位若干年后成为了 company 的首席架构师。一些人目睹了另一个庞大软件王国的四处扩张，威慑天下，心向往之并奉为圭臬，劝说其他人沿袭那个帝国的架构和思想，殊不知那个远古时代骨子里就流着邪恶之血的帝国也早已病入膏肓。更多人还是土狼，在国内红海中历经磨砺，几乎每个人都是人中之龙。

这样一群人聚集起来，在几十年前定下来了一个大架构，并设定了一个非常宏伟的 Vision，但这原本是一位圣贤为他的国度应付几百万独立访问者设定的，又如何能像古代的那些帝国开创者一样定为“祖宗之法不可变”呢？

2、

庞大的工程就这么建立了起来，它确实让 company 获益，创造了世人瞩目的诸多成就，顶住了巨大的以亿计的流量冲击。可人们都知道它隐隐有一个硬伤，没有太多实践经验的那群程序员，虽然早已学习过很多优秀的、行之有效的设计模式，但不知为什么却没有贯彻到他们亲手打造的工程里。

他们留下了太多生硬的接口，工作流多如牛毛，但指导它们运转的原则却不那么清晰，甚至蹩脚。随着时间的流逝，在这些接口上衍生出了太多的应用，有太多的新程序员在这些接口和服务上继续开发，并尝试升级系统，但就像多数工程一样，在一个跑了几十年的生产系统上，要让系统继续不间断地应付与日俱增的访问量，你只能零敲碎打修修补补。

无数新程序员学习这个系统的代码时，都呼吁“重构”“敏捷”。但项目总监、产品总监、运营总监们知道，“重构”谈何容易，谁能承受为了升级而暂停服务？谁能承担重构失败的责任？没有测试环境，只有生产环境，你怎么保证你的重构是正确的。

在原有系统上挂接的各个运营单位要在每一次系统小升级中分一杯羹，在每一个小补丁上都要嵌入自己的推广代码，所以也都不愿意自己被砍掉。

你有什么好办法？

郑昀 20090925 北京报道