前言
个人总结，阅读代码有以下4大线索：
1.线程线 ：线程线索的简称，观察创建了多少个线程，以线程运行流程的角度理解程序。
2.数据线 ：数据结构线索的简称，观察创建了多少个全局变量或对象，以数据流向的角度理解程序。
3.通信线 ：通信线索的简称，观察有哪些通信方式，以通信传递流程的角度理解程序。比如信号量、互斥量、消息队列、管道等IPC通信方式;比如调用回调函数、调用别的对象的方法;再比如全局变量，几个模块通过全局变量进行通信和交流。
4.业务线 :业务线索的简称，以业务为主线把线程线、通信线、数据线串起来以业务为单位以点攻面理解程序——即只抽取该业务的线程、数据、通信的运行流程理解程序。——这种方式，眼中的程序是一个个业务的集合——业务是组成程序的最小单位，业务是程序分割的最小单位。
正文
阅读代码的时候有没有这样的困惑：为啥要有这样子的线程？为啥要有这样子的通信？为啥要有这样子的数据结构？你要是单独以这些线索去看的话，对程序的理解是有偏颇的——总是不能完整把控——后来发现需要一个灵魂或者说主线统领它们——以业务线为主线为统领把它们串起来就好了 ——因为代码的设计者也是围绕业务展开的，一切因业务需要而诞生。 所以要以业务的角度来看代码。
操作系统下编程和走读代码，不可眉毛胡子一把抓什么都看，需要用业务线的方法来设计和走读代码。
业务线索统领了线程线索、数据结构线索、通信线索等线索，那么先把它们的概念和作用搞清楚，以掌控它们的角色和职责。
1.业务是啥？ 业务可以理解成客户需求，或者某个功能块——往往需要依赖线程、数据结构和通信的配合而实现的一个功能块。
2.线程是干啥的？ 干活的！一个个线程就是业务开展所需的一个个苦力——都是某个角色，有一定职责——然后，然后——给我干活去！
3.数据结构是干啥的？ 是业务承载的信息，是线程干活要处理的对象。好的数据结构设计干活事半功倍。
4.通信是干啥的？ 业务流转所需的，需要通信时而采用。
我提倡从业务线索的角度来走读代码，聚焦到一个一个业务线上来把控整个程序！如果你阅读代码的时候不以业务为线索把线程、通信、数据结构等串起来，而是眉毛胡子一把抓，那么你会越看越乱不知所云，浓雾弥漫，本末倒置。因为代码是按照业务实现进行的设计——实现业务需要线程，那就创建线程！一个不够，那就再来一个！还不够再来！直到满足业务需求。实现业务所需要的数据结构不满足，那就创建新的数据结构！实现业务还需要通信！那就搞！以业务为中心为主线，你才能平视代码设计者，回溯代码设计者的设计思路，与设计者进行灵魂交融，深入理解其设计的灵魂，才能掌控它，并具有重构它的能力。
例如，聚焦A业务，看看设计者为了实现A业务都创建了哪些线程？哪些数据结构？哪些通信方式？观察A业务的初始化、运行的流程——即观察其对应的线程、数据结构、通信等初始化、运行的流程并画思维导图或者别的图——注意只抽取A业务相关的线程、数据结构、通信来看，这样的话可以屏蔽无关信息的干扰。
这样一条一条业务线的观察，那么所有业务线的集合就是整个程序（分久必合合久必分）。
这样就做到了从局部把控到整体的把控。
而且在这过程中也能了解到该业务设计者当时设计时的想法（设计思想）、限制与BUG。
代码设计同样以业务为核心来设计。
该方法的关键是：聚焦到一个个业务上！剖离和该业务无关的一切信息，以单个的业务为线索把相关的一切（线程、数据结构、通信等）串起来，进行纯粹的观察与设计！以点破面的思想。
小结：业务线就是把程序分解成一个个业务，业务是组成程序的最小单位。从程序中扣出一个个业务，各个业务有各自的地盘，各自独霸一方，地盘里包裹着该业务对应的线程、数据、通信等代码，这样可以对各个业务进行进行精准分析与设计，所有业务的集合就是完整的程序。
后来思考
1.面向过程下，观察业务，从业务所需的全局变量为切入点，查看实现该业务用到了哪些全局变量或者全部变量的哪些成员，搜索这些成员是怎么被用的，那么就会发现通信手段是啥（是IPC通信还是回调函数或其他？），也能发现在哪个线程中处理的（该线程就是该数据的活动范围——溜达溜达），那么线程就引出来了（一个线程能干的活太多了）。然后就会知道整个的业务运转的动态图。
2.面向对象下，观察业务就是从对象作为切入点，看对象如何发生改变的，哪些通信方式导致，在哪个线程中改变的（该线程就是该对象的活动范围——溜达溜达），
