《代码大全》 读书笔记 ——需求篇

       最近基本上都在用挤地铁上下班的零碎时间去看一些有营养的书。看不了多少，只能截几个屏回来慢慢消化。看到一些觉得很有意义的话就记录了下来。

       软件开发的水塘隐喻：

      书中把一个正常的、高效的软件开发流程比喻成了一条健康的是食物链，比如在一片水塘中，一级级往上走迟到的也都是健康的食物。而不合理的开发流程就等同于一条不健康的食物链，在这样的食物链中，从食物链的下游生物就已经受到了污染，最底层的差不多就是我们的需求部分了，如果需求都被污染了，则会污染影响到整个架构，架构紧接着就会污染构建，使得最后程序员开发的时候也脾气暴躁，怨声载道。。而且开发出的成员也可能浑身都是BUG。

      实际工作中，我们见到的被污染的需求真的都已经司空见惯了。你会觉得这很正常，项目经理或策划的需求改来改去非常正常。我在被这样的“情形”磨砺了几个月之后，也越来越习惯。但是真的认真想一下，我们程序员真的只要是项目经理该需求就难过的不得了吗？其实并非如此，我们难受的，往往是那些从出生开始就带着“污染”的需求，也就是有问题的需求，这样的需求也会直接使得后面有优化不完的代码和后知后觉的BUG。

      学习成长的这段时间，也越来越觉得。其实我们今后在面对有质疑的需求的时候，更需要第一时间沟通清楚，不仅为解决问题预留空间和设计上的通用性，也更加为了避免那些基本的错误。

      通过需求核对表来检查我们的工作做的如何：

      其实书中关于功能性需求与非功能性（性能）的需求都定义了有很多，我只是摘录了我个人目前遇到容易欠缺的和我认为最基本的一些点。

      1.  针对功能需求

• 是否详细定义了系统的全部输入，包括来源、 精度、取值范围等；
• 是否详细定义了系统的全部输出，目的地、精度、取值范围、格式等；
• 是否定义好所有的软硬件接口；
• 是否列出了用户所有想做的事情； 

      2. 需求的质量

• 需求是否通过用户语言来描述的？用户也是这样想的吗？
• 需求之间是否存在冲突；
• 需求是否清晰；
• 每条需求是否都是可测试的，能进行独立的测试？

     关于需求的那些话

•      如果没有好的需求，你可能对问题有总体的把握，但是没有集中问题的特定方面。   ——但是这些特定方面，却往往可能是这个问题的关键点，遗漏这些点，不仅会成为我们今后工作中很重要的一个死穴，也让自己的工作不仅辛苦，还可能有较低的回报率。
• 
  

create： 2014-9-29 23:38:00

add：2014-10-2 15:01:45