是什么支撑你们去看框架源码的？

[binbinyouliiii]

我每次去看源码，比如像 Spring 这种，大体思想我还是知道的，但是这么大的框架，完全没有头绪,一个类跟多个类相关，注释也是介绍怎么用，不会介绍架构。

比如一个注解类，整个框架环环相扣，循序渐进越来越多的类根本看不下来，更别说总结了。

网上一堆介绍源码的文章，就简单的介绍两句，接下来就直接贴了一大段代码，看个鬼哦！

有的文章也不错，但是都是只言片语，或者深一点的找不到资料。

老哥们是怎么看源码的，或者说都是硬啃的？

[xiangyuecn]

自己写的代码，过段时间来看 其实也是这个效果。。。😂

[pomony]

弱鸡表示：debug 的时候看运行栈

[srx1982]

当然是出问题的时候看了。。。

[itning]

出错，需求，DEBUG

[Fazauw]

这不是我写的 bug，一定是框架的╰（‵□′）╯

[AngelCriss]

因为要造框架

[qq7788611]

面试，工资

[liuzhaowei55]

文档太烂。

[whoisghost]

我是要写差不多的东西拿去开源吹牛逼的时候，才会去看源代码。比如写的 gap-proxy, 我就研读了 netstack, v2ray, ssr/ss, kcp-go/kcptun 等我关心的部分。写 FnKV (一个至今未完成，但几乎完成并弃坑了的用 c 写的 k/v 数据库)，我就研读了 BoltDB 源代码。

我个人经验是，在看某开源项目之前，首先想要自己写个差不多的。这样才会针对性、有很强的目的、动力去看现有成熟的开源项目，至于什么技巧之类的，都是其次的。

单纯抱着学习的心态，可能效果不如如上那么好。

[whoisghost]

@whoisghost 吹牛逼一直我技术进步的动力。

[STRRL]

因为自己的无知与好奇。。

[binbinyouliiii]

@pomony 要是包含全局 /成员变量之类的还得找别的地方，没头啊。

@srx1982
@itning 现在我只会怀疑自己代码写错了。

@AngelCriss 像 Spring 这么大的压根看不下去

@qq7788611 现在老哥们的简历上个个都说自己看过各种源码，吓得一愣一愣。

[choice4]

贫穷 哈哈

[lonelygo]

面向工资的看源码了解一下🤫

[ifxo]

没几个人去找虐的，全世界有 100 人吗

[binbinyouliiii]

@ifxo 面试官又特别爱问这种东西，很多人的简历也会写看过 XXX 源码啥的

[loading]

没去看过。我只用过 ui 框架，css important 一大堆……←_←

[Allianzcortex]

理论上只是纯阅读的最好方法是直接 git check out 到最旧的版本看，主干相对清晰些，之后每次 git diff 看都有哪些新功能。

很佩服能看得下去 Spring 代码的同学，每次那么长的堆栈报错都会打消我继续看下去的想法....现在主要看 Go 的代码比较多，之前看过 Python 一些库，有一些挺有意思的发现，比如 requests 在 github 上列出的第一个版本 v0.2.3 里 core.py 这个文件竟然是用 tab 作为 whitespace (之后就修正了)

[Junh]

看源码比看文档快的时候

[woodface2233]

穷想多拿点钱或者年终

[springmarker]

楼上都是为了钱，看来我是一条咸鱼了

[binbinyouliiii]

@Junh SDK 还好说，架构复杂一点的框架完全没心情。

@springmarker 同是咸鱼

[EulerChen]

为了钱，为了梦想，为了更牛逼，为了进 BAT

[micean]

看 spring 的源码当然要崩溃
看 vertx 的源码不晓得多舒服

[chuanzhangACE]

没看几行，吃个晚饭就忘光了怎么破

[javaWeber]

我也在思考这个问题。实在是没头绪。、

[guyskk0x0]

0. 从零开始造一个 web 框架...
1. 从 spring 抄一点，vertx 抄一点，netty 抄一点...
2. 一个集各大框架于一身的框架诞生了...
3. 虽然功能不全，也不知还有多少 bug....
4. 但回头一看，你已经把源码读完了...

[Infernalzero]

第一阶段是排查问题需要，对框架实现比较清楚的话有些问题很迅速就能定位到
第二阶段是要会用框架，光看官方文档你可能并不知道一些隐藏机巧和细节，源码了解过在有些场景下你可能有更好的解决方案
第三阶段是在框架基础下做扩展，有些需求就需要自己对框架的实现做扩展，这种情况也需要读懂框架相应功能的实现
第四阶段是改框架实现了，有些情况下开源框架无法满足一些特殊的需求，而又没有提供相应的扩展的话就需要自己去改对应的实现了，这种情况下不了解框架实现根本没法改

很多人在第一阶段就没兴趣看下去了，一般看到框架报错多数都是弃疗，有的至少还会去搜索引擎里找下解决方案，但是真正对自己解决问题和编程能力提升的还是得要啃源码才行

[lynskylate]

因为难免会造一些小轮子，有些功能相似但和开源不一样，可以参考开源项目的模块划分和核心流程。
举个例子，我当时的一个需求是实现类似 jsonschema 拓展的一套验证数据的东西，我参考了 apistar 的验证系统。

[xiaoshenke]

难道不是因为面试？

[GiantHard]

如果不出 Bug，为啥要去看源码，当然，有时候也会为了学习优秀开源项目解决问题的方法去克隆仓库来看的。

[mringg]

就是 bug，到底看看是自己不会用，还是项目本来就有问题

[meta]

一般是文档写得太烂

[skypyb]

不会用才会去看...像 spring 这种，大家都会用，平时也不会出啥问题，我是没看过一点源码。
但是我之前折腾 Spring Shell 的时候，画表格有个问题太恶心了，google、Stack Overflow 都找不到解决方案，愣是把那一大块所有的代码全看了。画表格那一块别说如何使用，他代码执行流程啥的我都弄清楚了。（虽然那个困扰我的问题最终也没有解决

[zjsxwc]

碰到 bug，追了半天发现是框架的锅，然后提交 pr 给官方，等待大佬来指点我的代码

[falcon05]

调试的时候，偶尔卡壳了，就从头看看源码，带着问题多看几次就熟悉了

[iszengmh]

写看过源码，岂中是要被面试官问死

[my3157]

话说楼上应该没有主力语言是 golang 的, golang 一大堆框架 /库, 还都是个人维护的, 各种蜜汁 bug , 不看源码不成, 好在都不大, 而且 golang 没有太多的奇技淫巧, 大部分看得懂

[deadseven]

我看源代码我能看高潮

[usingnamespace]

动力一 学习精髓，bug 被你一眼看穿，也为以后开发类似的做准备，比如 redis 你源码研究得差不多了以后开发类似的架构不找你找谁，再一方面更主要的就是学架构和设计，
动力二 面向工资和竞争力
动力三 提高代码品味！！！！

[usingnamespace]

@chuanzhangACE 自己长期慢慢研究的源码一定要写成博客！！或者笔记 不然真的是白看

[2kCS5c0b0ITXE5k2]

因为从重量级框架转到轻量级框架不得不的去看那些框架是怎么实现的 ....

[ericgui]

@srx1982 +1

[zhengjian]

文档中描述的功能不足以实现需求的时候，就去翻翻源码有什么非公开的 Api。

然而人家就那么设计的，看了也没得用。

[congeec]

看源码更简单+1

[Just1n]

最好的读源代码的办法应该是 Debug 吧，而且我一直觉得 Debug 是每一个程序员最重要的能力之一。

[comi]

分模块硬吭，调试+运行。
细节是魔鬼。

[wweir]

更多是看 runtime，用到技术的论文资料。框架一般只看思想和骚操作

[bzi]

不想知其然而不知其所以然

[wly19960911]

很多实现需要看框架源码来调试。另外就是一些架构，还有 UI 框架的布局都是值得学习的

[wupher]

of course bug

[q397064399]

框架中很多代码是不值得看的，像 Spring 这种有年头的东西，里面很多代码 都是为了处理 dirty case，没必要浪费时间去一行行阅读，另外这些框架封装的层次太多，只是核心原理就那么点东西，去完整的翻看代码是一件投入产出比极低的事情，如果要研究 Spring 建议看 相关介绍的书籍 读代码 建议直接读 TinySpring，另外真的学技术 还是从底层把基础打好，这些框架东西都摆不脱底层 协议 操作系统 语言特性 那些玩意东西的。

[linZ]

因为五一玩游戏太多了，有负罪感。。。

[ala2008]

想扩展功能和看看怎么实现的。。

[specita]

一般会找个小的开源项目看，spring 这种 debug 时才会看

[bakabie]

Typecho，看源码比看文档快多了

[eternaldzw]

穷

[wizardoz]

个人不喜欢主动去看源码。但是有时候用到一个 API 或者类，文档没有提到自己关心的点，那就需要去看一下源码。但是也仅限于局部的看。一旦自己需要知道的看明白了就不看了。

[hihipp]

看框架源码，从启动类开始找线索，依赖注入严重，有时候挺难找具体实现类的。

至于部分框架源码，驱使我去看有这几种原因。
一：想看看这部分是怎么设计与实现的。
二：对比不同方法相同功能，内部差异是什么？

[vance]

一般只针对某个类或某个方法实现去看，像 Spring 这种框架只了解了下原理

[lazyfighter]

面试 工资（贫穷

[alexmy]

一般自己想造轮子的时候就会看各种已经运行良好的轮子。

[whusnoopy]

没看过 Java 的框架，看过的可以算

1. Bootstrap v3，把整个 css/less 和 js 自己逐行抄了一份，因为用的多，通过看文档和别的用法来理解，还是不如自己抄一边来的深刻，而且真的是逐行抄，不是大段的复制粘贴
2. Flask/werkzeug，某段时间写业务写不太动，刚好业务上压力没那么大的时候，去看了一遍 Flask 和 werkzeug 的实现，对以前一知半解的很多细节有了更好的认识，后面真的各种用的时候也更得心应手
3. WTForms，这个完全是调一些不符合预期的情况下，被逼去看了一遍实现，因为我们项目里没拿来生成 Jinja2 的表单和校验，都是拿来对 RESTful 的请求做参数校验，这个库在这种校验方面各种设计奇葩实现错误，去提 Issue 和 PR 都不理，只能自己去打补丁

[gamegrd]

无它，BUG 所迫

[MissThee]

@choice4 非常真实了

[zgl263885]

个人建议，可以先看看设计模式和设计原则这些奇技淫巧，然后看源码会好些，一些设计模式常用的关键字一眼就知道源码是想做什么的了，比如 factory,instance 等。

[annielong]

功能满足不了需求，看看能不能改一下

[nineyang]

我的建议是，先整理主干再丰富其骨肉，不要一上来就从头到脚开始啃。
比如你面对一个项目，你可以先了解各个组件是用来干嘛的，甚至于你还可以先猜测一下这个组件大致是如何嵌套到这个项目中的，然后根据你的猜测去快速扫描其实现方式，与你的想法是否有所出入。如果相同，那么你可以选择性的看一些细节，如果基本不同，那你再去细看其实现。
最后，当你把各个组件看完之后，自己再从头到脚梳理一遍整理的流转过程。
一点浅薄的陋见，不喜勿喷。

[nineyang]

@nineyang 学生时代的时候，在看一些习题的时候喜欢自己先做再看其解答。我把这种方式放在了阅读源码的过程中，还是有点小小的乐趣的，特别是当你的想法与作者不谋而合的时候。

[MonoLogueChi]

开发需要，文档描述不清楚的时候就需要去看一眼源码了，有些代码不知道怎么写，就去看一眼源码是怎么实现的，理想条件下，源码只要注释写得足够详细，文档只需要说明有哪些功能和接口就可以了，示例可以直接看源码。

[cherryer]

面试

[enaxm]

@Allianzcortex
赞同，看 linux 内核也是这么看的。有些框架封装的太复杂就不看了。

当然还可以去实现一个框架然后对比或者成熟框架贡献者里头看看大牛提交了哪些更改。

[socradi]

为了写一篇博客

[xfriday]

这个库有问题，我要看看:)

[keikeizhang]

穷

[daodao116]

面试。。。。哈哈哈哈。

[a719031256]

网上没有现成的资料就得去看源码

[qiumaoyuan]

应该是米饭吧，吃多了的话就会撑着。

[qiumaoyuan]

非 debug 的情况下完全没必要看什么源码。通过看源代码来学习这种口口相传的方式真的莫名其妙。
好的代码从来不引人注意，平淡无奇，过目即忘，你会觉得代码就是应该那么写的。到自己写的时候根本想不起来为什么别人那么写。
只有一些炫技的代码才会引人注意，但往往是把人往坑里带。

[lookas2001]

文档太烂+1，另外有些东西用了不知道原理就非常难受，这时候会瞅瞅框架提供的代码。。
实用主义吧，，，需要的时候去看，不需要就不看了。

[connection]

以前看源码是有趣的 clone 到本地 硬啃。一个个文件细节硬啃。

现在是啃的必定是自己在用的。
阅读的时候从全局再到具体。效率较以前低，但是想法比以前多了。

某些点自己不清楚的，希望学习提高的，那部分细节看。