Python - 关于代码阅读的一些建议
初始能力
让阅读思路保持清晰连贯，主力关注在流程架构和逻辑实现上，不被语法、技巧和业务流程等频繁地阻碍和打断。
建议基本满足以下条件，再开始进行代码阅读：
- 具备一定的语言基础：熟悉基础语法，常用的函数、库等；
- 了解业务背景和逻辑；
- 了解设计模式、熟悉编程和构建工具的使用、了解代码风格；
工具使用
- Source Insight - 具有强劲的代码浏览和分析功能
- Doxygen - 项目文档工具
- grep命令 - 用于全局搜索
- 利用代码结构分析功能或插件生成UML图
- Python Call Graph - 生成python函数调用关系图
- 代码转换成流程图 - 在线工具
- 浏览器插件Octotree - 直观显示Github项目树形结构
- 浏览器插件Git History - 直观显示Github项目历史记录
- ......
准备动作
明确问题与需求:
- 为什么要阅读源代码？要解决什么具体问题？要达到怎样的程度和效果？- 当前状态（初始能力、资源投入等）如何？是否足够支撑开始并完成这样的代码阅读？
- 没有明确目标，将会导致大量无效的阅读，就难以获得实际的收获；
一些参考步骤：
- 对于知名项目，收集规整已有的代码分析资料；- 确认辅助信息来源：官方文档、项目文档、搜索引擎等；
- 确认代码版本（早期版本或当前能够理解的版本）和编码风格；
方法和注意事项
问题需求、资源投入、项目状态的不同，适用的阅读方法和工具自然也就不同。
直接啃代码的方式适合解决具体的细节问题，简单粗暴，速度快效果好。
但如果想完整而深入地了解一个有规模和难度的项目，又该如何进行呢？
一些参考方法：
- 阅读“README”；- 通过查看提交和版本日志，研读所关注的功能和优化；
- 搭建测试环境并运行Demo或示例，观察运行状态，从外部了解核心功能和运行方式，形成总体认知；
- 善用文档：quickstart、tutorial、howto等内容中的示例往往是非常有效的了解途径；
- 分层阅读：先整体后局部，借助工具生成UML图，从整体了解代码结构和调用关系，确定阅读的层次和顺序；
- 寻找程序入口，根据实际情况确定阅读的切入点；
- 为代码写注释，必要时形成文档；
- 问题列表：记录疑问和问题并归纳成表，解决问题的过程也就是代码逐渐清晰的过程；
- 查看单元测试，编写测试用例，抛异常；
- Debug所关注的执行过程，观察现象和日志，明确调用关系和执行路径；
一些注意事项：
- 带着问题与需求阅读代码，围绕根本和主干，没有必要通读源码，更不应该沉陷于细节；- 必要时略过难以理解的地方，不过度纠结于某一行某一段；
- 理解项目作者的思考方式，
- 低头专注代码，抬头思考架构，结合业务流程，从整体的角度来看待局部实现的过程；
简而言之，也就是“因人而异，因地制宜”，有效的才是合适的。
下一步
- 关注原型
最终展现的软件往往是“原型程序”经过精心包装和美化的结果。 “原型程序”只包括核心和基础功能，是可用的初始化版本，是“软件成长的起点”。
应该从“起点”开始跟随，而不是从“终点”返回。
- 迭代式理解
软件是成长起来的，而不是一次性搭建完成的，尝试理解代码，也会有一个循序渐进的过程。 对项目代码的理解，只是当时的理解，受限于当时的技能水平，知识结构，资源投入，甚至是身心状态。
经过一段时间磨砺和成长，回头再阅读同样的项目代码，往往会有新的发现和理解。
- 改善适用性
“学以致用”是获得知识技能的最有效途径之一。 实现自己的需求和想法，最终形成更适合的版本。
在现有“轮子”的基础上去制造“一个更完善轮子”，在这样的二次开发过程中，可以验证代码理解。
- 获得建议与批判
落后的起源是“故步自封”、“自以为是”和“自欺欺人”。 归纳并分享你的理解，会获得更全面更专业更中肯的建议与批判。
争议之中，也恰恰隐含着成长与改变的线索与机遇。
以上是 Python - 关于代码阅读的一些建议 的全部内容， 来源链接： utcz.com/z/389297.html
