作架构也得讲武德

这里是Z哥的我的公众号程序员

每周五11：45 按时送达编程

固然了，也会时不时加个餐～架构

个人第「169」篇原创敬上分布式

你们好，我是Z哥。今天分享一篇对「架构」这件事的随想。单元测试

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

因此，不少人对作架构这件事的感知停留在网上不少大牛分享的文章里。大数据

可是，若是你只是看网上的文章其实对架构的理解会很是容易跑偏的，主要缘由有两点。设计

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

而不少讲架构的文章喜欢和新技术挂上钩，一个没用到新技术的“架构”，会让不少人以为有点out，缺少吸引力。开发

可是新技术的推出，要么是用来解决过去没法解决的问题，要么是能够提升当前解决问题的效率。正如当前的你在20年前作程序员，基于当时的编程环境，开发效率确定不如如今，这是毋庸置疑的。

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

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

第二点，不论是创造新技术的人仍是分享新技术使用经验的人，对他们来讲确定得对外展现新技术好的一面。若是写很差的一面，这不是拆本身台么，或者担忧表现出本身不会用、丢脸么。

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

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

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

我根据我本身作架构5年踩坑的经验总结了如下3点。但愿能帮助你少踩甚至是避开我踩过的坑。

/01 回到现实的问题中/

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

好比，以前我团队里有个小伙伴以为Saga模式很是酷，他认为用它来实现数据的写操做又快又准，还能大大下降资源竞争问题，是全部项目应该考虑的第一选择。因而，他在一个新项目中用上了。

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

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

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

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

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

/03 时刻保持风险意识/

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

这些点提及来简单，可是须要考虑的细节很是多。相似于「木桶原理」，只要你的总体架构中有一块短板拖了后腿，大大小小的问题就会接踵而来。

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

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

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

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

好了，总结一下。

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

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

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

但愿对你有所启发。

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