做架构也得讲武德

这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「169」篇原创敬上

大家好，我是Z哥。今天分享一篇对「架构」这件事的随想。

我想，做「架构」是每个热爱技术的技术人在不断追求想进入的领域。但是很多人可能工作了很多年也没能真正参与到做架构这件事上。

所以，很多人对做架构这件事的感知停留在网上很多大牛分享的文章里。

但是，如果你只是看网上的文章其实对架构的理解会非常容易跑偏的，主要原因有两点。

第一点，世界是在不断发展和迭代的。技术也是人类文明的一部分，所以自然也会随着时间的推移不断进化。

而很多讲架构的文章喜欢和新技术挂上钩，一个没用到新技术的“架构”，会让很多人觉得有点out，缺乏吸引力。

但是新技术的推出，要么是用来解决过去无法解决的问题，要么是可以提高当前解决问题的效率。正如当前的你在20年前做程序员，基于当时的编程环境，开发效率肯定不如现在，这是毋庸置疑的。

也正因为如此，每一项新技术的出现，背后必然对应着一个典型的问题场景。能最大化发挥这项新技术价值的地方也应该是这个场景。

如果我们仅仅停留在这项新技术本身去考虑它有什么用，那么就很容易就会陷入到“拿着锤子找钉子”的情况里。特别是出于对「架构」的崇拜，“我怎么才能用上这个技术”会成为脑海中第一重要的目标。

第二点，不管是创造新技术的人还是分享新技术使用经验的人，对他们来说肯定得对外展示新技术好的一面。如果写不好的一面，这不是拆自己台么，或者担心表现出自己不会用、丢脸么。

如果你有心的话，当你在网上搜某个技术的相关资料的时候其实很容易观察到这个现象，讲优点的文章比讲缺点、讲遇到什么坑的文章多得多。

这会造成的影响就是过度拉高“旁观者”对新技术的预期，认为它是很牛逼的，能解决很多问题。

那么正确对待「架构」的态度应该是什么呢？

我根据我自己做架构5年踩坑的经验总结了以下3点。希望能帮助你少踩甚至是避开我踩过的坑。

/01  回到现实的问题中/

任何技术应该都只是解决问题的可选项之一，并没有所谓的唯一选择。只有你回到的现实中，从实际的问题出发去考虑，你才能规避掉你对某项技术所带的偏见。（当然，提前是你还得对每项技术有基本的了解）

比如，之前我团队里有个小伙伴觉得Saga模式非常酷，他认为用它来实现数据的写操作又快又准，还能大大降低资源竞争问题，是所有项目应该考虑的第一选择。于是，他在一个新项目中用上了。

但是，最终系统上线后，页面操作的响应的确挺快，但是由于数据的滞后产生了一系列问题，让系统使用者苦不堪言。

/02  大多数时候，「减」都比「加」好/

我问你两个词语，你知道「简单」和「容易」的区别吗？

在我看来它们有很大的区别，我的理解是，「简单」是形容事物的，「容易」是描述做一件事的过程。所以，我们做架构这件事，要追求的是「简单」而不是「容易」。虽然很多时候「容易」会让你用的时候觉得很「简单」，但那不是真的简单，最多算得上是局部的“简单”。（这段话有点绕，细品一下应该还是很容易理解的）

所以，想要架构变得「简单」，自然是做减法比做加法好。但是现实中，往往相反，更多人乐忠于增加什么新技术，引入什么新技术。毕竟做加法有可能不用考虑“历史问题”，而要做减法不得不考虑“历史问题”，很明显前者更「容易」。

/03  时刻保持风险意识/

大多数情况下，后续暴露出风险的地方大多数是一些非功能性的点。比如，数据经常出错，访问量一大数据同步就延迟的厉害，甚至宕机。

这些点说起来简单，但是需要考虑的细节非常多。类似于「木桶原理」，只要你的整体架构中有一块短板拖了后腿，大大小小的问题就会接踵而来。

更加麻烦的是，这些问题还不容易解决，甚至需要做大量的推倒重新设计才能解决。

虽然说，不管怎么样依旧无法100%规避风险，但是时刻带着风险意识问自己：“这里这样设计可能会有什么问题？”必然会大大降低风险系数。

另外，对待已经察觉到的潜在风险绝对不能草率，认为未来不一定会发生，先将就着。规模越大的系统，越符合墨菲定律所提到规律——“凡是可能出错的事有很大几率会出错”，而且时间会大大提前。

暂时就想到这么多，这个话题其实很大，后续有新的思考再分享给大家一起讨论。

好了，总结一下。

这篇呢，Z哥和你分享了我对架构这件事的随想。

首先，对待一个陌生的技术，预期不能过于乐观。因为以下两点会潜移默化地让你产生偏见。

对自己不了解的技术的崇拜感。

你能查到的对外分享讲优点的远大于讲缺点和坑的。

对待架构这件事我给出的3个建议是：

回到现实的问题中。

大多数时候，「减」都比「加」好。

时刻保持风险意识。

希望对你有所启发。

架构是“平衡”的艺术，祝你早日找到你的“平衡感”。