沟通与事必躬亲

项目致命的灾难莫过于几种，我碰到了其中一种，无论是谁碰到这样的事情都会很懊恼，这的确是一次痛苦的经历，究其原因我认为是沟通问题，连带我最近碰到的小事一件，谈谈我对团队合作和项目心态方面的想法。

 事情是发生在一次紧急变更的时候，提取数据库的方法被拆分成了两部分——缓冲查找和数据库查找，这要求调用者在使用的时候做限制（至于为什么不把这两个方法封装成一个，是因为项目的特殊性不得已而为之），拆分方法的时候使用者也在线，大家约定修改行为。

最终还是出问题了，调用者修改了调用方式，但只是适合新的数据库查询方式，并未缓冲优先。这件事情让我十分懊恼，但是事情已经发生了，只得大家道一句交流不善。于是我想到了交流与事必躬亲。

在一个团队中，你应该相信自己的伙伴。做一件事情，什么事情都自己做，最终你会很累，还容易因为个人精力有限而除岔子。

问题在于，对于约定的事情，谁去做检查？对于一个人做很多事情，如何不落下来任何细节？

其实这两个问题是一个问题，如何处理繁多的细节而不出问题。这包括自己的工作和别人的委托。

为了弥补这个buf带来的问题，我做了一个小工具，刚开始我觉得也就几行代码的规模，为了尽快完成，我使用魔术数字，我觉得它可以一目了然。当你决定了一件事情后，你就作出了一个选择，而这个选择往往不是凭第一感觉就是完全正确的。是的，我做了一个糟糕的选择。

使用了魔术数字和草率的思想，我失去了模块化和封装性，当考虑细节逐渐增多的时候，思维的负担、开发的难度和可维护性变得无法被提及。

我终于做了个决定，正视我的敌人，软件无大小，看你心态。事情变得好了很多，这个工具我后来变了3次需求，都没有引发任何问题，也没有修改负担。

项目无大小，都要正视，所以你要用系统开发的规格要求你的开发，这样就出了问题，如此大的规模，如何控制不落细节。

我想一个比较好的办法是流程和规范。

1.不允许无法回溯的行为发生，对你的个操作负责。
2.事无大小都要记录，如果可以，要有完整的检查体系，记录做到有据可查。
3.及时记录你的想法，及时处理你的记录。
4.做好沟通，重点强调清楚，一定的检查机制是必要的，不一定躬亲，但检查责任要交代清楚。