10年架构师感悟：从问题出发，而非技术( 二 ) _架构师

实际上在架构领域，大家对这点也是有共识的。比如下图中这个 Micro-Kernel 的架构模式来自《面向模式的软件架构》的第一卷，它一大特点就是有比较好的可扩展性，同时通过 Plugin 之间的隔离，能够提高系统的可用性。

文章插图
“简单"并不容易
在我看来，我最近的第四个重要感悟是：“简单”并不容易。许多架构师都会强调保持简单，但很多时候我们会混淆简单和容易。简单是指简洁、清晰，而容易是指易于实现、理解或操作。我们应该努力保持简洁，而不是追求轻松的实现。
正如乔布斯所说，简单有时比复杂更难，因为它需要对问题、事物的深入研究，才能找到真正简洁的解决方案。简单实际上是一种巧妙的设计和思考。
举例来说，布隆过滤器就是一个简单而高效的重复数据过滤算法，它巧妙地解决了一个问题。如果想要使某件事情变得简单，就需要进行大量深入的工作。例如，简化架构很大程度上取决于我们对技术、开发过程以及不同业务场景的深入理解，而不仅仅是架构本身的设计容易与否。
因此，保持简单并不容易，它需要我们深入理解问题的本质，并找到最优雅、最有效的解决方案。
举个例子，我们来回顾一下软件生命周期中各个阶段的成本消耗占比。

文章插图
可以看到，在整个软件生命周期中，成本消耗最高的并不是设计、编码这些阶段，而是维护阶段。也就是说，如果你让维护变得简单，这会是最有性价比的。
五、永远不要停止编码
在我看来，我最近的第五个重要感悟是：永远不要停止编码。这一点非常重要，特别是对于一个架构师来说，要牢记自己始终是一名程序员。作为架构师，我们可能设计了一个高层次的架构，但实际上，代码才是软件的最终实现形式。每个程序员在架构落地的过程中的实现，都可能影响最终的架构呈现。
此外，如果你停止编码，最大的影响不是技术上的滞后或代码编写速度变慢，而是你可能会逐渐失去对编程的敬畏之心，忘记作为程序员的体验，特别是编码过程中的那些挑战与痛苦。你可能会陷入一些不切实际的幻想，做出一些不切实际的设计，这才是最大的问题。
我们都熟悉 JAVA 的创始人 James Gosling ，在亚马逊担任杰出工程师的职位，相当于高级副总裁，但他依然坚持编码。他每年编写的代码量是惊人的，常常超过 10 万行。这个事实告诉我们，无论职位有多高，作为一个技术人员，始终保持对编码的热爱和投入是至关重要的。
六、风险优先
在我看来，我最近的第六个重要感悟是：风险优先。
让我们先思考一个问题：为什么要进行架构设计？在我看来，架构设计的主要目的是转化、降低、甚至避免整个开发过程中的风险。作为架构师，我们的一个主要责任就是在项目的早期阶段识别出系统可能存在的风险，并通过我们的设计来转化、消除这些风险。
我们经常提到的原型方法或者架构切片的快速迭代方式，实际上也是在早期尽量测试风险，评估我们的架构是否能够解决相关问题，特别是那些非功能性需求的实现风险。这些风险往往不像功能性需求那样容易在项目初期被发现，但是修正它们的成本通常比修正功能性需求要大得多，甚至可能导致整个项目的失败。
比如敏捷开发，很多人认为敏捷开发只是更快地开发出一个产品，然后快速地将其交付到市场上，但这只是敏捷的一部分。另一个很重要的方面是，如果一个项目注定要失败，那么就要尽早地让它失败，绝对不能将风险留到最后。这也是敏捷方法的一种体现。
在这里，我想推荐一本书《Just Enough Software Architecture（恰如其分的软件架构）》。这是一本非常流行的架构书籍，强调了架构设计的目的是为了化解软件实现中的风险。如果项目中的所有风险都可以通过未来的重构来解决，那么你根本就不需要进行架构设计，直接等待重构即可。这也是我非常赞同的观点：风险优先。
从“问题”开始，而不是“技术”
我最近的第七个重要感悟是：从“问题”开始，而不是“技术” 。