七夕情人节之架构重构

序言

    掐指一算，十年不遇的七夕情人节快到了，你准备好了吗。。。

    看我不爽可以，但是你要打得过我朋友，他发起神经就不是打我这么简单的了，他狠起来连自己都打。

风言风语

    1 架构重构

    系统太慢，找出慢sql优化试试，开发效率低，把系统给拆分拆分，一个系统，如果故障频发，找不到故障点，那么怎么优化，如果找不到系统的瓶颈，那么怎么优化呢？

    接手一个烂系统，emmm。。。为了维护有些人的面子，不能说烂，要说还有很大的改进空间，所以呢，就可以进行架构重构了。。。

    架构重构的首要条件就是，如果是从0到1设计这个系统，那么和现在的系统有什么区别？能解决哪些已知问题？对于这些已知的问题，能达成多少倍的改进。。。这需要很多的前置工作，分析现在的系统架构，找出目前存在的问题列表。。。

    细细说来，架构重构和离婚好像很像的感觉，在架构重构的时候，需要考虑两件事情，一个是应用层架构的重构，可以进行拆分，降低系统之间的依赖，就像离婚，哎哟，两个人分开了，不是不爱，是实在是不能忍受目前的一些问题，看看应用重构，也是一样的道理，你无法忍受相互模块或者功能的依赖，一个出问题，整个系统都受连累，就像离婚吵架，一吵架，都不好过。。。没有依赖，就没有伤害。。。

    另外一件事就是持久层的重构，就像离婚时候的财产分割，这个我买的，那个也是，这个就像数据库的重构是一样的，这个表里面有部分数据是业务系统的，还有部分数据是管理系统的，什么都混杂在一起。。。离婚呢，受苦受累的都是孩子，就像持久层的各种非结构化数据，例如文件存储呀，键值存储呀。。。分割起来还是比较麻烦的。。。持久层的重构要么需要进行数据割接，要么还把孩子作为共有的一部分，这部分就不拆了，毕竟存储的拆还是非常麻烦的。。。

    我们总说要重构，但是在各种爆发的问题背后，最核心的问题是什么，我们要解决的问题是什么？就像离婚的时候，离婚解决了什么？换一个对象就不会发生同样的问题吗？重构还好一点，毕竟是针对性的进行求解，而且时间是可以估算的。。。但是，离婚后的再婚就不好说了，毕竟很难说是某个人导致的问题。。。很多人说，一个巴掌拍不响，但是我从来都不信。。。你把脸伸过来，我一个巴掌你看看香不香。。。

    想进行架构重构的时候，想清楚一个问题，风险，这个表示业务已经上线，如何让产品，技术去承担更换系统的风险；价值，这个表示如何说服老板投入资源去做这件事情；计划，这个表示有明确的时间点可以达成目标；投入成本，所花费的时间，消耗的人力。。。最终的收益就是价值减去成本。。。可衡量的指标，可度量的目标。。。

    2 烂架构的由来

    其实也不能说是烂架构，不能指责，不能抱怨，不能埋怨，要说，这个架构不太适合目前业务的发展，当初设计的时候，受限于人力，时间，从而导致架构没有进行恰当的设计，迫于业务的紧促性，从而导致了今天。。。

    就像结婚，并不是说因为爱情，而是迫于环境的压力，迫于年龄的压力，迫于同龄人的压力，导致不得乖乖去做这件事。。。爱情？想的美。。。哈哈哈

    在合适的年龄碰上了合适的你。。。这才是好的架构，能共同的成长，能有所包容，能有所不同，那么问题来了。。。你是选择你爱的，还是选择爱你的。。。

    一般呢，你选择你爱的，那么就会出现一种情况，这种架构能力你无法掌控，或许是技术不够，或许是能力不足，从而会导致出现各种各样的故障，看似主动，实际被动。。。

    其实，架构出现问题，也是一件好事，说明业务在快速发展，而架构如果一直不出现问题，那说明业务也就那样了，没准哪天就做黄了。。。所以呢，机遇与挑战并存。。。

    我们活在今天，却在计划明天。。。那么问题来了，你到底图啥。。。

    爱一个人很难，就像牛郎织女。。。一年才见一次，所以呢，很多东西，不是努力就够了，不要问原因。。。问就是因为爱情。。。天下没有无缘无故的爱，也没有无缘无故的恨。。。不要问，问就是因为爱情。。。哈哈哈

    说好的情人节，说啥离。。哪壶不开提哪壶，不是故意的，而是有意的。。。怪我咯。。

    最近看了一本书，叫架构即未来。。。看着看着，怎么感觉。。。跪着即未来。。。你品，你细品。。。

    不要问我脑子天天在想啥。。。我根本就没有脑子，哈哈哈。。。先买后开输赢天定死而无怨。。。既然是咸鱼，就不要给自己加戏，毕竟。。。咸鱼翻身还是咸鱼。。。