如何有条理地阅读源码_阅读源码的正确方式

文章目录：

• 1、为什么以及如何阅读源码
• 2、如何阅读源代码
• 3、怎样才能更好地阅读他人的 Android app 的源代码
• 4、如何写出规范的JavaScript代码
• 5、如何高效地阅读lucene源码
• 6、如何正确的阅读源代码

为什么以及如何阅读源码

对于这些问题，说到底主要是因为经验不够，而经验主要从项目实践中积累，所以招聘单位一般都会限定工作时间大于 3 年，因为这些人的项目经验相对较丰富，项目中遇到的场景相对较多。

工作经验的积累来自于年限与实践，然而看源码可以扩展我们的思路，这是变相增加我们经验的不错方法。虽然不能短时间内通过时间积累经验，但是可以通过学习开源框架、开源项目来获取。

另外进职场后一般都要先熟悉现有系统，如果有文档还好，没文档的话就得自己去翻代码研究。如果大家之前对阅读源码有经验，那么在研究新系统的代码逻辑时就不会那么费劲了。

如何阅读源代码

最近有做源码阅读的事情，觉得有些费尽，做了一些思考。 一个大项目的源代码，不要过份详细的阅读。大项目，其代码量基本上是可以吓死人的。过份的关注细节，常常会拘泥于细节，而忽略了整体框架。当你能够看清框架的时候，亦花费了太多的时间。 因此，阅读一个大项目的源代码，其目的不在于欣赏代码细节，而在于迅速看清项目整体框架的大概面貌：都有那些模块，这些模块是干嘛的（不关心具体怎么干），模块之间的通讯机制大概是怎样的，然后在考虑子模块，通常只要掌握两级子模块就够了。花上1，2天的时间掌握这一切，就达到了阅读大项目源码的目的。因为一旦你掌握了框架，你就可以按照这个框架实现这个项目，虽然和原项目全然不同，但是完成的需求却是一样的。 在软件中，架构才是本质。 也许你指望详细阅读大项目源代码能看到高质量的代码，但是，大项目通常都是团队的劳动成果，每个人的不同水平造就了代码质量的高高低低，一个人在不同时间不同环境的代码质量也是不同的。要指望在大片源码面前找到高质量，简直是天方夜谭。 也许你要从阅读源码中掌握某项技术细节，比如bsp，又或者换装，那么，最好的建议是查找相关的技术文档以及文档上所附带的sample code，这种sample code一般不会附带任何干扰，简洁得只是为了证明该技术而存在的。如果没有这些东西，而只能从大项目源码中找的话，你提前先了解了框架，能更快的查找和定位到表达该技术的文件。但是通常都会比较不幸，因为你为了明白这一技术，通常要先理解混入其中的另一技术。 最后谈谈怎样才能阅读到高质量的源代码。何谓高质量？是指算法出人一表（比如某种o(1)的排序法）？还是采用了极端深奥的语言特性将某实现完美表达（比如模板的灵活运用）？无论是哪种，最好的来源是书，如《STL详解》，或者《inside XX》这样的东西。书的作者通常就是这些高质量代码的作者，他会带领你探索这些源码背后的真相。

怎样才能更好地阅读他人的 Android app 的源代码

读别人的项目源码，可以先找一个切入点，如程序的入口，一层层深入阅读，跟踪代码的调用，便能了解整个项目。

在阅读时不必纠结于一点，或过于深入某一点（除非该功能很重要），这样才能对项目有大致的了解，加快阅读的速度。

在寻找切入点时，可以根据类名、方法名等，快速定位功能，免去阅读无用代码的时间。

如何写出规范的JavaScript代码

本人在开发工作中就曾与不按规范来开发的同事合作过，与他合作就不能用"愉快"来形容了。现在本人撰写此文的目的除了与大家分享一点点经验外，更多的是希望对未来的合作伙伴能够起到一定的借鉴作用。当然，如果我说的有不科学的地方还希望各路前辈多多指教。下面分条目列出各种规范要求，这些要求都是针对同事编码毛病提出来的，好些行业约定的其它规范可能不会再提及。1. 保证代码压缩后不出错对于大型的JavaScript项目，一般会在产品发布时对项目包含的所有JavaScript文件进行压缩处理，比如可以利用Google Closure Compiler Service对代码进行压缩，新版jQuery已改用这一工具对代码进行压缩，这一般会去掉开发时写的注释，除去所有空格和换行，甚至可以把原来较长的变量名替换成短且无意义的变量名，这样做的目的是加快文件的下载速度，同时也减小网站访问带来的额外数据流量，另外在代码保护上也起到了一点点作用，至少压缩后的代码即使被还原还是没那么容易一下读懂的。要想代码能正确通过压缩，一般要求语句都要以分号正常结束，大括号也要严格结束等，具体还要看压缩工具的要求。所以如果一开始没有按标准来做，等压缩出错后再回去找错误那是浪费时间。2. 保证代码能通过特定IDE的自动格式化功能一般较为完善的开发工具（比如Aptana Studio）都有代码"自动格式"化功能，这一功能帮助实现统一换行、缩进、空格等代码编排，你可以设置自己喜欢的格式标准，比如左大括号{是否另起一行。达到这个要求的目的在于方便你的开发团队成员拿你代码的一个副本用IDE自动格式化成他喜欢或熟悉的风格进行阅读。你同事需要阅读你的代码，可能是因为你写的是通用方法，他在其它模块开发过程中也要使用到，阅读你的代码能最深入了解方法调用和实现的细节，这是简单API文档不能达到的效果。3. 使用标准的文档注释这一要求算是最基本的，这有利于在方法调用处看到方法的具体传参提示，也可以利用配套文档工具生成html或其它格式的开发文档供其他团队成员阅读，你可以尝试使用jsdoc-toolkit。如果你自动生成的API是出自一个开放平台，就像facebook.com应用，那么你的文档是给天下所有开发者看的。另外编写完整注释，也更方便团队成员阅读你的代码，通过你的参数描述，团队成员可以很容易知道你编写的方法传参与实现细节。当然也方便日后代码维护，这样即使再大的项目，过了很长时间后，回去改点东西也就不至于自己都忘记了当时自己写的代码是怎么一回事了。4. 使用规范有意义的变量名使用规范有意义的变量名可以提高代码的可读性，作为大项目开发成员，自己写的代码不仅仅要让别人容易看懂。开发大项目，其实每个人写的代码量可能都比较大，规范命名，日后自己看回自己的代码也显的清晰易懂，比如日后系统升级或新增功能，修改起代码来也轻松多了。如果到头发现自己当初写的代码现在看不太懂了，那还真是天大的笑话了。当然，使用有意义的变量名也尽量使用标准的命名，比如像这里：var me = this也许没有var self = this好，因为self是Python中的关键字，在Python中self就是通常语言this的用法。再看下面一个例子，加s显然比没有加来的科学些，这样可以知道这个变量名存的是复数，可能是数组等： var li = document.getElementsByTagName('li') var lis = document.getElementsByTagName('li') 5. 不使用生偏语法JavaScript作为一门动态脚本语言，灵活性既是优点也是缺点，众所周知，动态语言不同层次开发人员对实现同样一个功能写出来的代码在规范或语法上会存在较大的差别。不管怎么样，规范编码少搞怪，不把简单问题复杂化，不违反代码易读性原则才是大家应该做的。比如这语句：typeof(b) == 'string' alert(b)应该改为：if (typeof(b) == 'string') alert(b)，像前面那种用法，利用了运算符解析机制：如果检测到前语句返回false就不再检测后面语句，在代码优化方面也有提到把最可能出现的情况首先判断，像这种写法如果条件少还好，如果条件较多而且语句也长，那代码可读性就相当差。又比如：+function(a){var p = a;}( 'a')应该改为：(function(a){var p = a;})( 'a')，其实function前面的+号与包含function的()括号作用是一样的，都是起运算优先作用，后者是常见且容易看明白的防止变量污染的做法，比如好些流行JavaScript框架就是采用后面这种方式。再说个降低代码可读性的例子，如：function getPostionTxt(type){return type == 2 ? "野外" : (type == 3 ? "商城" : (type == 4 ? "副本" : null));}应该改成：function getPostionTxt(type){var typeData={"2":"野外","3":"商城","4":"副本"};if (typeData[type]) return typeData[type]; else return null;}。如果type是从0开始不间断的整数，那么直接使用数组还更简单，这种结果看起来就清晰多了，看到前面那种多层三元表达式嵌套头不晕吗。6. 不在语句非赋值地方出生中文语句中不应该出现中文我想一般人都知道，虽然这样做不影响程序运行，但是显然有背行业标准要求，当然我们也不是在使用"易语言"做开发。关于这一个问题，我本来不想把它拿出来说的，但我确实遇到有人这样做的，也不知道是不是因为他的英语实在太烂了，至少还可以用拼音吧，另外寻求翻译工具帮忙也不错的选择。我举例如下，像以下写法出现在教学中倒还可以理解：this.user['名字'] = '张三' 或者 this.user.名字 = '张三'7. 明确定义函数固定数量的参数固定数量参数的函数内部不使用arguments去获取参数，因为这样，你定义的方法如果包含较多的脚本，就不能一眼看到这个方法接受些什么参数以及参数的个数是多少。比如像下面： var $ = function(){return document.getElementById(arguments[0]);}应该改成：var $ = function(elemID){return document.getElementById(elemID);} 8. 不必热衷动态事件绑定虽然知道事件可以动态绑定，比如使用addEventListener或者使用jQuery的bind方法，也知道采用动态事件绑定可以让XHTML更干净，但是一般情况下我还是建议直接把事件写在DOM节点上，我认为这样可以使代码变得更容易维护，因为这样做，我们在查看源代码的时候就可以容易地知道什么Element绑定了什么方法，简单说这样更容易知道一个按钮或链接点击时调了什么方法脚本。9. 降低代码与XHTML的耦合性不要过于依赖DOM的一些内容特征来调用不同的脚本代码，而应该定义不同功能的方法，然后在DOM上调用，这样不管DOM是按钮还是链接，方法的调用都是一样的，比如像下面的实现显然会存在问题： function myBtnClick(obj) { if (/确定/.test(obj.innerHTML)) alert('OK'); else if (/取消/.test(obj.innerHTML)) alert('Cancel'); else alert('Other'); } a herf="javascript:;" onclick="myBtnClick(this)"确定/aa herf="javascript:;" onclick="myBtnClick(this)"取消/a 上面例子其实在一个函数内处理了两件事情，应该分成两个函数，像上面的写法，如果把链接换成按钮，比如改成这样：input type="button" onclick="myBtnClick(this)" value="确定" /，那么myBtnClick函数内部的obj.innerHTML就出问题了，因为此时应该obj.value才对，另外如果把按钮名称由中文改为英文也会出问题，所以这种做法问题太多了。10. 一个函数应该返回统一的数据类型因为JavaScrip是弱类型的，在编写函数的时候有些人对于返回类型的处理显得比较随便，我觉得应该像强类型语言那样返回，看看下面的两个例子： function getUserName(userID) { if (data[userID]) return data[userID]; else return false; } 应该改为： function getUserName(userID) { if (data[userID]) return data[userID]; else return ""; } 这个方法如果在C#中定义，我们知道它准备返回的数据类型应该是字符串，所以如果没有找到这个数据我们就应该返回空的字符串，而不是返回布尔值或其它不合适的类型。这并没有影响到函数将来的调用，因为返回的空字符串在逻辑判断上可被认作"非"，即与false一样，除非我们使用全等于"==="或typeof进行判断。11. 规范定义JSON对象，补全双引号使用标准肯定是有好处的，那么为什么还是有人不使用标准呢？我想这可能是懒或习惯问题。也许还会有人跟我说，少写引号可以减轻文件体积，我认为这有道理但不是重点。对于服务器返回的JSON数据，使用标准结构可以利用Firefox浏览器的JSONView插件方便查看（像查看XML那样树形显示），另外你如果使用jQuery做开发，最新版本jQuery1.4+是对JSON格式有更高要求的，具体的可以自己查阅jQuery更新文档。比如：{name:"Tom"}或{'name':'Tom'}都应该改成{"name":"Tom"}。12. 不在文件中留下未来确定不再使用的代码片段当代码调整或重构后，之前编写的不再使用的代码应该及时删除，如果认为这些代码还有一定利用价值可以把它们剪切到临时文件中。留在项目中不仅增加了文件体积，这对团队其它成员甚至自己都起到一定干扰作用，怕将来自己看回代码都搞不懂这方法是干什么的，是否有使用过。当然可以用文档注释标签@deprecated把这个方法标识为不推荐的。13. 不重复定义其他团队成员已经实现的方法对于大型项目，一般会有部分开发成员实现一些通用方法，而另外一些开发成员则要去熟悉这些通用方法，然后在自己编写模块遇到有调用的需要就直接调用，而不是像有些开发者喜欢"单干"，根本不会阅读这些通用方法文档，在自己代码中又写了一遍实现，这不仅产生多余的代码量，当然也是会影响团队开发效率的，这是没有团队合作精神的表现，是重复造轮子的悲剧。比如在通用类文件Common.js有定义function $(elemID){return document.getElementById(elemID)}那么就不应该在Mail.js中再次出现这一功能函数的重复定义，对于一些复杂的方法更应该如此。14. 调用合适的方法当有几个方法都可以实现同类功能的时候，我们还是要根据场景选择使用最合适的方法。下面拿jQuery框架的两个AJAX方法来说明。如果确定服务器返回的数据是JSON应该直接使用$.getJSON，而不是使用$.get得到数据再用eval函数转成JSON对象。如果因为本次请求要传输大量的数据而不得以使用$.post也应该采用指定返回数据类型（设置dataType参数）的做法。如果使用$.getJSON，在代码中我们一眼能看出本次请求服务器返回的是JSON。温馨提示：jQuery1.4后，如果服务器有设置数据输出的ContentType，比如ASP.NET C#设置 Response.ContentType = "application/json"，那么$.get将与$.getJSON的使用没有什么区别。15. 使用合适的控件存储合适的数据曾发现有人利用DIV来保存JSON数据，以待页面下载后将来使用，像这样：div id="json"{ "name":"Tom"}/div，显然这个DIV不是用来界面显示的，如果非要这样做，达到使用HTML文件进行数据缓存的作用，至少改成用隐藏域来存这数据更合理，比如改成：input type="hidden" value=" { "name":"Tom"}" /。其实也可以利用window对象来保存一些数据，像上面的例子，我们可以在AJAX请求页直接包含这样的脚本块：scriptwindow.userData = { "name":"Tom"};/script，当在AJAX请求回调函数中执行完$( "#MyDiv ").html(data)后，在window上就马上有了这一变量。如果采用第一种方法，将不可避免eval(document.getElementById("UserData").innerHTML)。如果在window对象存放大量数据的话，这些数据不用时要及时手动清理它们，它们是要等浏览器刷新或重启后才会消失的，这就会增加内存开销。16. 永远不要忽略代码优化工作代码最优化是每个程序员应该努力达到的目标，也应该成为程序员永远的追求。写代码的时候，不应该急着把功能实现出来，要想一下如何写代码，代码的执行效率才是较好的。举个例子：假设有定义getElementById的快捷方法functoin $(elemID){return document.getElementById(elemID)}，那么有人可能会写出这样的代码$("MyDiv").parentNode.removeChild($("MyDiv"))，其实这里执行了两次getElementById DOM查找，如果改成这样将更好：var myDiv = $("MyDiv"); myDiv.parentNode.removeChild(myDiv)。还好getElementById的DOM查找算比较快，如果换成getElementsByTagName则更应该注重优化了。jQuery开发团队也有提醒大家要注意这方面的问题。当然，代码优化技巧也是需要个人不断积累的。曾有朋友跟我说他写网站后台代码从来不用考虑优化的，因为他们网站用的是至强四核服务器，我觉得这是很可笑的。17. 会分析策划文档，能用面向对象方法进行接口定义和代码组织这一能力对于每一个程序员来说都是非常重要的，这也是决定一个程序员水平高低的一个重要因素。能够把需求细化并抽象出不同的类，然后有条理地编写代码，使代码结构清晰，可读性高，代码易于维护，不至于太过程化而且杂乱无章，这样才算是一个优秀的程序员。

如何高效地阅读lucene源码

1.IndexReader

IndexReader是一个抽象类，提供访问索引的接口。对一个索引的查询就是通过该接口。

有两种不同的IndexReader。

a.AtomicReader：不包含子reader 是一个原子类型的reader 支持存储域，文档值，词和倒排表

b.CompositeReader:

一个基于硬盘的IndexReader实例，通常是通过调用DirectoryReader.open()方法来构造的。

对于更有效地方法，通常通过一个唯一的ID来关联一个document。IndexReader是线程安全的。

2.AtomicReader

3.CompositeReader

4.IndexReaderContext

代表IndexReader层次关系的一个结构类。

5.DirectoryReader

CompositeReader的实现类，可以从一个directory中读取索引信息。

通常调用静态方法open(final Directory directory)

6.FindSegmentsFile

同当前段文件打交道的工具类。

三：IndexReader加载过程

1.FSDirectory调用open方法，打开索引所在的目录

public static FSDirectory open(File path) throws IOException {

return open(path, null);

}

2.FindSegmentsFile调用run函数

首先列出所有的segment_N，并取出其中的最大的N，设为genA

files = directory.listAll();

if (files != null) {

genA = getLastCommitGeneration(files);

}

另一方面，打开segment.gen 文件，从中读出N，设为genB

genInput = directory.openInput(IndexFileNames.SEGMENTS_GEN, IOContext.READONCE);

在 genA 和genB 中去较大者，为gen，并用此gen 构造要打开的segments_N 的文件名

gen = Math.max(genA, genB);

segmentFileName = IndexFileNames.fileNameFromGeneration(IndexFileNames.SEGMENTS,

"",

gen);

3.StandardDirectoryReader调用SegmentInfos.FindSegmentsFile的匿名类的doBody()方法，读取段的相关

信息。

SegmentInfos sis = new SegmentInfos();

sis.read(directory, segmentFileName);

根据生成的SegmentInfos 打开各个段，并生成ReadOnly DirectoryReader

readers[i] = new SegmentReader(sis.info(i), termInfosIndexDivisor, IOContext.READ);

4.Lucene42FieldInfosReader调用read方法，读取段相关.fnm文件

public FieldInfos read(Directory directory, String segmentName, IOContext iocontext) throws IOException {

final String fileName = IndexFileNames.segmentFileName(segmentName, "", Lucene42FieldInfosFormat.EXTENSION);

IndexInput input = directory.openInput(fileName, iocontext);

boolean success = false;

try {

CodecUtil.checkHeader(input, Lucene42FieldInfosFormat.CODEC_NAME,

Lucene42FieldInfosFormat.FORMAT_START,

Lucene42FieldInfosFormat.FORMAT_CURRENT);

final int size = input.readVInt(); //read in the size

FieldInfo infos[] = new FieldInfo[size];

for (int i = 0; i size; i++) {

String name = input.readString();

final int fieldNumber = input.readVInt();

byte bits = input.readByte();

boolean isIndexed = (bits Lucene42FieldInfosFormat.IS_INDEXED) != 0;

boolean storeTermVector = (bits Lucene42FieldInfosFormat.STORE_TERMVECTOR) != 0;

boolean mitNorms = (bits Lucene42FieldInfosFormat.OMIT_NORMS) != 0;

boolean storePayloads = (bits Lucene42FieldInfosFormat.STORE_PAYLOADS) != 0;

final IndexOptions indexOptions;

if (!isIndexed) {

indexOptions = null;

} else if ((bits Lucene42FieldInfosFormat.OMIT_TERM_FREQ_AND_POSITIONS) != 0) {

indexOptions = IndexOptions.DOCS_ONLY;

} else if ((bits Lucene42FieldInfosFormat.OMIT_POSITIONS) != 0) {

indexOptions = IndexOptions.DOCS_AND_FREQS;

} else if ((bits Lucene42FieldInfosFormat.STORE_OFFSETS_IN_POSTINGS) != 0) {

indexOptions = IndexOptions.DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS;

} else {

indexOptions = IndexOptions.DOCS_AND_FREQS_AND_POSITIONS;

}

// DV Types are packed in one byte

byte val = input.readByte();

final DocValuesType docValuesType = getDocValuesType(input, (byte) (val 0x0F));

final DocValuesType normsType = getDocValuesType(input, (byte) ((val 4) 0x0F));

final Map attributes = input.readStringStringMap();

infos[i] = new FieldInfo(name, isIndexed, fieldNumber, storeTermVector,

omitNorms, storePayloads, indexOptions, docValuesType, normsType, Collections.unmodifiableMap(attributes));

}

if (input.getFilePointer() != input.length()) {

throw new CorruptIndexException("did not read all bytes from file \"" + fileName + "\": read " + input.getFilePointer() + " vs size " + input.length() + " (resource: " + input + ")");

}

FieldInfos fieldInfos = new FieldInfos(infos);

success = true;

return fieldInfos;

} finally {

if (success) {

input.close();

} else {

IOUtils.closeWhileHandlingException(input);

}

}

}

如何正确的阅读源代码

除了阅读代码以外, 没有更好的方法. 7.在寻找bug时, 请从问题的表现形式到问题的根源来分析代码. 不要沿着不相关的路径(误入歧途). 8.我们要充分利用调试器|编译器给出的警告或输出的符号代码|系统调用跟踪器|数据库结构化查询语言的日志机制|包转储工具和Windows的消息侦查程序,

定出的bug的位置. 9.对于那些大型且组织良好的系统, 您只需要最低限度地了解它的全部功能, 就能够对它做出修改. 10.当向系统中增加新功能时, 首先的任务就是找到实现类似特性的代码, 将它作为待实现功能的模板. 11.从特性的功能描述到代码的实现, 可以按照字符串消息, 或使用关键词来搜索代码. 12.在移植代码或修改接口时, 您可以通过编译器直接定位出问题涉及的范围, 从而减少代码阅读的工作量. 13.进行重构时, 您从一个能够正常工作的系统开始做起, 希望确保结束时系统能够正常工作. 一套恰当的测试用例(test

case)可以帮助您满足此项约束. 14.阅读代码寻找重构机会时, 先从系统的构架开始, 然后逐步细化, 能够获得最大的效益. 15.代码的可重用性是一个很诱人, 但难以理解与分离, 可以试着寻找粒度更大一些的包, 甚至其他代码. 16.在复查软件系统时, 要注意, 系统是由很多部分组成的, 不仅仅只是执行语句. 还要注意分析以下内容:

文件和目录结构|生成和配置过程|用户界面和系统的文档. 18.可以将软件复查作为一个学习|讲授|援之以手和接受帮助的机会. ++++++++++++++++++++ 第二章: 基本编程元素 ++++++++++++++++++++ 19.第一次分析一个程序时, main是一个好的起始点. 20.层叠if-else if-…-else序列可以看作是由互斥选择项组成的选择结构. 21.有时, 要想了解程序在某一方面的功能, 运行它可能比阅读源代码更为恰当. 22.在分析重要的程序时, 最好首先识别出重要的组成部分. 23.了解局部的命名约定, 利用它们来猜测变量和函数的功能用途. 24.当基于猜测修改代码时, 您应该设计能够验证最初假设的过程. 这个过程可能包括用编译器进行检查|引入断言|或者执行适当的测试用例. 25.理解了代码的某一部分, 可能帮助你理解余下的代码. 26.解决困难的代码要从容易的部分入手. 27.要养成遇到库元素就去阅读相关文档的习惯; 这将会增强您阅读和编写代码的能力. 28.代码阅读有许多可选择的策略: 自底向上和自顶向下的分析|应用试探法和检查注释和外部文档, 应该依据问题的需要尝试所有这些方法. 29.for (i=0; i 30.涉及两项不等测试(其中一项包括相等条件)的比较表达式可以看作是区间成员测试. 31.我们经常可以将表达式应用在样本数据上, 借以了解它的含义. 32.使用De Morgan法则简化复杂的逻辑表达式. 33.在阅读逻辑乘表达式时, 问题可以认为正在分析的表达式以左的表达式均为true; 在阅读逻辑和表达式时, 类似地,