浅谈产品架构
故事
先讲一个小故事,张三是一个程序员,在金九银十的季节去了一家新公司就职。新的公司看起来前景不错,做的内容也是行业前沿的产品,张三发誓自己要在新的公司一展宏图,用自己精湛的开发技术为公司的上市添砖加瓦。
就职的第一天公司开放了代码的权限,张三迫不及待的熟悉起了公司的核心项目。
然后,心凉了半截,公司的项目就像是一个垃圾场,各种恶心的代码堆成山。他要做的事情,就是去维护这些老项目。在那一刻,张三内心的幻想瞬间破灭。
在维护了一段时间屎山项目之后,事情似乎出现了转机,终于有一天,有一个新项目下来,老板任命张三是负责人,全权负责这个全新的项目,张三内心狂喜,终于可以证明自己了。
“我一定要让代码显得优雅,跟烂代码说再见。” — 张三
刚开始非常顺利,张三用了各种设计模式,疯狂抽象业务,越做越有劲。感觉一身的才学终于有了展示的机会,那种爽快的感觉无语言表
但是项目是多人合作的,随着时间的流逝,项目的迭代,很多新人开始不按照预定的规范来开发代码。
为了图方便,微服务如雨后春笋般一个个往外面冒,在代码里面毫不犹豫地填充了一个又一个if语句。
张三本能的觉得不对,他开始手动的限制那些不符合规范的代码提交。可是项目时间的压力越来越大,张三终于迫于交付压力放开了限制。
项目顺利的交付完成了,但是奇怪的代码缺永久的留在了项目中。
慢慢的,原始的精美的设计开始变得越来越臃肿,逻辑变得复杂无比。
没有人敢去重构,也确实不可能重构了。
终于,张三实在无法忍受,在金九银十的季节辞职去了一家新公司就职,新的公司看起来前景不错,做的内容也是行业前沿的产品,张三发誓自己要在新的公司一展宏图,用自己精湛的开发技术为公司的上市添砖加瓦…
这样的故事在互联网行业内一遍一遍的发生,似乎任何项目随着时间的演进,一个个补丁打到最后都会变成屎山型项目,充斥着各种历史遗留问题,新功能开发越来越慢,最终无法演进走向项目的终结。
有些互联网公司会为了延长这个项目的生命周期,在某个节点聘请资深的软件架构师,他们往往熟读《重构》,用各种各样的技术手段去延缓这个过程。具体可以延缓多久,基本得看架构师的水平。
最近我在网上冲浪的时候发现了一个叫做"产品架构"的概念,