Atitit 高级人员要看哪些源码 目录 1. Ati看过的源码 1 1.1. Ui类 1 1.2. Mvc类 1 1.3. 数据库类 1 1.4. 算法类 1 2. 看源码的意义 2 2.1. 一

Atitit 高级人员要看哪些源码

 

目录

1. Ati看过的源码 1

1.1. Ui类 1

1.2. Mvc类 1

1.3. 数据库类 1

1.4. 算法类 1

2. 看源码的意义 2

2.1. 一、解决问题(BUG) 2

2.2. 二、知其所以然 2

2.2.1. 三、学习 2

2.2.2. 四、改造 2

2.2.3. 五、借鉴 2

2.3. 六、面试有加成 2

3. 何看源码 3

3.1. 先看文档，整体把握 3

 

1. Ati看过的源码
   1. Ui类
   2. Mvc类
   3. 数据库类

 

Mysql URL 解析源码 ，方便简化配置

Sql 解析源码

Db连接池源码，得到db url

Jpa jpql源码

 

1. 1. 算法类
2. 看源码的意义

看源码只是一种方法、手段，而不是目的。我也曾经给自己制定过“阅读xxx源码”的目标，现在看起来真的很蠢，一点不smart（specific、measurable、attainable、relevant、time-bound）。

只有搞清楚了阅读代码的目标，才能有的放矢，抓住重点，高效达成任务。

看源码的意义总结起来包含但不限于以下几点：

1. 1. 一、解决问题(BUG)

只要是代码，就会有bug，只是说bug的多与少、深与浅罢了。现在大家都喜欢发布、使用开源项目，不同的开源项目社区成熟度、代码质量又会有较大的差异，遇到bug就不足为奇了。

当然，遇到bug肯定是先在网上搜索是否有类似的问题，一般可以在google、Stack Overflow、项目的issues里面有对应的关键词搜索。如果搜不到，那么就只能看源码解决了

1. 1. 二、知其所以然

我在[如何学习新技术、团队技术选型时要注意些什么][Link 1]里面提到过，如果我们需要将一个开源项目用到自己的项目中，那么就必须了解这项项目的优缺点，并深知原理，对部分细节（尤其是项目的优势、feature）进行深入研究。

如果是成熟的开源项目，遇到问题也许能google到很多答案；但如果是一个处于快速发展中的开源项目，多了解其架构、核心原理，也能帮助快速定位问题。

另外，有的项目文档可能不那么丰富，但又不得不使用，那么如何以正确的姿势使用呢？也得参考源码

1. 1. 1. 三、学习

看源码也是一种不错的学习方式（虽然不一定不是最佳的方式），尤其对于比较优秀的开源项目，能让人大开眼界。

1. 1. 1. 四、改造

一般来说，我们刚开始仅仅是使用一个开源项目，但随着使用的深入，会发现一些自己需要的功能并没有很好的支持，向项目组提的issues也可能得不到快速的响应，这个时候就要自己开分支，改代码，加功能了。

当然，比较好的是将自己分支比较好的新feature 给原项目提merge request，反哺开源项目，比如阿里的[Blink][]

1. 1. 1. 五、借鉴

他山之石可以攻玉，如果有需要重新开始自己造轮子，那么参考一些已有的、优秀的轮子肯定是有好处的。

1. 1. 六、面试有加成

这一点，不应该作为我们阅读源码的出发点，但是确实能在实际中对找工作、面试有加成，算是副产品吧。

1. 何看源码

看源码的目的很大程度上影响了看源码的方式、需要阅读的代码的范围。比如说，如果是为了修一个线上bug，那么阅读代码的范围就紧紧围绕bug本身；而如果是为了了解某个分布式算法，那就需要按大量的、可能运行在不同节点（进程）上的代码，了解其交互原理、工作流程。

下面说一些通用的方法。

1. 1. 先看文档，整体把握

一般来说，文档是对代码的高度凝练，一个高质量的开源一般会包含tutorial、specification、API reference等documents，通过选择性的略读、精读这些文档，就能大致了解项目的整体架构、设计原则

正确的路线是通过文档去认识这个项目，然乎通过阅读代码去验证文档、深入细节，而不是通过直接啃源码来了解这个项目，以偏概全。

Atitit 高级人员要看哪些源码

 

目录

1. Ati看过的源码 1

1.1. Ui类 1

1.2. Mvc类 1

1.3. 数据库类 1

1.4. 算法类 1

2. 看源码的意义 2

2.1. 一、解决问题(BUG) 2

2.2. 二、知其所以然 2

2.2.1. 三、学习 2

2.2.2. 四、改造 2

2.2.3. 五、借鉴 2

2.3. 六、面试有加成 2

3. 何看源码 3

3.1. 先看文档，整体把握 3

 

1. Ati看过的源码
   1. Ui类
   2. Mvc类
   3. 数据库类

 

Mysql URL 解析源码 ，方便简化配置

Sql 解析源码

Db连接池源码，得到db url

Jpa jpql源码

 

1. 1. 算法类
2. 看源码的意义

看源码只是一种方法、手段，而不是目的。我也曾经给自己制定过“阅读xxx源码”的目标，现在看起来真的很蠢，一点不smart（specific、measurable、attainable、relevant、time-bound）。

只有搞清楚了阅读代码的目标，才能有的放矢，抓住重点，高效达成任务。

看源码的意义总结起来包含但不限于以下几点：

1. 1. 一、解决问题(BUG)

只要是代码，就会有bug，只是说bug的多与少、深与浅罢了。现在大家都喜欢发布、使用开源项目，不同的开源项目社区成熟度、代码质量又会有较大的差异，遇到bug就不足为奇了。

当然，遇到bug肯定是先在网上搜索是否有类似的问题，一般可以在google、Stack Overflow、项目的issues里面有对应的关键词搜索。如果搜不到，那么就只能看源码解决了

1. 1. 二、知其所以然

我在[如何学习新技术、团队技术选型时要注意些什么][Link 1]里面提到过，如果我们需要将一个开源项目用到自己的项目中，那么就必须了解这项项目的优缺点，并深知原理，对部分细节（尤其是项目的优势、feature）进行深入研究。

如果是成熟的开源项目，遇到问题也许能google到很多答案；但如果是一个处于快速发展中的开源项目，多了解其架构、核心原理，也能帮助快速定位问题。

另外，有的项目文档可能不那么丰富，但又不得不使用，那么如何以正确的姿势使用呢？也得参考源码

1. 1. 1. 三、学习

看源码也是一种不错的学习方式（虽然不一定不是最佳的方式），尤其对于比较优秀的开源项目，能让人大开眼界。

1. 1. 1. 四、改造

一般来说，我们刚开始仅仅是使用一个开源项目，但随着使用的深入，会发现一些自己需要的功能并没有很好的支持，向项目组提的issues也可能得不到快速的响应，这个时候就要自己开分支，改代码，加功能了。

当然，比较好的是将自己分支比较好的新feature 给原项目提merge request，反哺开源项目，比如阿里的[Blink][]

1. 1. 1. 五、借鉴

他山之石可以攻玉，如果有需要重新开始自己造轮子，那么参考一些已有的、优秀的轮子肯定是有好处的。

1. 1. 六、面试有加成

这一点，不应该作为我们阅读源码的出发点，但是确实能在实际中对找工作、面试有加成，算是副产品吧。

1. 何看源码

看源码的目的很大程度上影响了看源码的方式、需要阅读的代码的范围。比如说，如果是为了修一个线上bug，那么阅读代码的范围就紧紧围绕bug本身；而如果是为了了解某个分布式算法，那就需要按大量的、可能运行在不同节点（进程）上的代码，了解其交互原理、工作流程。

下面说一些通用的方法。

1. 1. 先看文档，整体把握

一般来说，文档是对代码的高度凝练，一个高质量的开源一般会包含tutorial、specification、API reference等documents，通过选择性的略读、精读这些文档，就能大致了解项目的整体架构、设计原则

正确的路线是通过文档去认识这个项目，然乎通过阅读代码去验证文档、深入细节，而不是通过直接啃源码来了解这个项目，以偏概全。