结构糟糕的架构会有什么样的影响?

由于工作内容的原因，我在两家公司的工作中主持并经历了十多次代码和架构重构。 我简单说一下我对重构的一些经验和思考。

关于重构

首先，重构面临的背景是相似的。 程序员编写最基本的代码，就是为了快速完成需求并上线。 在功能不断扩展的过程中，通过打补丁的方式扩展代码，也会面临开发人员的变更和辞职。 渐渐地，代码会变得越来越臃肿，难以维护。

糟糕的架构会产生哪些影响？ 首先是开发效率的降低。 在糟糕的架构下添加新功能会受到之前代码的影响。 可能会出现意想不到的变化和问题，开发调试时间会大大增加。 增加; 其次，故障率增加。 在低质量的代码中，总是容易隐藏许多不易发现的陷阱，从而成为失败的隐患； 同时，架构也会大大降低完成度要求，使得精心设计的目标，由于架构限制或者性能原因，只能完成80%甚至更低。

重构要解决的问题

重构不能凭空进行。 它必须解决一个问题。 一般来说，重构需要解决的问题包括以下几个。

结构差。 相信很多程序员都有过接手别人代码后摸不着头脑的经历。 一个文件超过5000行，一个函数超过3000行。 面对这样的代码，想要修改并继续开发是非常困难的。 一件非常困难的事情。

安全风险。 很多代码只是为了快速完成功能，而忽略了很多潜在的安全风险，比如内存管理、异常处理、模块接口等。有些地雷如果不扫除，迟早有一天会爆炸。

性能问题。 对于很多大型服务来说，更高的性能可以节省大量的服务器成本。 性能问题主要是要找到核心问题。 有些问题出在架构上，但大多数问题出在代码上。

功能扩展。 有些模块在最初设计时只是为了实现一些非常基本的功能。 随着产品功能的不断增强，被赋予的功能越来越复杂。 在一定程度上，它们需要进行重构，以使其能够完成新分配的任务。 。

协同开发。 很多时候，一个大系统往往需要多人共同开发。 如果这些人需要修改同一个类甚至同一个函数，往往会发生冲突，代码集成往往会出现更多问题。 这时候就需要一个好的架构来支持多人的共同开发和修改。

模块调试。 在一个大的系统中，往往有很多相互关联的子模块。 如果某个模块的调试需要启动整个大系统，或者会受到其他模块稳定性的影响，效率是很低的。 重构建立调试层或者开发调试工具是更好的选择。

模块复用。 有时，多个系统或算法可能会使用子算法和子模块，很多公司在不同的项目或模块中重复开发具有相同功能的子模块是很常见的。 很多时候，抽象一些通用的部分可以让这部分变得更好、更精确。 综合来看，往往能够极大的提高开发效率和效果，往往还能够优化算法性能。

算法使用不当。 有些模块使用了不合适的数据结构或相关算法，导致性能或效果出现问题。 在这种情况下，甚至需要推回原来的架构，重新设计算法和数据结构，以达到尽可能最好的匹配效果。

承载能力不够。 有些系统有自己设计的容量，比如即时访问量、同时在线人数等。 很多企业从小到大都经历过这样的情况。 当超过一定程度的时候，很多时候就不能简单地通过增加服务器来解决了。 有时架构需要重新设计。 就像12306一样，因为架构问题，很难承受同时在线的高人数。

重建经验和感受

重组时，第一个困难是如何通过领导力考验。 很多领导者都要背负产品指标和任务，大多数人更关心的是能实现多久。 重构，在很多时候，可能就是“吃力不讨好”的代名词，因为在大多数情况下，无法帮助领导者完成目标。 在这种情况下，如何获得领导的支持就显得极为重要。

对于重构，一种方法是将重构与某些技术或产品指标联系起来，比如完成新产品、改善效果、提高性能等，这相当于重构是和其他改进一起上线的。 这样的话，就可以比较顺利地完成重建了。

而如果纯粹为了架构的合理性而重构，我们需要说服领导为什么原来的架构会降低开发效率，新的架构能够带来哪些改进。 我们必须让领导明白，这可以带来真正的长期利益，无论性能、效率、安全性等，而不仅仅是“看着不顺眼”的重构。

如果团队中有一定数量的人，就可以分一部分去开发新的架构，另一部分去改进现有的架构，这样短期和长期的目标都不会被耽误。 这时候值得注意的是，无论从代码还是设计角度，现有的东西都要被复用，而不是新架构上线后就被废弃。

如何进行渐进式改造也是很多建筑师需要思考的问题。 也就是我们不用一次重构半年、一年，而是可以按月快速迭代，这样就能快速看到效果，并小范围投入使用。

不管怎样，一定不能为了重构而重构，或者因为对前人的代码不满意，或者因为自己有技术完美主义。 最重要的是确定要解决的实际问题。 这时候重构可以带来开发效率的提升。

在重建的过程中，还需要设计新的建筑，有一定的远见，否则很容易出现新建筑、新新建筑、新新新建筑之类的东西。 另外，还需要尽可能增强代码的复用性，使得模块能够很好地应用在任何架构中。 当然，这需要根据具体情况具体分析。

在重构时，尽量不要有技术完美主义。 很多时候，用最成熟的解决方案和最简单的架构模型来实现所需的功能，一般会更加“简单可靠”。 有时架构过于复杂，会淹没焦点，因为所有架构都是服务于功能的。 同时，尽量不要使用很多应用不广泛的前沿技术，因为其中很多可能在开发和部署过程中遇到意想不到的问题，减慢开发速度，影响上线结果。

另外，作为重构的负责人，必须密切关注代码开发流程，随时提供指导。 一般来说，不要相信写出糟糕代码的人只要稍加指导就能写出漂亮的代码。 我曾经有过将一个非常大的类按照功能拆分成模块的经历。 设计好架构和各个子模块后，让团队成员进行开发。 开发完之后看代码我就抓狂了。 将模块进行拆分，为每个功能创建子类，通过主类调用子类，但每个子类都将主类作为友元。 然后调用主类中的成员变量和函数。 再次重构此类代码是不可避免的。 这给我的教训是，重构工作必须认真完成，迭代过程中的代码检查也是必不可少的。

好习惯从头开始

当然，重构再好，也是一种推倒重来的方式，浪费时间。 根据我的经验，其实大多数重构都是可以避免的。 对此，需要从以下几个方面进行改进。

良好的编码风格和良好的习惯往往很难自然形成。 他们通过在工作中不断接触新事物而得到更大的发展。 许多领导者希望员工将所有的时间都花在项目上，并不断推动更多的工作。 事实上，他们正在短跑中进行长跑，很容易出现体力不足的情况。 而在微软的经历也让我感受到了成为潮流人士并逐渐成熟的过程。 后来，即使我在搜狗团队工作太忙，我也会尽力检查每个团队成员的代码并帮助其他人。 为了改进。

最初的架构设计也非常重要。 建筑设计能否一次性完成还很难说。 但我相信，一个好的架构会比一个粗糙的设计更长久。 而一个好的架构能够考虑到未来可能扩展的规模和功能，为未来的开发留下良好的接口。 同时，里面的各个模块也非常有序。 即使大框架需要修改，也只是一个架子，原有的子功能、子模块可以得到很好的复用。

其实很多时候，代码开发一段时间后并不需要重构，写出一个好的架构并不是那么困难。 更重要的是，需要的是不断提高程序员的自身修养，不仅是能力上，更是态度上。 不要在开发初期只考虑省事，而不考虑一段时间后会发生什么。 一个好的架构对于以后的开发和发展能够真正做到“事半功倍”。

最后我们来看一个关于扁鹊的故事：

魏文王曾向名医扁鹊请教：“你们兄弟三人都擅长医术，谁最好呢？” 扁鹊说：“大哥最好，二哥较差，我是三人中最差的一个。” 魏王疑惑道：“请详细介绍一下。”

扁鹊解释道：“病未发作之前，大哥就治病了，当时病人并没有感觉有病，但大哥却开药祛除病根，难为他的医术了。”所以，他没有名气，只在我们中间。” 他在家族中很受尊敬。 我二哥在疾病刚出现的时候就治疗，症状不是很明显，病人也感觉不到疼痛。 二哥能用药治病，这让村民们以为二哥只是治病。 小病很有效。 我只有在病情很严重、病人痛苦极了、病人家属着急的时候才治病。 这时，他们看到我刺破经脉，用针放血，或者在患处涂毒以抗毒。 或者我可以进行大手术，直接针对疾病，使重症患者的病情得到快速缓解或治愈，所以我名满天下。”

扁鹊其实是一位非常优秀的重构大师，但是扁鹊的大哥才是大师中的佼佼者，就是因为他能把问题摆在前面，处理在前面，所以他才能永远保持健康！