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

[binbinyouliiii]

我每次去看源码，比如像 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，另外有些东西用了不知道原理就非常难受，这时候会瞅瞅框架提供的代码。。
实用主义吧，，，需要的时候去看，不需要就不看了。