话说祥林嫂自从应聘于鲁迅的＜呐喊＞公司后工作很不顺利-read.docVIP

祥林嫂编程记 一、系统测试 话说祥林嫂自从与比他小十来岁的祥林合作开公司后，工作很不顺利。他们的第一个项目husband就由于没有经过系统测试，在向客户演示时失败。由于这次失败，导致他们公司破产，丈夫祥林气血攻心而死。 多年以后，她遇到了＜呐喊＞公司的老板鲁迅。鲁老板是当地有名的海归，创业成功者。 “本来，所有演示项目都结束了，但最后退出时却出了问题，死机了。”祥林嫂说，“我真傻，真的。单注意各个演示项，没注意退出时的处理。” “你们有没有做系统测试？”鲁老板问。 “。。。没有。。。”祥林嫂说，“没有时间，刚做完就要演示，没办法”。 “那就难怪了。”鲁老板抽了一口烟，说：“我们呐喊公司从第一个产品开始就有了测试部。所有产品，包括演示版本，都要经测试部按要求的测试项测试后才能发布。产品不经过测试，就拿到客户那里去，怎么能不出问题呢？” 二、需求收集与分析 祥林嫂破产后，他们的母公司要把她卖给另一家公司，老板叫贺老六。但那家公司给的待遇很差，于是她就自已出来，到镇上鲁四的公司里打工。在这里，她工作得很快乐。但没过多久，她原来公司竟然以她“带走公司机密”为由，带一些保安，直接把她强行带到了那家新公司。 祥林嫂经过一段时间，竟然也慢慢适应了这家新公司。新公司看她工作努力，还让她当了项目经理。 新公司做的还是＜husband项目。祥林嫂把原来公司的东西再捡起来，补好了退出时内存异常访问这个漏洞，并添加了一些新功能。他们终于找到了第二次机会，又参加了演示。但是很不幸，客户这次要求自已操作，结果发现他们很感兴趣的一个功能的某种重要情况没有实现，而竞争对手却实现了。情况看来很糟糕。 经过这次打击，她所在的新公司也出现危机了。 “唉，事情太匆忙。再说，我又怎么能想到这一点呢。我连局方机房都没去过，局方的应用场景都不清楚。”祥林嫂后来遇到鲁迅时无辜地说。 “公司应该是以客户的需求为导向的。你们在开发前有没有认真地做需求分析呢？”鲁迅问祥林嫂。 “没有。我们都是开发人员直接做需求分解的”。 “那就难怪了。”鲁老板抽了一口烟，说：“我们呐喊公司从第一个产品开始就有了系统部。系统部专门从事需求收集和分解、版本路标规划、系统架构设计与规划等工作。系统部是联系研发与市场、用服的纽带。” 三、第一个版本 这次事件后，公司尽管元气大伤，但还是积聚所有力量，成立了系统部。系统部专人经市场人员引导和陪同，到局方重新了解和确认了需求。发现局方的需求和她们最初想的还是有些不一致的地方。并且发现，局方的维护人员积极性很高，替她们出了不少好建议。于是公司规定，对个好建议计一分。每季度评比，对评分高的局方人员评奖。于是局方员工对公司的亲合度大增。 同时，这些建议被记录入库，由系统部的人员分析，最后每季度都被选出些实用且可行的来，分析后纳入版本计划。 系统部对整个＜husband项目重新进行了需求分析，增加了好多新需求。但迫于市场压力，只好拿出一部分基本功能来，要求第一部分实现。剩下的部分功能在后续版本中实现。他们称这个为迭代开发。 开发中，祥林嫂熬夜过多，以致头晕眼花，有一次不小心撞到办公室的柱子上了。好了后，额头上留下了疤。 经过努力，终于，她们的第一个版本顺利通过了测试，受到了局方的好评。公司收到了第一笔回款，但大部分用来偿还债务了。 四、第二个版本 她们再接再厉，努力开发第二个版本。这中间她们非常忙碌，经常加班，然而她反满足，口角边渐渐的有了笑影，脸上也白胖了。 她们在分析第二个版本所要完成的功能后，认为需求实际极其庞大而复杂。当初的设计有些过于简单。于是把系统分成了两部分，一个是Client端，一个是Server端，并添加了人手。祥林嫂负责Server端，另一位员工负责Client端。 “幸亏彻底地做了次架构调整。要不然，以后再慢慢添加这么多功能，系统根本就不可能受得了。单模块复杂度太高，我的水平也不会够。”祥林嫂后来对鲁迅说。 祥林嫂继续加班加点，终于赶在计划进度前完成了自已模块的任务。于是进行联调。 结果发现，联调效率很低。不是自己这方出问题，就是对方出问题。而且，更要命的是，一方出问题另一方就只好在旁边等待。 “你们联调前有没有做单元测试呢？”鲁迅问。 “单元测试？以前没做过，会很麻烦吧。” “那就难怪了。”鲁老板抽了一口烟，说：“在联调前一定要做单元测试的。以确保各自的模块不会有一些低级的错误。另外，有些异常情况也不是联调所能模拟的。我们呐喊公司从第一个产品开始强调单元测试。” “你们用什么工具做单元测试？”祥林嫂问。 “RTRT。”鲁迅说。 等联调完成后，他们提交了。这时项目已经延期了3周。再经过两周测试，局方才收到版本。 五、第二个版本提交。 因为有了前一个版本的基础，局方就直接扩容了。 但是，局方这次只回款了30%。另外60%要在三个月试用后初检合格后