项目致命的灾难莫过于几种,我碰到了其中一种,无论是谁碰到这样的事情都会很懊恼,这的确是一次痛苦的经历,究其原因我认为是沟通问题,连带我最近碰到的小事一件,谈谈我对团队合作和项目心态方面的想法。 事情是发生在一次紧急变更的时候,提取数据库的方法被拆分成了两部分——缓冲查找和数据库查找,这要求调用者在使用的时候做限制(至于为什么不把这两个方法封装成一个,是因为项目的特殊性不得已而为之),拆分方法的时候使用者也在线,大家约定修改行为。 最终还是出问题了,调用者修改了调用方式,但只是适合新的数据库查询方式,并未缓冲优先。这件事情让我十分懊恼,但是事情已经发生了,只得大家道一句交流不善。于是我想到了交流与事必躬亲。 在一个团队中,你应该相信自己的伙伴。做一件事情,什么事情都自己做,最终你会很累,还容易因为个人精力有限而除岔子。 问题在于,对于约定的事情,谁去做检查?对于一个人做很多事情,如何不落下来任何细节? 其实这两个问题是一个问题,如何处理繁多的细节而不出问题。这包括自己的工作和别人的委托。 为了弥补这个buf带来的问题,我做了一个小工具,刚开始我觉得也就几行代码的规模,为了尽快完成,我使用魔术数字,我觉得它可以一目了然。当你决定了一件事情后,你就作出了一个选择,而这个选择往往不是凭第一感觉就是完全正确的。是的,我做了一个糟糕的选择。 使用了魔术数字和草率的思想,我失去了模块化和封装性,当考虑细节逐渐增多的时候,思维的负担、开发的难度和可维护性变得无法被提及。 我终于做了个决定,正视我的敌人,软件无大小,看你心态。事情变得好了很多,这个工具我后来变了3次需求,都没有引发任何问题,也没有修改负担。 项目无大小,都要正视,所以你要用系统开发的规格要求你的开发,这样就出了问题,如此大的规模,如何控制不落细节。 我想一个比较好的办法是流程和规范。 1.不允许无法回溯的行为发生,对你的个操作负责。 文章:来源 (win2ks) |