浅谈产品架构

浅谈产品架构

故事

先讲一个小故事，张三是一个程序员，在金九银十的季节去了一家新公司就职。新的公司看起来前景不错，做的内容也是行业前沿的产品，张三发誓自己要在新的公司一展宏图，用自己精湛的开发技术为公司的上市添砖加瓦。

就职的第一天公司开放了代码的权限，张三迫不及待的熟悉起了公司的核心项目。

然后，心凉了半截，公司的项目就像是一个垃圾场，各种恶心的代码堆成山。他要做的事情，就是去维护这些老项目。在那一刻，张三内心的幻想瞬间破灭。

在维护了一段时间屎山项目之后，事情似乎出现了转机，终于有一天，有一个新项目下来，老板任命张三是负责人，全权负责这个全新的项目，张三内心狂喜，终于可以证明自己了。

“我一定要让代码显得优雅，跟烂代码说再见。” — 张三

刚开始非常顺利，张三用了各种设计模式，疯狂抽象业务，越做越有劲。感觉一身的才学终于有了展示的机会，那种爽快的感觉无语言表

但是项目是多人合作的，随着时间的流逝，项目的迭代，很多新人开始不按照预定的规范来开发代码。

为了图方便，微服务如雨后春笋般一个个往外面冒，在代码里面毫不犹豫地填充了一个又一个if语句。

张三本能的觉得不对，他开始手动的限制那些不符合规范的代码提交。可是项目时间的压力越来越大，张三终于迫于交付压力放开了限制。

项目顺利的交付完成了，但是奇怪的代码缺永久的留在了项目中。

慢慢的，原始的精美的设计开始变得越来越臃肿，逻辑变得复杂无比。

没有人敢去重构，也确实不可能重构了。

终于，张三实在无法忍受，在金九银十的季节辞职去了一家新公司就职，新的公司看起来前景不错，做的内容也是行业前沿的产品，张三发誓自己要在新的公司一展宏图，用自己精湛的开发技术为公司的上市添砖加瓦…

这样的故事在互联网行业内一遍一遍的发生，似乎任何项目随着时间的演进，一个个补丁打到最后都会变成屎山型项目，充斥着各种历史遗留问题，新功能开发越来越慢，最终无法演进走向项目的终结。

有些互联网公司会为了延长这个项目的生命周期，在某个节点聘请资深的软件架构师，他们往往熟读《重构》，用各种各样的技术手段去延缓这个过程。具体可以延缓多久，基本得看架构师的水平。

最近我在网上冲浪的时候发现了一个叫做"产品架构"的概念，再结合曾经做烂的一个个项目，忽然有了些许感悟。

研发人员习惯用技术解决问题，但问题的解法是多样的，或许从另一个角度切入，会有新的解法。当然，无论用什么方法，归根到底