朋友们好，我是bobo。
好久不见，十分惦记！
本日和朋友们一起来聊一聊【架构】的那些事，考试测验用大口语唠唠嗑！
第一部分：没有架构行弗成？
开始本日的谈论之前，咱们先来看一个故事：
大型系统的实质问题是繁芜性问题。
互联网软件，是范例的大型系统。
数百个乃至更多的微做事相互调用/依赖，组成一个组件数量大、行为繁芜、时候在变动当中的动态的、繁芜的系统。
因此，软件工程师们常常自嘲，“when things work, nobody knows why”。
如果我们只是写一段独立代码，反面其他系统交互，每每设计上哀求不会很高，代码是否易于利用、易于理解、易于测试和掩护，根本不是问题。
而一旦碰着大型的软件系统，如互联网分布式运用或者企业级软件，我们常常陷入繁芜度陷阱。
怎么办理繁芜度的问题？
是的，答案便是架构！
想起一个笑话：
繁芜系统的掩护是一种玄学。
当一个大型软件系统涌现bug的时候，最好的办理办法是什么？
是啥也不要做，赶紧去烧喷鼻香拜佛，大概它自己就好了。假如动了啥，还不知道会造成什么更加毁灭性的后果。
啥意思，意思是压根就不知道问题出在哪！
办理问题的第一步是找到问题。
要想找到问题，最最少得要有点脉络可寻——这时候，架构便是那个脉络。
就像我们看高德舆图。如果给你一堆全国各个县的舆图，你怎么找？一团乱麻。
如果是按照“全国-省-市-县”这个的构造，就很清晰了，很随意马虎就定位到您想要的地方。
这个构培养是架构。
如果是一个大略的软件，一个小企业，没有架构，也没啥问题。
但是，如果软件越来越繁芜，企业的业务越来越繁芜，没有架构可能便是一场灾害了。
由于，繁芜度这个事是呈指数趋势而不是线性趋势增长的。
越是大型系统，越须要大略性。
架构便是解构繁芜度，简化问题的抓手。
第二部分：怎么做一个完美的架构？
bobo的答案是：没有完美的架构。
怎么来理解？先问一个问题：
软件是建造出来的，还是“成长”出来的？
BUILT vs GROWN，that is the problem.
软件不是建造出来的，乃至不是设计出来的。软件是“成长”出来的！
这个说法初看上去和我们平时的认识彷佛不同。
我们常常谈软件架构，架构这个词彷佛蕴含了一种建造和设计的意味。
然而，对付软件系统来说，我们必须认识到，架构师设计的不是软件的架构，而是软件的“基因”，而这些基因如何影响软件未来的形态则是难以预测，无法完备掌握。
所谓建造和“成长”的差异在哪里？
一个繁芜的软件系统，确实很像一个繁芜的建筑物。但是把软件比作一栋摩天算夜楼却不是一个很好的比喻。
缘故原由在于，一个摩天算夜楼无论多么繁芜，都是事先可以根据设计出完全详尽的图纸，按图准确施工，担保质量就能建造出来的。
然而现实中的大型软件系统，却不是这么建造出来的。
软件的动态“成长”，更像是上图所画的那样，是从一个大略的“构造”成长到繁芜的“构造”的过程。
伴随着项目本身的发展、研发团队的壮大，系统是个逐渐成长的过程。
或者换一个主体，把“软件”换成“业务”，也是同样的道理。
业务也不是一开始就能设计出来的，还是逐步“成长”出来的。
以是，架构也不可能完美。由于架构本身只是现实的“投影”，业务在“成长”，架构也须要“成长”。
总而言之，bobo以为对待架构这个事要有【辩证的思维】。
一方面，架构不可能生而完美，一开始可以做的大略点，关键是要做起来。
另一方面，架构须要不断完善，不要指望一劳永逸，不断迭代、不断成长才是正道。
要觉得文章还不错，朋友们请随手点个【赞】和【在看】吧，能【讴歌】一下请bobo喝杯咖啡就更感谢啦！
您的支持便是我不断输出的动力
