今天这篇文章一行代码都没有请放心阅读。
无论是换工作,换团队,还是换业务,我们都不可避免地会接触新的项目,甚至可能接触一个大型的项目。很多人,包括我自己,在面对这一整个庞大的工程的时候,未免会感觉到有点力不从心,有点焦虑,因为毕竟是一个全新的东西,它有自己的生命,自己的问题,自己的功能,自己的架构。
我经常在想,有没有一套方法,可以让我们快速进行项目工程呢?
答案是有的,最近逐渐在脑子里成型。
项目工程,我们不外乎关注这么几个点。
1、这玩意干啥的?怎么做到的?
2、这玩意我咋上手?
3、这玩意我改得动吗?不会崩吗?
很遗憾的是,很多人其实只关注了第二点,也就是我经常说的 ctrl c + ctrl v 工程师。很多的时候你并不知道为什么这样写,为什么只能这样写,当时为什么会这样写。听过一个笑话,就是你觉得一坨代码很烂,但是你深思熟虑后,觉得也只能这样写了。
我们关注的几个点要怎么到达呢?我建议是这么一个路径去达到。
首先,咨询原来的开发者,得到整个项目的背景以及项目的历史,和各个部分的关系。这一步,我们可以在脑子里有个大概,但是很显然一个组件都记不住,关系也记不住,但是没关系,我们来到第二步。
这个时候,你脑子里必然是一脸懵逼的,我们的经验和大脑本能地告诉我们这事情是行不通的,但是别人又说这是行得通的,这在我们脑子里就很矛盾,你需要一些证据给你的大脑证明这是行得通的。所以这时候你需要一个 quick start,也就是 ctrl c + ctrl v 按照前辈的经验自己写一个小功能,也就是一个证据,一个就够了。接下来就开始分析我们的需求改动点应该是哪里了。
这玩意我改得动吗?这是我们的脑子给我们的第三个信号,它在不熟悉一个东西的时候,会本能地拒绝任何的变更。所以在这个阶段,源码阅读是我们必不可少的一个步骤,特别是在项目开发的过程中,我们要依靠第一步的系统关系,以及我们已经认知的业务流程,把项目代码啃下来。就是我们已经知道有ABCDE子系统以及他们的大概关系,利用这个关系,像编织篮筐一样,按照设计的方向慢慢看清整个项目。
阅读源码的过程 以接口和消息机制为入口,仔细梳理某个流程的完整调用链,并把它扩展到其他的调用过程里面。相信我,绝大部分的代码都是增删改查,你要了解的事情是,这是在哪查的,在哪改的,在哪删的,在哪增的,这就够了。至于业务流程本身,或者逻辑判断,有个大概的认识就好了,第一遍阅读主要是认一认各个系统各个数据结构之间的关系,让你的脑子知道这玩意是怎么跑的。
基于第一次阅读的认识,我们再反向观察整个项目结构,这时候的你不仅有信心,而且知道项目整体情况,对于各个部分的细节也有一定的认识,你的项目眼界不知不觉中已经提高到一个架构师的基本。这时候的你必然能得到你所负责需求的改动,以及对于全局的影响。
大系统就是这样,牵一发而动全身。
共同学习,写下你的评论
评论加载中...
作者其他优质文章