1.谈谈如何看源码
个人觉得拿到一个开源的项目，首先要先使用一下。
如果是有页面的那种，可以先把测试平台部署起来，然后到处随意点点，然后用一下最基础的功能，走一遍基础的使用流程。不用担心会把系统弄坏，弄坏了说明没有配置好或者本身代码有bug，这时候可以尝试先自己解决一下，如果能解决是好的，如果不能解决，那就更好了，因为这个时候会激发出你的好奇心，好奇心会驱使你有更浓厚的兴趣去研究源码。
如果是没有页面的，比如服务器软件或者中间件等，那么也是先使用一下这个软件最基础的功能。
对这个软件有一些了解之后，我们就可以开始自己想想，如果是自己去实现这个软件的某个功能点，比如调度系统举例的话，调度系统是怎么拉起linux进程来执行程序的，执行完成程序后是如何获取结果和执行过程中的日志的。这些都可以自己想一想，想的时间越长，你会越好奇这个软件是怎么实现的。这个时候其实你就有了一个切入点，有个切入点去看代码，就像在一个陌生城市行走突然有了地图一样。你会把不相干的代码暂时跳过，只看对解决我当前的疑问有帮助的那些代码。这时候，一个有上千个文件的工程此时与你相关的就变成数十个了，你只需通过这个切入点来看明白这数十个对解决你当前疑惑有直接帮助的源代码文件就好了。
2.谈谈对DolphinScheduler平台的一些疑惑
最开始使用这个平台时候，我相信很多人和我一样，会先建立一个项目，然后拉一个最简单的shell节点先执行一下。执行成功后会生成一个成功的运行实例。实例点开是能看到此次执行的日志的。
就这么简单的一个流程，我就比较好奇在几个点：
1 ）这个调度平台是怎么拉起一个linux进程的？
2 ）这个调度平台如何获取执行的结果和日志的？
3 ）这个调度平台的前后台是如何交互的？前台的一个shell节点存储在数据库是怎么样的一个结构。
4 ）如果有很多的依赖，是如何存储和解决这些依赖的？
5 ）这个号称分布式的调度系统，是如何保证高可用的？
以上这些是我最初的时候想到的一些疑惑，所以我就决定带着这些疑惑，作为一个个切入点，去解决掉，并要求自己一定要写为每个问题写一篇文章记录一下揭秘的过程。因为我相信我现在走的路，很多后来的人都会再走一遍，如果有走过的人写一下记录一下，应该会好很多吧。我们后边见～～～