我一般下班会遇到基础服务的小伙伴聊聊天，我说话很少，就喜欢听听别人聊点什么，他跟我聊了几天，我发现问题是现有商品代码已经不足以支持业务的快速迭代，因为冗余其他东西太多了。比如说一个毛胚商品，然后它也快速的加上其他属性，变成一个加工品。但是现在场景变成了它就是一个加工品，你想拆成其他加工品，很困难，就是字段冗余到商品表里头了。

这个时候到架构已经不适合业务快速迭代了，需要重构，大破大立，还需要大佬牵头。review狭义上是代码层发现问题，如果你从一线同学那里听到的东西，能发现问题，也是一种review。

架构师不止规范，需要深度

需要什么深度呢？

从一个做需求的点看，从需求理解，这个是业务深度，从设计文档上，严谨程度，扩展性、风险点、可行性，设计深度。从开发阶段，coding，技术规范，技术功底，这个是技术深度。

跳出需求的点，从大的面来看，需求为了解决什么问题，不做行不行，业务价值在哪里？做了这一期还有后续吗，这是业务的前景。然后规划是怎样的，先从哪里入手，然后有木有计划去推进？这是思考的深度。

抽象的能力

大咖们如何评判优秀架构师？

里面反复提到抽象的能力，比如说逻辑、物理架构图，这个有助于你理解整个系统的调用关系，形成闭环，可以从全局的角度去理解，我当前做的需求在什么位置，为了解决什么问题。

再到通过问题看到本质，从技术方案看到实质。有一次一位同学跟我探讨DDD,跟我说防腐层不应该是这样写的，你只是用了策略模式去写，应该有个一个门面，然后后面是实现逻辑。我听到这里就明白他被绕进去了，DDD是一个思想，他幻化出来一些对应的框架，它的精髓是高内聚、低耦合。你说策略模式，能否将外部rpc调用分隔开呢？当然可以，它算不算防腐层呢？也算～

最近一次做代码优化的时候，我用了责任链的设计模式，将190行的代码，拆分成4个模块，每个类大概30行，当然190行包括换行。但是实际效果除了行数变少外，每个模块分工特别清晰，这个模块在处理特定的逻辑，当某部分有问题的时候，直接找到那个模块修改即可。（这就是高内聚的魅力）

抽象另一种体现：模块化

最近在牵头做账单，其实我也没做过，我就找了几篇大厂的文章看看，拿来吧你，哈哈

分为几个步骤，下载账单，解析账单，对账，差异处理（平账）。是不是瞬间有了几个模块，文件模块，包括上传、下载，解析文件对吧。然后是账单模块，可能会分成订单，还有一些退款的，然后是对账处理结果，属于对账模块，文件解析出来的东西跟账单对比，哪些是对的上的，哪些又是异常的，这个模块还有后续的处理结果，自动平账，或者人工处理。