一个教训（以前的一断痛苦经历总结）

教训_20070626

大概三个星期之前，加入我的第三个项目，分到了两个功能模块的改造任务。现在做的是第一个：workflow的后台批处理，对所有延期未能完成的task的责任人和相关管理者发mail。需要做的是改变收件人和信件内容——对不同的收件人发不同的邮件，而不是给所有人同样内容的邮件。

调查了一番，最有后认定需要改动的只有几个部分：收件人地址设置，把统一设置修改为分别设置；重新设置异常处理的判断条件；添加额外的资源文件项目和相应的key值。

看上去很简单吧？我也曾这样以为，而这，就是我痛苦的开端！

现在，按照工程表。单体测试书review都应该结束了，而我才刚刚把代码调试通过。延迟——所有程序员都不愿看到的字眼。为什么？如果我能恰当的回答这个问题，若干天的加班也算值了。

淹死人的水坑，可能看着不大，其实深着呢！

我不止一次的告诉自己：项目前期做的工作再多再细都不过分，我还真是自己抽了自己一耳光！

本以为当抓到了“主干”时，那些边边角角的问题可以先放一放。但是有的问题从表面上看是“细枝末节”，真要顺着这个线头揪下去，能揪出一嘟噜一嘟噜的麻烦。仍以现在这个项目为例。按照客户要求，在每封信中都要包括责任人和管理者的姓名。大概也是我的经验不足，我以为了解了送信的整体过程，这个信件具体内容的问题还不是小菜一碟。结果，当我把详细设计做的差不多了才发现，因为这个被轻视的问题，我辛辛苦苦搭起来的骨架不得不重新设计结构。这个在邮件内容中不过只占两个词的东西，需要我从后台数据库一直折腾到写入到正文中，这个过程还要进行判断、转换、格式化等等处理，所以返工，所以延迟，所以痛苦。

综上，在项目开始时，千万别忽视任何看起来不起眼的细节，它的“不起眼”很可能仅仅是“看起来”而已。