自学架构设计的一个好方法，经验分享

来源：大飞码字

架构设计，讲起来，比较虚，不像算法和代码。你写了一段巧妙的代码，编译，运行，如果最终结果是正确的，那就是正确的。

但架构设计就不同了，你就算自己脑子YY了一个架构出来，好不好，有时候自己还真不好判断，只有真正实施了，才能知道结果。

于是出现了一个尴尬的情况，想参与架构设计的同学需要先有架构的经验，但架构经验又要来自实际的项目，事情好像陷入了死循环，无法破局。

这里我给大家分享下，一个自学架构设计的方法： 看开源项目的源代码

我从大学开始看开源项目的源代码，看得比较多的是linux 内核的源码，也看过mysql , C++ stl ,boost 库等的源代码。

我个人的感觉是，收益特别大，尤其是对于架构上的收益，这个方法是单纯的看书和资料，所无法比拟的。

看源代码带来的实际收益

如果，你看懂了一个开源系统的源代码，你会知道，这个开源系统的整体架构，实现的细节，一些精妙的设计之处，你都会接触到。

这些东西会对自己产生潜移默化的影响，就像写文章的人，要多看书一样。时间长了，可以帮你形成一种架构设计的 “直觉”。

写代码是工程实践，而架构师有时候更像一个艺术家，很依赖于架构师的经验和直觉，多看优秀开源系统的代码，更能直接地吸取这种经验和培养这种直觉。

除了经验和直觉上的积累，看源代码还带来另外一个直接的收益。

比如，你是做linux 服务器开发或维护的，如果你看过不少linux 内核的代码，那你对 linux 里面很多具体的实现机制肯定是有深入了解的。

这部分的知识和经验，绝对是你工作中强有力的武器，你在设计和维护服务器的时候，都可以做的比一般人更好，而且很快会成为团队内的linux 专家，技术地位杠杠的。

同理，如果你做的是java 服务器的开发，你看过Java虚拟机的源代码, 做出来的设计和写出来的代码，肯定会考虑到更多的实际情况，性能和稳定性都会更好，你同样很快会成为团队内部的虚拟机专家。

客户端和前端的同学也一样(android系统的实现机制，浏览器，V8引擎的实现机制等)。

那怎么来看源代码会比较好呢，下面来说说

看之前先要搞清楚整体架构

看源代码前，先要通过对应的书籍和文档，搞清楚整体的系统架构，然后，再开始进入代码。

是的，从源代码里面是很难看出整体架构的，书和文档容易的多。

如果你一开始就扑进代码堆里，你很快就会感觉沮丧了，你会找不着北。

我一开始看源代码的时候，也是一上来就扑到代码堆里，看得云里雾里的，看得很吃力。甚至有时候，一个子系统的入口，都要找个半天，有时候出现两个类似的，还不能确定是哪个。

后面，我发现很多比较知名的开源系统，除了有开源的代码，还有不少的书籍和文档。所以先通过书籍和文档，尽量的搞懂系统的设计，再进入源代码，会有事半功倍的效果。

比如，我去看ext4源代码的时候， 我用尽google, 百度上的资源，先中中文的看起，看完看英文，当我确定，基本理解整个的设计，包括磁盘布局，数据结构，大体的数据流程，关键设计点后，我才会开始去看代码。

因为我体会到，整体的架构，如果你看文档的时候看不懂，你在看代码的时候也是很难看懂的。

你或许会说，如果看书籍和文档就搞懂了系统，那还看源代码干嘛。

书籍和文档能让你对系统有个整体的认识，让你知道，这个系统有那几个部分，每个部分是怎么衔接的，给了你一个代码的蓝图。

带着这个蓝图，你看完代码，才能真正知晓和体会到，系统设计的权衡和精妙之处，才不会有云里雾里的感觉。

如果你只看了书籍和文档，那就像是有了一个蓝图，但没有带着这个蓝图去寻找宝藏，始终是空中楼阁。

看源代码时，需要关注的点

看源代码的时候， 从整体到细节的，你可以关注这些。

你可以关注，系统的整体设计，比如系统分了几层，每层由几个部分组。

你可以关注，层次之间数据的交互方式，最常见的当然是接口的方式，但也有的系统会采用队列，共享内存等的方式。

你可以关注，各个模块间接口的设计，包括接口的类型，接口的入口参数和输出结果。

你可以关注，系统里面核心的数据结构，可以关注代码层面的设计模式。

你可以关注，代码里面，一些精巧设计的部分。比如 linux 内核里面，红黑树的实现，用C宏实现的泛型链表操作等，你会惊叹还能这么玩。

你还可以关注异常处理流程等。

看源代码其实是很有意思的事情，自己要带着问题和思考去看，你会发现有一片新的天地，这个也是看代码带来的一大乐趣了。

学会 “囫囵吞枣”

刚开始，看一个系统的源代码的时候，你会想要全部搞懂。

你一直地看，觉得终于看到一个函数的尽头，最后一句的时候，突然出现一个新的入口函数，你点击去，发现是”新大陆“，你崩溃了。

刚开始看源代码的时候，经常遇到这种挫败感，总感觉看不透，很多细节不懂，后来学会 “囫囵吞枣” 的方式，就消除了这种感觉。

看不懂的也不深究，跳过，看能看懂的。后面，来来回回地看，有时，隔了一段时间，刚好有接触到，就再看，最后还是能看懂很多。

其实看源代码不能抱着大而全的意识去看，而应该抱着，看懂一点是一点的意识去看，你会有完全不一样的感觉。

你没了那种 “大而全” 带来的压力，取而代之的是点滴收获的累积，你看得过程也轻松了很多。

因为源代码不是一般的教科书，你不需要“大而全”，能吸收多少，是多少。

新手和老手的区别

这里还是有些区别的，对于新手，建议是看完文档后，一定要去看源代码，要不就是 “隔靴挠痒”，最后收获一定不大。

但如果是经验丰富的老手，就要区分看待了。

比如一个实际参与过数据库系统设计和实现的老手，在看mysql 的时候，很多部分，他可能看完文档和书籍，心里就已经有各种具体实现甚至是实现细节了，这时候，他确实可以不用再去看源代码。

当然，这个是基于，他已经有这部分丰富的实践经验的基础上。

但对于没有经验的新手或经验不足的同学，还是建议看源代码的，要不就会有一种”飘“的感觉。

关于时间

看开源项目的源代码，是挺花费时间的事情，所以这块，也需要做比较好的安排。

如果你是学生，没有太大的学习和项目压力，你可以根据自己的兴趣选择喜欢的开源项目。

当然，尽量选择知名的开源项目，因为知名的开源项目，它整体的设计，编码等都是被实际生产环境验证过的，是正真的好项目，就像看书要看好书一样，看开源的代码，也要看好的开源代码。

如果你已经工作，时间不太充裕，那尽量选择跟自己工作相关的开源项目。比如，你是做服务器开发的，你每天都要跟数据库打交道，进行CRUD，那你可以考虑看mysql的书籍和mysql的源代码。

一来，可以学习到mysql在这部分的架构和设计，积累经验和培养“直觉“; 二来，所学到的这部分的知识可以直接的运用到工作之中。

比如，你在做SQL语句优化的时候，如果，你知晓，mysql内部的实现机制，那你做起优化来，肯定要顺很多很多，说不定，不久之后，你就成为了，你们团队的mysql专家了。

如果时间比充裕，可以大块，大块的看。如果时间比较吃紧，就具体的某个部分，结合书籍和文档来看。

结尾

对于项目经验不是很丰富的同学来说，如果想在工作外的时间，积累架构经验，培养架构“直觉”，结合书籍文档，看开源系统的源代码是个不错的方法。

我看了不少开源系统的源代码，确实收益颇多，很多的常用架构，设计模式，方法，实际实现的方式，都可以通过看开源系统的源代码获得，而且消除了只看书或文档，带来的云里雾里的感觉。

有兴趣的同学不妨试试。

（完）