关闭

一个教训(以前的一断痛苦经历总结)

226人阅读 评论(0) 收藏 举报
教训_20070626
大概三个星期之前,加入我的第三个项目,分到了两个功能模块的改造任务。现在做的是第一个:workflow的后台批处理,对所有延期未能完成的task的责任人和相关管理者发mail。需要做的是改变收件人和信件内容——对不同的收件人发不同的邮件,而不是给所有人同样内容的邮件。
调查了一番,最有后认定需要改动的只有几个部分:收件人地址设置,把统一设置修改为分别设置;重新设置异常处理的判断条件;添加额外的资源文件项目和相应的key值。
看上去很简单吧?我也曾这样以为,而这,就是我痛苦的开端!
现在,按照工程表。单体测试书review都应该结束了,而我才刚刚把代码调试通过。延迟——所有程序员都不愿看到的字眼。为什么?如果我能恰当的回答这个问题,若干天的加班也算值了。
淹死人的水坑,可能看着不大,其实深着呢!
我不止一次的告诉自己:项目前期做的工作再多再细都不过分,我还真是自己抽了自己一耳光!
本以为当抓到了“主干”时,那些边边角角的问题可以先放一放。但是有的问题从表面上看是“细枝末节”,真要顺着这个线头揪下去,能揪出一嘟噜一嘟噜的麻烦。仍以现在这个项目为例。按照客户要求,在每封信中都要包括责任人和管理者的姓名。大概也是我的经验不足,我以为了解了送信的整体过程,这个信件具体内容的问题还不是小菜一碟。结果,当我把详细设计做的差不多了才发现,因为这个被轻视的问题,我辛辛苦苦搭起来的骨架不得不重新设计结构。这个在邮件内容中不过只占两个词的东西,需要我从后台数据库一直折腾到写入到正文中,这个过程还要进行判断、转换、格式化等等处理,所以返工,所以延迟,所以痛苦。
综上,在项目开始时,千万别忽视任何看起来不起眼的细节,它的“不起眼”很可能仅仅是“看起来”而已。
 
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:782次
    • 积分:42
    • 等级:
    • 排名:千里之外
    • 原创:2篇
    • 转载:0篇
    • 译文:0篇
    • 评论:0条
    文章存档