提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
由于新换工作，在熟悉项目和模块方面做出如下总结：
这个文章会随着自己的理解加深而不断修改
提示：以下是本篇文章正文内容，下面案例可供参考
在刚接手熟悉项目时，虽然会有老人大致讲解一下项目的功能结构，让自己对项目有一个大致的了解，但由于时间问题我们大部分只能记住个大概，其模块内具体功能则需要自己去详细了解。
以前熟悉项目或开源的第三方代码总是需要用到某个功能时才会去稍微看一下源代码及实现方式，比如在编写Dialog时也会时常查看代码是如何实现的其功能是什么。
程序是别人写的，只有写的人才知道他的真正用途和涵义，很多人都有逆反心理不愿意去阅读或了解别人所写的源代码，我之前也是如此，写代码是开心的，但是阅读别人留下的代码是我之前所恐惧的，有时候我也会如大部分人一样宁愿重写代码也不愿意使用别人已写好的代码（当然简单的例外）对于复杂的我不愿意去维护和修复和加强他们，为什么会这样自我？在看过网上同类文章后，自我总结为：程序是别人写的，只有原作者知道程序的含义和用途，如果自己要用就得去触碰这些代码，碰就得了解，了解就得阅读大致代码这样就产生了逆反心理。
很多人会把接手别人留下的代码，当作头疼的事情当然我也不例外，因为这确实很费脑，因为得花时间去阅读并理解他是怎样的思路来写这些代码的，这得费时间去探索。
但是现实原因确实让我们不得不去接受这些代码，像同事离职留下的代码你必须去接手他遗留的工作，这只是其中一种情况，我们总是要触碰其他人所写的代码，但是换个心态来看待这些问题可能就会不一样了，我们可以透过同事留下的代码或在阅读开源源码时学习到优秀的新的技术，和高手是怎么设计架构的，以及设计模式使用的场景等等，当阅读完一个优秀的开源框架，我们可以从中提炼出自己的代码，可能这就是站在巨人的肩膀吸取养分吧。
写代码只是一个程序员的技能之一，同样读懂并修改别人的代码也是一个很重技能。
如果不熟悉项目，就无法解决实际开发工作中带来的问题，也无法解决别人已经写好的代码问题，看着现成的代码也无法下手。
接触别人的代码可以分为三种：1.了解，2.修改 扩充，3.抽取 提炼，了解别人写的代码是最基础的工作，如果不了解就不用说修改或者扩充也不能提取到自己所需的，回收再利用别人的代码。虽然说是阅读别人代码，但不能像读小说一样循序渐进一行一行下去，找到程序入口很简单，但系统复杂度一般很高，十分庞大有时候千头万绪。
从程序入口开始读，如果循序读完所有代码很费时间，用这些方式很难建立系统的全貌，从而了解到系统的全貌，个人通过学习他人阅读技巧和自我实践认为阅读代码的重点，不至于读完每一行代码，在与有效的透过探索及阅读，从而了解系统的架构及行为模式，以便在需要了解到具体某个功能的细节时，能够很快在脑海出现具体代码的位置，到这个时候才是细读源码的时候。
阅读源码首页得对写代码所使用的语言熟悉，在阅读中也能学习到语言的各种不同用法，其次是了解程序的命名规则这个也很重要，不同的人和团队都会有差异，但是如果团队都按照统一的规则那我们阅读起来就非常顺畅了。
关注写这个代码的作者心态与习惯也能很好的帮助我们了解作者惯用的语汇。
这一段总结：要了解一个系统，最好是采取由上而下的方式，先尝试了解系统架构性观念，不要过早的钻入细节，因为这样对于了解全貌没有多大帮助，阅读代码不是在于读完每一行代码，我们的目的也不是这样。
最重要的价值是能读懂作者的代码，才有能力从中萃取自己需要的代码，以此提高生产力。
读懂别人代码的基础就是了解所使用开发语言和对方命名惯例，有了这个基础，才算是有了基础的阅读能力，毕竟想要读懂俄文钢铁是怎样炼成的小说，总不能俄文都不懂吧。
阅读代码我们很少从第一行开始读起，阅读代码的目的在于了解系统全貌，而不是为了地毯式阅读一遍代码。
拿车这个对象来说，他会拆解为多个对象比如轮胎、方向盘等，我们读轮胎类可以明白他的作用和行为，但是对于他和方向盘是如何交互的怎么协同工作的我们根本不知道，因为每个类只描述他本身的行为，如果我们只阅读轮胎就很容易造成片面的认识。
如果不想浪费大量时间去阅读源码，就得转换观点来看待系统，从个别类的行为入手，由上到下的方式去阅读。
同样的，以Java写的Android程序中，也许会应用的okhttp之类的框架，这些都可以看做主要架构下的次级架构。甚至在okhttp次级架构下建立更自由的次级架构。
对我们来说，谈到架构这样的观念时，我们必须要有层次感，不管是那一层级的架构都有各自的角色，以及每个角色的关系。对阅读代码的我们来说，相较于直接切入最细微的单一角色行为，不如直接了解某个特定架构中，究竟存在多少角色，以及这些角色之间的互动模式，比较能够帮助我们了解整个系统的运作方式。