“一人后来过江南，烟雨锁惆怅；听得乌篷轻摇桨，竟不知所想；画船萧鼓声声唱，几曲断人肠；”—— 程响 《人间烟火》
五月的杭州时而细雨蒙蒙，雨后空气清亮，开车走在杭州的高架桥上，红色的月季花，一簇簇，一串串，沿着车道延展开来，冲入视野，说不出的舒爽，心情抑制不住的开心。
最近在做一个复杂业务系统的重构工作，老系统有很多年岁了，十二三年总是有的，三百万行JAVA代码，前后端不分离，JSP代码六十多万行，承载着对公的数以万亿计的融资业务。对于系统的建设投入资源所承接的每个需求，我们会进行分类，比如哪些需求是直接支持业务拓展的，有哪些需求是进行系统技术整改的，或者安全合规改造的，等等。说实话，这个系统是我见过的，其直接支持业务拓展的比例最高的。不夸张的说，这个系统的资源投入，几乎全部贡献给了业务拓展所需要的需求建设。
如果你是这个系统的业务属主，或者对口业务部门之一，是应该高兴呢？还是应该哭呢？世间芸芸众生，对此答案各有不同，甚至于说，我觉得对于某个具体的业务人员来讲，可能在不同的时间点，看到这个现象，或哭或笑都是有可能的。时间是一个神奇魔术师，光阴上的每一页碎片中，会映出一个个完全不一样的自我，而这些互相冲突或者完全相反表现的瞬间，构成了一个真实的人，进而在更大的宏观层面构成了这个真实的世界。
业务启动阶段，系统的全部资源投入业务拓展类需求，可以全力以赴以最快的时间交付给业务所需的系统功能。这样的业务与科技配合，当是业务的幸运，该笑。
业务从无到有，进入大规模运行阶段后，系统的全部资源投入业务拓展类需求，可以支持业务规模做大后所面对的各种奇葩客户需求以及五花八门的奇怪问题，当是业务的幸运，该笑。
业务成熟阶段，需求变少了，但是随着业务的发展做大，可能某些组织架构都已经开始进行调整，相关的系统功能开始大变样，系统的全部资源依然投入业务拓展类需求，或者被动的因为组织架构调整而产生的业务调整诉求，当时业务的幸运，该笑。
十三年过后，业务见到的是一个有着各种各样的丰富功能，承载着各种各样的业务的巨无霸系统。新的需求依然在不断的产生，需求依然在按时交付。
但是也许在某几个瞬间，产品经理会有一丝无助，这个新的需求，到底要动到这个系统的哪些部分，会造成什么影响，哪些能够通过配置来实现，哪些必须要搞代码实现，为什么听说别人的某个系统可以把大部分的能力给配置化，而我这边每次都要代码开发？开发人员说我们也是配置化，但是他们总是悄悄的进行，从来不让我看到，也不让我配置，感觉是对我的能力不放心？
但是也许在某几个瞬间，研发人员会有一丝叹息，简单的需求，从接口服务层增加字段，数据存储层存储字段，外部系统调用传递字段出去，没什么意思，感觉自己开发的代码太水；稍微复杂点的需求，比如一个新的重点客户的对接，对于某个服务接口的处理能力有差异，无法直接用现有的服务能力，咋办？COPY一个呗，把两千行代码粘贴过来，重命名一下，把代码内容，按照最新的需求删除清理下，然后增加一部分必须要写的新逻辑，最后发布为一个新的服务，搞定！转头看向旁边辉煌高耸的京基一百，想想自己刚才干的事情，偷偷喝一口刚拿上来的瑞幸，告诉自己不要在意，牛马人要有牛马人的自觉，负罪感是不存在的，开心一下。嗯？有BUG，打开通义灵码，帮忙分析一下报错，看着提示的修复代码还是靠谱的，应用一下，再次搞定！
会议室里，产品经理一本正经的和一本正经的研发人员一本正经的讨论这次需求的实现为何是这个样子，认为这个也是目前来想到的最佳解决方案，是产品经理和研发人员共同努力，才能得出如此优秀的完美方案。相互点赞与肯定一番，然后回头去各自忙自己应该做的事情去了，做那些在研发流程中规定必须要做的步骤，需求的澄清，需求的讨论，研发的编码，研发自测，测试验证，业务验收等等。步骤严丝合缝，没有任何瑕疵。方案完美，执行亦完美，无敌了。
偶尔不知道为啥，生产环境会爆出个奇怪的问题，比如某个批量任务在处理用户变动数据时，不小心把自己系统的用户信息给清理了大半；再比如某个特殊的报文解析把JVM内存给搞爆了，然后这个问题导致相邻的轮训任务也出现了问题；再比如……还是不要再多想了，每年会出几次而已，每次进行故障复盘，也没有发现研发人员有什么失职，每个具体的问题，都已经制定了详尽的整改方案，非常专业。
其实呢，这种状态不是这一个系统是如此，在各种不同的场合，各种不同的公司，都会有似曾相识的感觉。这不就是我们所经常说的屎山系统的典型特征么。所谓的屎山代码，并不是无法正常运行，反而它会一种非常奇怪，精密无比的奇怪姿势，顽强的完美运转着。
有时候，一切正常才是最不正常的事情，一个个合乎情理的决策，终点是荒诞。系统建设如此，日常生活如此，社会运转也是如此，要不然王朝更替是在干啥？难道自己不能发现问题，并且在还能抢救一把的时候，续命一把么？能，能看到问题的人不少，去尝试解决的人也不少，但最终还是会发生王朝更替。
一个生命体，不论是有机的系统，譬如社会，还是无机的系统，譬如业务系统，其发展历程遵循一定的历史规律。当系统的矛盾修复成本过高时，就无法修复，或者说可以不用考虑修复，而是推翻重来。
到此时，我们再回头看看，曾经在各个阶段，全部资源全力投入到业务需求建设中去的场景，是该笑呢？还是该哭呢？要想活得长，系统是需要内省一下的，埋头干活的时候，也不要忘了抬头看路。
上述提到的这个业务系统，重构已经在路上了，如何重构，从何重构，重构后的系统长什么样子，重构后的系统能避免重蹈覆辙么？我不能肯定的回答以上问题。因为做这些事情，是在抵抗惯性，也是在反人性。遵循管理流程和研发规范开发出来的系统，是不是就是高质量的系统？研发人员在什么样的情况下，会以奇怪的姿势，优雅的击穿所谓的质量防线？
新系统的建设过程中，我会尝试着回答这些问题，在回答这些问题的过程中，一个很重要的切入点是产品工厂。对于银行产品工厂，各种实践层出不穷，相关专著也很多，不敢自称专家。但是我诚恳的将自己的思考以及分析过程，呈现出来，希望这些不是最终结论的过程经历，能够对需要的人有所启发。
所以这次开始写的银行产品工厂系列，不会拘泥于形式，也不会刻意的去总结拔高我们的建设效果，众多的低级问题，我们也会不加避讳的展开讨论，因为真实的世界就是这样的。
是否建设产品工厂就要非常全面的建模？是否建设产品工厂就要大量投入人力？是否建设企业级的产品工厂，就一定比业务领域级的产品工厂高级？甚至于说，产品工厂这个提法是不是就有问题，为啥需要这么多产品？这些问题，我都会在后续的章节中，娓娓道来。
这个时代很快，有些事情还没想清楚，就已经过去了；这个时代很慢，有些绕不过去的问题，会时不时突然从脑海中冒出来，虽然已经告别某个领域好久，也无法避免。那索性我们就在这次重构实践中，将产品工厂这个事情，给搞个痛快。