有病呻吟(二)

     [关于需求]

      需求应该记录下来。但是很多需求在通过语言表达的过程中被发现并不复杂，于是很多程序员的选择是把它们存储在大脑芯片里。这样可能会节省很多时间。然后一旦出现人员流失或者需求变更的情况，那么它就会显得非常混乱。要知道用户可不想一次又一次的回答同样的问题。我曾经给众多的客户充当过开发顾问的角色。他们总是向我抱怨，项目团队的开发人员总是一次又一次的问他们同样的问题，而理由是上次那个信誓旦旦的家伙离开了。听起来真是糟糕，不是吗？是的，我们确实需要记录需求。但不一是把它们都存放在WORD文档里，记录需求的方式有很多，你可以把他们写在WORD文档中，也可以把他们编写成剧本，或者顺手绘制的可以说明问题的图形。而如果该部分不是非常复杂的话，你可以直接通过代码把他们表达为测试的形式。只要保证他们能够被追踪就可以了。一定要把文档制作成艺术品的规定只有那些经纪人才干得出来的事。他们可以通过那些艺术品获取不菲的酬劳，那你可以获得什么？用价值万元的程序员为你装典门面？在我的团队里常常将讨论的结果草纸或者拍摄的数码相片做为需求的输入，然后快速的把它们表示为一种简单共识的东西。如果可行，就把它们记录为测试代码的形式。虽然80%的情况是伪代码，但是当他们可以运行起来的时候，它们就会呈现给客户，以进一步的获取需求。整个的转变过程是这样的：用例->用户故事->测试用例->单元测试代码->伪代码，然后是新的更改的或者是添加的需求。哈，我们以为多么复杂呢，结果还是代码。噢，先等等。我们的结果确实是代码，但是这些代码并不是目的，这部分的代码是手段，最为重要的却是过程。让我举个例子吧。我们吃饭->消化->排泄。是的，最后的结果是排泄，但那不是我们的目的，我们的目的是通过这个过程获得生命的源料。那个过程很重要，如何把握它们并不是很容易的事。所以，我改打赌，上帝是个非常不错的程序员。这并不是因为他的“代码”有多么巧妙，最主要的是通过代码的实现满足了用户的需求。

      [关于团队]

      没有完美的人，同样也没有完美的项目。当一个项目太完美时，那么它原来定义的作用已经不存在了，转化为了另外一种职能，一种用来被观赏的金子作的馒头。
我尝经数次体验到在项目组中引入游戏所带来的好处。它增加了团队成员之间的协作意识。更重要的是所有的人都有了时间的概念，这样工作起来反倒更加有效。要知道很多时间常常被浪费在每日工作的夹缝中，而大家却混然不觉。
      在决定是否在开发过程中引入一种新的方法时，最应该考虑的问题是它是否真的可以给我们带来好处，如果拿不定主意，可以适量抽出一些少量的时候去作一下试验，但是时间不可以过长。这要比听那些所谓的专家要有效的多。注意，方法不是越多越好。它的好坏在于它带来的质量，而不是数量。即使它有效，也不要试图引入所有的方法，那样只能使你顾此失彼。方法的使用也是增量迭代的，直到前面的方法已经成为一种习惯，再去接着引入第二种、第三种方法。好的团队是有自我学习的能力的，他们会在每次迭代结束时总结和反思项目中存在的问题和成效，然后在下次迭代更进它们。团队的成长与人的成长历程是一样的。有句谚语叫做“罗马不是一天建成的”，Roma wasn't build in a day!

      [关于语言]

      计算机语言是所有语言中最为简单最为直接的语言。不需要你背大量的生词和短语，也不需要你了解每一个谚语后面的背景故事，真正需要你做的只是用那些有限的词汇把用户的需求复述一遍而已。就像上小学时的作文一样简单。

      [关于计划]

      在我的开发周期中，喜欢用两种方法来整理问题，一种是宏观层面的，帮助我们对软件有一个概要性的抽象了解，这种方法俗称OOAD。另外一种则是从微观层面的，给我们在代码的实现过程中以指导，这种方法则是以KENT BECK创建的TDD。有趣是这两种都是以事务脚本作为需求输入的。可以将用例分解为用户故事。如果项目较小可以直接使用用户故事的形式。针对用户故事编写测试用例。表示这些测试用例的最好方法不是用例文本，而是接受性测试代码。根据测试代码，将用户故事分解为多个任务，区分优先级记录在todolist任务列表内。

      [关于勇气]

      周星驰可以拍出好的电影是因为他总是永于推翻昨天自己刚刚完成的设计。软件开发也没有一磋而就的事情。一定是设计、实现、重构的过程。所幸的是软件的重构可以建立在上一次设计的基础上，这可以节省大量的菲林。