工作再体验-软件工程篇

在上篇文章《工作初体验-软件工程篇》中，简单说了自己对软件工程的一些体会，现在继续侃侃。

需求分析。在工作中会经常遇到客户无休止的提出新的需求，这个时候我们该怎么办呢？软件开发者和客户始终存在着矛盾，客户肯定想花越少的钱获得越多的功能。不过我们要让客户明白：软件开发人员的精力是有限的，不可能开发出功能无限的软件。不过一个优秀的公司，必定是谦虚的、内敛的，我们当然不能直接拒绝，而是要很有艺术。这样有时肯定不行，所以必须在合同中严格说明维修范围、功能、性能等。另外在《工作初体验-软件工程篇》中提到开发方应充分引导客户提需求，把需求分析的主动权放在自己的手上。不过怎么样才能充分引导客户提需求呢？要达到这种程度，必须比客户更了解客户的业务,比客户更知道客户的所需。事实上，当你比客户更了解客户的业务，比客户更知道客户的所需时，就可以剖析客户的业务，发现其中的不足，为客户提供与之配套的技术解决方案。

设计。在《工作初体验-软件工程篇》中我提到任务要自上而下，产品要自下而上，这是“嫦娥一号”总指挥在今年的IT两会上说的。任务要自上而下：模块式开发方式非常符合这个构思。对于一个软件产品，非常仔细地自上而下地进行分析。每分析到一个逻辑上非常清晰的模块的时候，就停下来，把这个模块交给个人或团队去做。产品要自下而上：如果让我们做一个软件产品，我们肯定不能完成；不过如果让我们做其中的一个模块，我们可能可以；如果还不行，让写一些类总可以吧！就这样自下而上，软件产品出来了。其实现在web2.0的产品也很符合这个idea：产品要自下而上。

测试。最近公司在培训自动化测试，用的工具是Borland的SilkTest，在测试JFC--PageList中简单使用了一下SilkTest，功能还挺强大的。待续...

(补)记得在一个同学的QQ签名上看到：应用工程师=测试+全面知识+沟通。我认为其中的"全面知识"就是对业务知识的掌握，现在社会需要的开发人员既能在技术能力上突出又要能够精通业务，打个比方，他们就是士官，既能指挥小组，也能打仗，没有业务理解和分析能力、纯粹的编码人员将被淘汰。在我们公司比较明显，领导相对来说更倾向于能在业务和技术能力上同样突出的技术人员。这点也印证了我刚才在需求里面所说的，如果对业务知识很熟悉，那么在制作需求说明书的时候主动性很大。所以说，测试也应当由对业务比较熟悉的人来做。当然如果用户能充当这个角色，那就太好了。