前面计划了“熟悉业务”的整体安排,现在来从技术上讨论一下,应该如何有条理、有节奏地熟悉业务,并在部分方面深入代码细节,掌握核心实现。
同时将这些形成技术文档,供团队查阅。
困境是什么?
CRM类型的业务在细节上非常复杂,由于没有实现文档,很多时候一头扎进代码,会被高度抽象没有注释的代码搞的一头雾水,由于产品本身的复杂性很高,代码的实现本身就是细节魔鬼。 所以,从数据模型上去梳理出核心脉络不是好的选择。同时,由于系统本身是个超级单体应用,所以没有一个人能掌握全貌,通过口头请教别人快速掌握系统也是不现实的。很多时候,你甚至不知道自己要问什么,如何持续深入地提问。
该如何进行?
人在很多时候,会无意识地扎进当前的所处的环境中,难以自拔。对于程序员来说,最先拿到的就是代码,然后想当然地就去看代码,看着看着就不知道自己在干什么了。 所以首要的事情是将自己从当前的环境中抽离出来,再来思考如何来熟悉业务这件事情。
产品的生产过程是,产品概念设计->产品需求细化->程序员与产品经理沟通->程序编码,从这条线来看就能大概清楚该如何去熟悉一个产品了。 首要做的就是分层,从产品层到代码层逐层递进。
执行广度优先算法,再针对个别核心点进行深度优先算法。
第一层, 先从产品经理的角度去掌握这个产品本身是什么,产品有哪些模块,各个模块之间的关系。
第二层, 每个模块中子模块及其特性。
第三层,根据第二层特性,梳理代码的核心实现脉络,核心模型的抽象。
第四层,根据核心抽象,梳理实现细节及关键技术点。
按照层级依次进行,则可以实现有条理、有节奏地熟悉业务,形成文档后,便可收益无穷。
如何落实到行动?
上面已经梳理出熟悉业务的脉络,那么应该在实际情况中进行有效实施呢? 依然需要分层进行。
- 首先找产品经理要产品文档。如果不能获得产品文档,则自己到产品上按照广度优先的策略梳理出产品结构。
- 请教产品经理,让他们推荐一些工具,或者方便进行产品结构化呈现的经验。通过这两步,勾勒出第一层和第二层。
- 挑选出部分重要的模块,请教相关熟悉代码的人,梳理出功能实现的核心脉络和使用到的工具。
- 深入细节。透彻掌握部分核心功能的实现。
整个过程应该会持续数月,过程中,通过自己做示范作用,吸引更多的人参与进来,这样能在效率和质量上有很大提升。
有什么价值?
明白对应的价值,会在很大程度上激励我们克服困难,不断前行。
- 能进行系统重构
- 出现故障能更快进行响应
- 新人进来可以在更短的时间内贡献生产力
- 价值正反馈
能够很清晰地知道,这件事情是非常重要,也是非常紧急的,价值无穷。