一般情况下,良好的设计风格产生的代码(不良好的也不让过啊)往往都是由一个个具备统一或者类似功能要求而形成代码文件组成。所以我们在理解代码的时候也应该遵循这种逻辑,可以先试着挨个文件进行大致的了解,每个文件是用于实现什么功能,或者统一之处在哪里,便于后续理解。然后我们就可以在脑海中构思一个大致的流程图。

如果可以运行的话,我们可以跟着运行访问的地址作为消息入口,如果无法启动运行,那么我们需要通过一些特殊的规则定位消息入口:

  如何定义项目的启动文件:

a. 一般情况下启动文件会在根目录下, "start...", "main...", "manager...", "app...", ...开头 

b. 如果在启动文件下找不到,着重看项目部署文档

那么我们找到了入口文件如何理解那一个个新模块文件呢?

  a. 需要从头到尾快速浏览该文件,只关注最外层的代码和类定义

  b. 找到关键代码, 从关键代码跟踪进去(练习理解代码你需要熟练掌握IDE一些工具:shift+Ctrl+find全局查找以及Ctrl+鼠标左键快速查找)

当我们碰到不好理解的新类的时候:

  a. 首先只看类的名字(做啥子)及其构造方法和公有方法

  b. 根据函数名和变量名大胆猜测其用途,和脑海中的信息进行对照

  c. 猜不到再深入跟踪

当你无法简单直接找到类的函数之间如何跳转时:

a. 如果是卡在三方库中,此时打开源码,进行全局搜索 !!!--- 相对较为麻烦,有一定经验要求

b. 抛异常 raise Exception

如何快速理解一个复杂全新的函数?

  a. 快速阅读整个函数的代码,只关注关键模块,注意第一次尽量不要跳转到内部另外的函数,其他的部分混个脸熟。

为什么感觉没有提到注释?

是的,因为所有第一次见到的注释和日志信息仅供参考!!!如果它们的意思和你脑海中的设想比较接近,则权且先相信它是对的,否则当它是错的。因为一个成熟的代码也不会自己更新注释,而一个再成熟的程序员也不可能面面俱到的改动代码后立即更新注释。如果有,请告诉我,我去瞻仰一下。毕竟日志内容也可以是错的。当然,博客内容也有可能是错的,但是我是对的!!

作为新手:善用抛异常的方式去从报错中确认函数由谁调用。

作为新手:善用抛异常的方式去从报错中确认函数由谁调用。

作为新手:善用抛异常的方式去从报错中确认函数由谁调用。