大家是不是经常听人提到架构，朦胧中也会觉得这是个好东西，可落实到现实中，架构到底是个什么玩意儿？看个书又弄的高大上，错综复杂，忙绕无头绪。用大白话，用通俗方式，讲述简单而深刻的道理，便是我的方向。
管理学上有个名词，结构效率远远优于运营效率。
例如：一个大设备的生产，有10道工序（假设工序用时是均匀的），1人完整的装配完1台需要1天（10h小时），10人1天里每人装了1台，在每道工序上耗费的时间为1h。该人每天每道工序的装配水平就是1h的水平。他每天多加1h班在某道工序上，也不过在该道工序上是2h的水平。
现在改成流水线作业，10个人每人负责一道工序，10个人一起完成这一天总共10台的工作，这样1人1天（10h）对负责的工序重复了10次，试想一下，一个人一天在一道工序上重复了10遍和做了1遍相比，哪个更熟练效率更高？后者不用加班，每天就是10h的熟练程度。
前者靠加班提升，这是运营效率；后者靠分工的组织架构提升，这是结构效率。
另一个例子，一锅炉温度监测软件，在一个大程序架构里，A、B、C三位工程师均会用到温度参数，分别根据测量结果用于调节通风、送煤、报警。于是ABC分别各自编写了这几行并不复杂的程序。
A调试时，遇到了测量结果偶超出100度的问题，于是加了上下限判断干扰数据丢弃处理；
B调试时，遇到了前后两个测量时间相隔几秒但温度却差别很大，水温不应该出现的干扰情况，于是B加了温度变化率的判错功能。
C调试时，发现了一个50Hz工频干扰，于是加了50Hz陷波搞定。
图1
如上编程的话，三个人各有各的经验，却相互之间不能共享，当到了用户现场后，万一A遇到了B、C的问题，而A的代码里没有相应措施，是不是会带来召回或维修？通过ABC三人之间的交流来弥补各自的欠缺，管理效率上是不是也会有较大的漏洞？
如果将此软件架构改成图2的形式，单独设置ADC（）函数，A、B、C三位工程师分别调用该函数的功能，A发现超限，则反馈给ADC函数的编程人员，将上下限判断的功能加入ADC（）；B将温度变化率的判错功能、C将数字滤波的功能也都加入函数ADC（）。这样ABC三人的代码，每个人是不是都享受到了三个人的经验？
图2
再例如：一个硬件的大系统，外围有诸多的功能，中央控制单元用一个大型的MCU实现调度和控制（图3左图），可想而知，各个部分之间的时序分配、中断的交叉，对硬件设计师和软件设计师会有多少逻辑上的复杂需求；
改变一下思路，换成图3右图的架构方式，能独立出去的终端功能用独立的小型MCU实现，用一种“分散、自治、多元化”的设计思想，将一个强力中央单元的功能分散到诸多个诸侯国去，中央单元仅实现各部分之间的调度，将数据处理功能有各自单元独立完成。试想一下，软件调度逻辑和每部分的硬件难度是否可以大大降低。一个不太方便明说的示例，就是中美领导架构的对比，我们国家的高层领导的工作难度就比美国要难得多，原因是大事小情都得上面操心，而美国，联邦是联邦，各州是各州，分散了。是否与此同理？
图3
类似的事儿还有很多，比如DCDC电源种类的选择（并不是归一化就真的好）、晶振频率的选择、结构布局等等，从架构的角度去考虑设计方案，甚至有可能会颠覆曾经一直以为是宇宙绝对真理的三观。
架构的改善，带来的将是质的提升。但架构却又是一个“好人不愿干，差人干不好”，“干好了没人知道，干坏了也没人知道”的事儿，当然更多的是，做架构设计的人、被差的架构祸害的人，被好的架构荫庇的人，好多都还没意识到架构的价值和方法。
