一点感想

事情是这样的。
前天晚上九点多，老婆突然来了一条微信，问我能不能做一个年会抽奖的小程序，明天晚上就要。我一想，抽奖嘛，不就是个随机数的问题嘛，简单。头脑一热，就满口应承下来。然后，等坐下来准备写的时候，才发现其实需求还是蛮复杂的，首先是要有个看得过去的UI，然后还要定制每种奖项的抽奖策略，因为各个奖项的数量和抽取的次数是不一样的，还要考虑去重的问题，就是中过奖的人是不能再中奖的，等等等等。最后，还有个很致命的问题：好久没有写Windows程序了，.net控件都忘得差不多了。但是，活已经接下来，就不好意思再反悔了，只能硬着头皮往下干。搞到晚上十一点半，大体的功能已经完成，准备第二天上午再调试优化一下。
忙了一上午，到中午，调试基本完成，就把东西发给了老婆，让她试试，看可有问题。很快反馈意见就来了，其中有一条是”工会X等奖”的工会二字被我打成了“公会”，都不是什么大问题，很快就改好了。到下午5点半，距离年会还有半小时，这个时候又一条微信来了，原来一个有三个“公会”，我只改了俩，还有一个没有改，接着又一条微信：你逗我呢？看到这条，我就习惯性的回了一条：你不也没看到嘛。然后把软件改完又发过去了。
时间来到了晚上8点半左右，老婆的微信又来了，说闯大祸了。原来别人发给老婆，老婆在发给我的抽奖花名册表格有两个表单，我只导入了其中的一个，抽奖的时候观众发现有一个部门一个中奖的都没有，现场就比较混乱。我立马想了一下，还是有补救方案的，只要三分钟，就能保证后面的抽奖不出问题，但是现场的情形已经不允许我有这三分钟了。老婆就怨我搞砸了，我呢，面对老婆的埋怨，习惯性的就把责任推给了发名单给我老婆的那个人，说一个名单还搞俩sheet，也不打个招呼。然后，等我老婆回家，后面的事情大家就脑补一下吧。
大半夜的，想想这件事，有很多方面需要反省一下，对以后的工作生活很有警示作用。

1. 没有一个项目是很简单的。看上去很简单的任务往往也埋有大坑，一不小心就栽坑里了。
2. 在决定要不要接受一项任务时，一定要对任务有足够的重视，不能因为任务简单，就对任务的难度和工作量有过于激进的评估。
3. 在实际编写代码之前，一定要对任务进行分解，对每个部分进行详细的设计，同时，这也是修正之前对工作量错误评估的一个机会（这个时候后悔还来得及）。这个阶段就是软件工程里面的设计阶段，血淋淋的教训证明设计阶段有多么的重要。
4. 对于项目的输入一定要做仔细的审查。输入文件是项目实施的基础，如果基础都出问题了，那么输出一定会出问题。这件事情搞砸的最直接原因就是对输入的名单没有仔细的检查，导致漏掉了一个表单。
5. 在项目的实施过程中，对于自己比较弱的方面，一定要有清醒的认识和重视，因为问题往往就出现在自己不熟悉的地方。平时在工作中，我是做后台逻辑的，很少会做前台UI，所以在做这个抽奖软件的时候，对界面上的文字就没有仔细的审查，导致在“工会”上出了两次bug。
6. 在开发的过程中，测试和开发之间一定要注意沟通的方式。测试和开发都要奔着解决问题的方向去沟通。测试报bug的时候心态一定要放平，就事论事，千万不能有抱怨的成分，因为开发都有很强的自尊心，对自己的代码都很有自信，如果测试沟通的时候不注意语气和方式，就会让开发觉得这是故意挑事，这样是不利于解决问题的。从开发的角度来说，开发人员也一定要保持着审慎的心态，先从自身找原因。测试报了bug，一定是测试觉得有地方实现得不好。测试觉得不好，那客户就也有可能觉得不好。不好的代码是你写的，那么你就有义务去解决这个问题，要么修复这个bug，要么就要跟测试解释清楚，为什么要这样写，有什么其他方面的考虑或者是其他方面的限制只能这么写。大家都是为了把工作做好，没必要去抱怨甚至争执。
7. 重要的事情和环节一定要有备选方案，不能把鸡蛋放在同一个篮子里。就拿抽奖这件事情来说吧，提前就要做好准备，玩意电脑抽奖方案出问题了，就上传统的抽奖箱，保证年会能顺利进行下去。
8. 在决定接不接受一项任务之前，不能只想着完成之后又多少收益，同时也要考虑到万一做砸了，会有多大的影响。这或多或少将影响你的决定。

9. 在项目实施之前或者实施的过程中，如果预想到会有风险，一定要和客户沟通清楚，因为，项目的实施人是你，风险只有你知道。客户选择你，是因为相信你会不折不扣的完成任务，如果你不告知客户风险点的存在，等到最后真的出问题了，客户会因为没有备选方案而导致全盘失败，同时，造成的损失就得全由你来背。

   戒之！戒之！戒之！