如何熟悉业务？ # W09

前面计划了“熟悉业务”的整体安排，现在来从技术上讨论一下，应该如何有条理、有节奏地熟悉业务，并在部分方面深入代码细节，掌握核心实现。

同时将这些形成技术文档，供团队查阅。

困境是什么？

CRM类型的业务在细节上非常复杂，由于没有实现文档，很多时候一头扎进代码，会被高度抽象没有注释的代码搞的一头雾水，由于产品本身的复杂性很高，代码的实现本身就是细节魔鬼。 所以，从数据模型上去梳理出核心脉络不是好的选择。同时，由于系统本身是个超级单体应用，所以没有一个人能掌握全貌，通过口头请教别人快速掌握系统也是不现实的。很多时候，你甚至不知道自己要问什么，如何持续深入地提问。

该如何进行？

人在很多时候，会无意识地扎进当前的所处的环境中，难以自拔。对于程序员来说，最先拿到的就是代码，然后想当然地就去看代码，看着看着就不知道自己在干什么了。 所以首要的事情是将自己从当前的环境中抽离出来，再来思考如何来熟悉业务这件事情。

产品的生产过程是，产品概念设计->产品需求细化->程序员与产品经理沟通->程序编码，从这条线来看就能大概清楚该如何去熟悉一个产品了。 首要做的就是分层，从产品层到代码层逐层递进。 

执行广度优先算法，再针对个别核心点进行深度优先算法。

第一层， 先从产品经理的角度去掌握这个产品本身是什么，产品有哪些模块，各个模块之间的关系。

第二层， 每个模块中子模块及其特性。

第三层，根据第二层特性，梳理代码的核心实现脉络，核心模型的抽象。

第四层，根据核心抽象，梳理实现细节及关键技术点。

按照层级依次进行，则可以实现有条理、有节奏地熟悉业务，形成文档后，便可收益无穷。

如何落实到行动？

上面已经梳理出熟悉业务的脉络，那么应该在实际情况中进行有效实施呢？  依然需要分层进行。

1. 首先找产品经理要产品文档。如果不能获得产品文档，则自己到产品上按照广度优先的策略梳理出产品结构。
2. 请教产品经理，让他们推荐一些工具，或者方便进行产品结构化呈现的经验。通过这两步，勾勒出第一层和第二层。
3. 挑选出部分重要的模块，请教相关熟悉代码的人，梳理出功能实现的核心脉络和使用到的工具。
4. 深入细节。透彻掌握部分核心功能的实现。

整个过程应该会持续数月，过程中，通过自己做示范作用，吸引更多的人参与进来，这样能在效率和质量上有很大提升。

有什么价值？

明白对应的价值，会在很大程度上激励我们克服困难，不断前行。 

1. 能进行系统重构
2. 出现故障能更快进行响应
3. 新人进来可以在更短的时间内贡献生产力
4. 价值正反馈

能够很清晰地知道，这件事情是非常重要，也是非常紧急的，价值无穷。