一个工作习惯

突然觉得自己工作处于一种浑浑噩噩的状态。

虽然一直在做项目,也多多少少有一些进度,但是没有给自己制定计划,没有明确自己在某个时间点应该完成到什么程度。

也不是说这种状态就完全是错的。如果我只考虑当前涉及到的业务,把这一部分实现之后再去考虑其他部分,那这样最终也可以完成任务。

我现在觉得这种状态是错的,是因为我深刻体会到了这么做背后的痛苦。我们是根据业务的需求去开发,可以说业务需求决定了我们如何设计这个项目。比如 A 需求,通过方案一可以很好地实现,但是后面发现 A 需求跟 B 模块有关联,现有的方案无法优雅地实现。所以现在算是什么情况呢?现在是需求没变,只是发现了之前遗漏掉的一些关联,导致项目部分代码需要重构。项目都没有做完,就要把一部分代码重构,而且这部分代码没有问题,只是无法满足需求。这实在是一件可笑且可悲的事情。

项目需要重构很正常,但是还没有做完就要重构,那么一定是哪里出了问题。

我们应该在开发之前梳理业务的流程,在梳理的时候应该能够用自己的话说出来,这里的说主要是为了检查自己能否将这个功能进行抽象。进行抽象的好处是让自己能够以更高的视角看待项目,让业务流程看起来更加清晰,本质上就是化繁为简。同样的功能,可能有很复杂的实现,也可能有很简单的实现(注意我这里说的是“可能”而非“可以”)。

对于一项不熟悉的任务,很难一开始就给出合适的解决方案,甚至开始时都无法判断一个方案是否可行。如果说犯错在所难免,那么我们应该尽早的将错误暴露出来:模拟使用某个方案,深入体会该方案是否足够简单,是否完全满足需求。这件事并不简单,因为凭空想象很难,深入到每一个细节也是需要花很多时间的。但是在脑海中模拟完整的业务流程是很有价值的,因为这样做可以最小化试错成本(除非自己对于业务非常熟悉,有过这部分的经验)。

胡说八道了那么多,标题所指的工作习惯究竟是什么呢?其实就是在做一些没有完全把握的功能时,要学会去抽象这个功能,要完整地梳理完业务中的每一个流程,思考它们之间的关系,提出业务中的不合理性,最终给出合理的解决方案。(让一个开发去做这些事情,实在是过分。此外,更过分的是客户的需求可能会发生改变,意味着很多付出都白费掉了,不过解决方法很简单:加钱)

明确自己的任务,将思考和执行分开:前期光是思考,一行代码都不要写。后期光是执行,按照计划实现就好。当任务明确之后,就可以评估任务完成的时间,让自己有目标,也看得到自己完成了哪些任务,而不至于浑浑噩噩不知道要做什么,也不知道做了什么。