先来分享下我的经历

在我刚从Java转到Python时就直接接触的Django框架，当时同事给我推荐过一本Django的英文书《Practical Django Projects》,当时看了几页，因为速度太慢，就转向这个网站：http://djangobook.py3k.cn/2.0/ 。 当时我们使用的Django是1.3的版本，这个翻译的网站翻译的文档版本是1.1，但大部分差不多，也算是个能快速了解Django的途径。

后来随着对Django使用的越来越多，发现翻译的东西虽然能让你快速了解Django的一些东西，但是很多细节的地方还是需要去看英文文档才能明白，究其原因主要有两个：一是文档更新慢，二是文档是有志愿者参与翻译的，水平不一，细致程度也不一。于是就很少再去看这个中文的了。

再之后，每每遇到问题请教同事或者在网上查得时候总能得到这样的反馈——你看过这部分的文档吗？！先去看看文档再来讨论。于是乎，在这样不断的被鄙视过程中不断的熟悉了Django的官方文档，对于Django的问题也终于有了正确的认识——那就是，有问题就去看文档;出错了，一定是你文档看的不仔细。

除了在这样被鄙视的的状态下去看文档的，自己也尝试过去挨篇读文档，唯一的收获就是大概知道有哪些东西了，附带的收获就是对文档这东西不那么陌生了。

再后来基本上就是用到一个模块，遇到问题，就去自己阅读相应的文档。当时还翻译了三部分： Django1.4数据库访问优化部分 这个是项目运行时遇到问题之后去仔细看了下，然后给同事做了分享，花了点时间翻译了下。另一部分是： Django1.4文档的class-based-views 这是为了学习怎么使用Class Based View才开始翻译的，这算是我自己集中精力的一种方式，当你的大脑是在无法接受这些英文字母时，一句一句的去翻译会让你打起精神来。还有一部分middleware的翻译，也是基于同样的目的。

翻译几篇之后基本上就对Django的文档中的常用语比较熟悉了，剩下的就是花点时间去看看，或者用到了就去看看。

这就是大概的经历，下面稍稍总结下。

战略上藐视它

在一开始学习Django的时候，第一次打开官网，肯定会被如此多的文档震惊了——“天哪，什么时候能看完”。其实这是一个错误的心态，这不是什么xxx入门书，你得看完之后才能入门。这就是一个文档、手册，把Tutorials看一遍就行了，剩下的就是随用随查，心情好的时候来搂两眼。不然的话心里包袱太重导致哪一章都看不下去。

Django文档的模块介绍

Django的文档基本上就这几个模块——Model layer, view layer, template layer, Forms, deployment process。

这几个模块的介绍顺序就是你项目开发的顺序，先定义Model，然后写view，最后渲染template。forms这部分通常情况下用的不多，最最后就是部署了。

Model 这一部分包含了所有你要和数据库打交道的内容，一般项目在一开始的时候都会先抽取实体，然后定义模型，所以这一部分在文档的开始。

从你开始定义Model中使用的字段，类型，到Model查询出得结果Queryset的介绍，以及Model这个对象实例化之后包含哪些方法都在这一部分了。

只要是和数据库相关的部分，遇到问题查这个应该就差不多了。

View 这一部分是在你定义好Model之后需要用到的。在view中的逻辑是接受浏览器发过来的request请求，也就是在view中常写的 def view(request): 。接受到这个Request之后，就是你自己的业务逻辑了，基本上也就是从Model中取出数据，然后对数据进行处理，最后通过Response返回给浏览器。

除了view内部的逻辑之外，在一个view被调用之前还有一个urlconf的配置，用来匹配对应的url到对应的view中。而在往上捣捣就到Middleware了，这一层的主要作用是处理接收到的Request和返回的Response。

剩下的也就是文件上传，数据导出之一类的东西。但凡是逻辑部分的东西，都在这部分能找到。

这里附一张Django接受请求的流程图:

Template 这个就是模板的基本使用，Django的模板本来就很简单，看看语法，看两个例子就行了。因为语法简单，所以可能会遇到满足不了需求的情况，这种情况下就需要自己扩展了，Django提供了Tags和Filter的接口，允许你编写自己的扩展。

常用的也就这几部分，等到项目开发的差不多需要部署的时候，需要再去看看 The development process 部分。如果需要用到Django自带的Admin的话，可以去看看The admin部分。其他的部分就是随用随取，当然更好的情况是自己有心情，走马观花的看看。

可能存在的捷径

无论是读翻译的中文文档，还是遇到问题时去搜中文的资料，你看到的任何一个材料其实都逃不了Django的官方文档。因此我们可能不需要绕太多的弯子来达到理解Django文档在说什么这一目的。

直接去看英文文档可能会是一个捷径。无论是翻译还是别人（或者我）写的关于Django某一点的应用，都会随着Django版本的更新变得不再实用。并且所有这些资料的最终来源都是在官方文档上，因此不如直接从源头上汲取营养。

另外还得说说英文阅读的事儿，这是任何开发人员都绕不过的坎，关于英文对程序员的重要性网上已经有很多论述了，我这里不再添加冗余的信息了。只说一句：如果你没有办法直接从源头上获取知识，那你就只能去等别人帮你消化完，这样的结果是你不但丧失了消化能力，还始终获得的是陈旧甚至被曲解过的知识。

两种实践方法

自己一个人看东西有时还是挺无聊的，单纯的阅读也是挺无聊的，那么当你陷入这种状态之后，怎么破呢？我个人总结了两种实践方法：

以练促读 通过练习来读文档，看的时候顺便写写代码，验证下文档是不是正确。这个方法相当的实用，别光看，动起来，实践出真知嘛。很多东西你以为自己读懂了，但真正用的时候还是糊里糊涂。就像是我之前写的那篇《从Django的Tutorials可以学到什么》一样，虽然以前就看过，但是不实践一次的话，还是没有什么感觉。

所以，以练促读对我来说是一个高效的，并且不太费时的方法。

以教促学 相对于上面的方法，这个以教促学的方法会花更多的时间。上面的方法只是自己明白，能够使用。这里的目的却是把别人也讲明白，这就需要把要讲的内容反反复复的仔细琢磨，然后转化为自己的方式、语言，传递给别人。

虽说耗时会多些，但收获是更多的。

总结

吧啦吧啦的写了一堆，也算是对自己的思路做一个整理。写这篇文章，其实就是在实践上面的 以教促学 这一方法，写文章的耗时要远多于我自己在脑海中构想Django的文档结构，但写出来才是真正的把构想实现。这也是我喜欢写博客缘由之一。

本文的主要是从自己的经验上来说的，仅供参考，也欢迎补充不同的方法和建议。