拿到代码的时候
1、最好先看目录结构并找到配置文件
2、以自己的开发经验去判断大概的程序架构，理清楚是否为单点入口，
3、让把程序运行起来
1、最好先看目录结构并找到配置文件
2、以自己的开发经验去判断大概的程序架构，理清楚是否为单点入口，
3、让把程序运行起来
没有数据库的情况下运行起来可能会错误很多，不过这些错误可以引导你对程序理解，对着错误提示，跟踪代码脉络，很容易就把整个系统拿上手了。
我通常是局部功能研究着手，研究一个功能的走向流程，那么基本可以熟悉他的基本工作模式来，然后在逐步的推敲框架结构
先看下是否有框架，如果有框架，去看下框架文档就知道了
如果没有框架，看是否能出框架的出口和入口入手了
先看下 目录结构
使用xdebug生成profile文件，可以用KCachegrind来查看，但是这个工具只在linux下面可用，没有windows下的版本。这里推荐一个win下的免费工具——wincachegrind，也可以查看xdebug的profile文件，用来分析php代码运行情况足够用了（偶尔不太稳定）。
有代码的流程，大部分的项目就可以知道整个代码流程了，
具体逻辑的东西，就只能你自己慢慢体会。
奇吧太多了
开源的吗? 如果有文档的话 当然是先看文档了 如果没有的话就用调试工具吧 比如Zend Studio什么的
好像没有快速的方法。我的做法是看着代码在脑中跑一遍，了解大概流程，然后再细看。
如果没注释的话很困难，如果有phpDocumenter的标准注释可以用它来生成文档
一个源码首先第一步不看代码，看结构，大致知道采用的是那种设计模式，例如函数式的还是mvc方式的，接下来从一个功能入手，先用firebug或者chrome的工具查看请求的url,以及请求url后web前端表现出来的，接下来，上面的模式用到了，去看url对于的方法吧，方法中必定会调用其他的方法，层层递进，分析下来，这个小功能的实现懂了吧，然后多多分析各个功能的实现，大致这个源码的结构熟悉了，那么带着前端的一些操作去摸索各个功能点的实现方法吧
1、拿到代码查看项目当中是否有readme这样的文件，如果没有查看是否有文档之类的
2、代码当中没有文档，那么就想你的同事或者其他人要这个框架的介绍或者资料
3、先请教别人这个框架的大体思路
4、自己独立去按照文档或者其他人说的思路去看代码
5、不懂的地方全部记录下面，一次行去问，有的时候很多问题在你看到后面的东西的时候就自然明白了
6、看懂了代码之后自己尝试着写一个，看自己的理解是否正确就这么多了。
先了解整体流程,在个个击破~!
第一章: 导论
++++++++++++
1.要养成一个习惯, 经常花时间阅读别人编写的高品质代码.
2.要有选择地阅读代码, 同时, 还要有自己的目标. 您是想学习新的模式|编码风格|还是满足某些需求的方法.
3.要注意并重视代码中特殊的非功能性需求, 这些需求也许会导致特殊的实现风格.
4.在现有的代码上工作时, 请与作者和维护人员进行必要的协调, 以避免重复劳动或产生厌恶情绪.
5.请将从开放源码软件中得到的益处看作是一项贷款, 尽可能地寻找各种方式来回报开放源码社团.
6.多数情况下, 如果您想要了解"别人会如何完成这个功能呢?", 除了阅读代码以外, 没有更好的方法.
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<n; i++)形式的循环执行n次; 其他任何形式都要小心.
30.涉及两项不等测试(其中一项包括相等条件)的比较表达式可以看作是区间成员测试.
31.我们经常可以将表达式应用在样本数据上, 借以了解它的含义.
32.使用De Morgan法则简化复杂的逻辑表达式.
33.在阅读逻辑乘表达式时, 问题可以认为正在分析的表达式以左的表达式均为true; 在阅读逻辑和表达式时, 类似地, 可以认为正在分析的表达式以左的表达式均为false.
34.重新组织您控制的代码, 使之更为易读.
35.将使用条件运行符? :的表达式理解为if代码.
36.不需要为了效率, 牺牲代码的易读性.
37.高效的算法和特殊的优化确实有可能使得代码更为复杂, 从而更难理解, 但这并不意味着使代码更为紧凑和不易读会提高它的效率.
38.创造性的代码布局可以用来提高代码的易读性.
39.我们可以使用空格|临时变量和括号提高表达式的易读性.
40.在阅读您所控制的代码时, 要养成添加注释的习惯.
41.我们可以用好的缩进以及对变量名称的明智选择, 提高编写欠佳的程序的易读性.
42.用diff程序分析程序的修订历史时, 如果这段历史跨越了整体重新缩排, 常常可以通过指定-w选项, 让diff忽略空白差异, 避免由于更改了缩进层次而引入的噪音.
43.do循环的循环体至少执行一次.
44.执行算术运算时, 当b=2n-1时, 可以将a&b理解为a%(b+1).
45.将a<<n理解为a*k, k=2n.
46.将a>>n理解为a/k, k=2n.
47.每次只分析一个控制结构, 将它的内容看作是一个黑盒.
48.将每个控制结构的控制表达式看作是它所包含代码的断言.
49.return, goto, break和continue语句, 还有异常, 都会影响结构化的执行流程. 由于这些语句一般都会终止或重新开始正在进行的循环,
因此要单独推理它们的行为.
50.用复杂循环的变式和不变式, 对循环进行推理.
51.使用保持含义不变的变换重新安排代码, 简化代码的推理工作.
++++++++++++
1.要养成一个习惯, 经常花时间阅读别人编写的高品质代码.
2.要有选择地阅读代码, 同时, 还要有自己的目标. 您是想学习新的模式|编码风格|还是满足某些需求的方法.
3.要注意并重视代码中特殊的非功能性需求, 这些需求也许会导致特殊的实现风格.
4.在现有的代码上工作时, 请与作者和维护人员进行必要的协调, 以避免重复劳动或产生厌恶情绪.
5.请将从开放源码软件中得到的益处看作是一项贷款, 尽可能地寻找各种方式来回报开放源码社团.
6.多数情况下, 如果您想要了解"别人会如何完成这个功能呢?", 除了阅读代码以外, 没有更好的方法.
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<n; i++)形式的循环执行n次; 其他任何形式都要小心.
30.涉及两项不等测试(其中一项包括相等条件)的比较表达式可以看作是区间成员测试.
31.我们经常可以将表达式应用在样本数据上, 借以了解它的含义.
32.使用De Morgan法则简化复杂的逻辑表达式.
33.在阅读逻辑乘表达式时, 问题可以认为正在分析的表达式以左的表达式均为true; 在阅读逻辑和表达式时, 类似地, 可以认为正在分析的表达式以左的表达式均为false.
34.重新组织您控制的代码, 使之更为易读.
35.将使用条件运行符? :的表达式理解为if代码.
36.不需要为了效率, 牺牲代码的易读性.
37.高效的算法和特殊的优化确实有可能使得代码更为复杂, 从而更难理解, 但这并不意味着使代码更为紧凑和不易读会提高它的效率.
38.创造性的代码布局可以用来提高代码的易读性.
39.我们可以使用空格|临时变量和括号提高表达式的易读性.
40.在阅读您所控制的代码时, 要养成添加注释的习惯.
41.我们可以用好的缩进以及对变量名称的明智选择, 提高编写欠佳的程序的易读性.
42.用diff程序分析程序的修订历史时, 如果这段历史跨越了整体重新缩排, 常常可以通过指定-w选项, 让diff忽略空白差异, 避免由于更改了缩进层次而引入的噪音.
43.do循环的循环体至少执行一次.
44.执行算术运算时, 当b=2n-1时, 可以将a&b理解为a%(b+1).
45.将a<<n理解为a*k, k=2n.
46.将a>>n理解为a/k, k=2n.
47.每次只分析一个控制结构, 将它的内容看作是一个黑盒.
48.将每个控制结构的控制表达式看作是它所包含代码的断言.
49.return, goto, break和continue语句, 还有异常, 都会影响结构化的执行流程. 由于这些语句一般都会终止或重新开始正在进行的循环,
因此要单独推理它们的行为.
50.用复杂循环的变式和不变式, 对循环进行推理.
51.使用保持含义不变的变换重新安排代码, 简化代码的推理工作.
全文均为转载 从各个帖子，博文里
有来源于知乎帖的 最后这段转自jk110333的文章
5724
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
