今天早上到公司后打开需求网页发现前两天聊到的已经分派给别人的需求开发分派到了自己的名下,本来有点奇怪,组长说为了赶进度,所以就让我做了。在这儿我想吐槽一句,组内有十来个人,除了三四个测试人员,其他人都被分配在开发组,但实际上有开发能力的人没几个,每次就是来那两三个人在写代码,我偶尔也被分几个优化需求。其实今天的这个优化需求很简单,只要有点编程基础的人都能在一两天内完成,我是今天刚上午刚拿到,今天下午下班前就把方案上传了,同时代码修改工作也已经完成,只是没来得及测试。我不明白这么简单的东西这些人为什么总是学不会。接下来记录一下今天的代码优化总结:
首先是需求描述:
有一个新的功能要上线,关于这个功能需要做一些放开校验的修改,而且是只针对这一个功能放开校验,代码修改不能影响到已有的功能。
接下来是需求分析:
刚开始我对这个模块的业务逻辑并不是很了解,因为这个模块之前是由别人来维护的,所以我自己先根据自己的经验看了下代码,然后有了一个初步的修改方案。但是这个时候我并没有着手开始修改,我先去跟之前维护这个接口的同事沟通了一下,同事也进一步了解了一下这个需求的相关问题,以及之前代码的逻辑。聊得过程中,这个同事告诉我说,在这个模块的逻辑中有一个和本次要求的变更很相似的流程,只要根据这个思想直接复制一套相似的流程就能达到修改的目的。经过他的点拨之后我回去又看了一下代码逻辑,同时结合他说的地方仔细看了一下,发现确实如他所说。而且他的这个方案比我刚开始设想的方案更优,也能省去很多麻烦的数据处理。所以我果断地更换了涉及方案。重新设计了一下,然后编写了方案。
第三步是着手修改代码:
刚才已经说过了,需求不是很麻烦,再加上已经有了现成的设计思路,代码中之前已经做好了涉及,所以代码修改工作很快就完成了。
第四步是整理实际方案,编写测试文档。
就这样一个简单的需求就搞定了。其实这个过程很简单,首先自己理解需求的意思,如果有不懂的地方就能相关负责人沟通,动手之前一定要确定好功能具体要求,每个细节。然后自己先根据经验设计一个初步的方案,之后在跟有经验的同事沟通了解一下,有时候这样会帮你省去很多麻烦,也能学到一些不同的设计思想,拓展自己的思维。沟通很重要。