需求分析，是一个很讲究经验、技巧的阶段，以前我认为需求分析做得好的人不一定是编程非常棒的人，当时在一个小的团队里，我的想法是错的。要把需求分析做好，那好的需求分析结果是什么洋子的呢？有什么特征，比如说两个脑袋之类，让人过目不忘的特征？或是琅琅上口那种？
总结一下撒：
         好的需求分析，不是简单的总结，更重要的是分析，来源于用户的需求，又高于用户的需求。这样说有点太玄了，就是需求分析总结出来的功能点，不单要覆盖到用户的直接需求，还要为用户的次生需求提供足够的扩展空间。
         分析的结果要记录在案，免得自己日后不认账。需要一种监督的力量，这种力量是很难得的，最靠谱的做法是群发给所有人，这样就在别人那里记下了一笔账，等你提交Demo版本的时候，大家都掏出账本，一笔一笔的兑现。

         设计是回答需求分析归纳出来的功能点，一个功能点就是一个问题，设计就是回答这些问题。
问题的回答首先有个大纲，这个跟写作文一个道理，HOHO，我写作文从来不写大纲，所以小学初中的时候天马星空，深得老师赞赏，到了高中就废废了，sigh。
         概要设计就是这个大纲，所谓大纲，可以浪漫些，理想主义一些，把软件想的完美一些，如果是设计完了是自己来实现，怕是多数人不会选择这种风格，怕是实现不了，或者实现起来很难，岂不是搬起石头来砸自己的脚。所以，很大程度上要靠责任心，这年月，什么最贵？责任心。其实，只要设计出来，实现都是没有问题的，以上的一些逃避的想法，其实是对自己的技术不够自信导致的，是一种对于未知世界的恐惧敢在作怪。对付这种恐惧，别无他法，只有武装自己。
         这一步也要记录在案，不然，本来就捉襟见肘的设计，最后在偷懒的本性的剥蚀下，会变得惨不忍睹。

         概要设计列好了大纲，下面是详细设计。详细设计阶段对设计人员有一个要求，就是在这时候，设计者应该能透过概要设计画出的蓝图，看到实现的细节，甚至是具体代码。要不然，如何定义接口呢？在接口的设计上是有一些惨痛代价的，能犯的错误，基本上一个不拉。设计到最后，大量的重名函数，由个更名带来的接口污染，由于态度暧昧造成返回值类型的滥用，接口类型的不确定，参数时多时少，总是不恰好。尤其是到了编码阶段，如果这些地方出现错误你算算需要维护多少分文件，实现文件算一份，头文件一份，接口文件一份，再加上开发文档、类图，牵一发动全身，一处错误，到处修改（貌似Java的特性）。
         这些都是教训，那经验呢？
         我想，如果有一个东西能控制这整个过程，那就是类图吧。类图修改起来容易，而且很直观，如果要用好类图，就不要吝啬你的脑细胞，整个操作流程设计的细枝末节都要细细斟酌，这样才算没有糟蹋UML这样一把牛刀。

         如果有凌波微步的功夫把前面三步走都走的很潇洒的话，后面的工作可以说是水到渠成了。可惜，这样的功夫我暂时还不具备，摔了几跤，爬起来，拍拍身上的泥土，擦干净身上的狗屎，继续前进。
到了编码这一步，我的最大体会就是，如果你没有把前面几步蹚明白就贸然走进这一步的话，会碰得灰头土脸。不要怕过度的设计，现在的问题是设计不够，说明白点，就是没有在设计阶段，把全部的精力都放在设计上。

         在编写代码的第一步编写测试用例，我想多数人接触这个东西的时候心里都是感觉怪怪的，老是想着，我的button+label的法宝不是屡试不爽的吗，干嘛要这劳什子。试用之后，发现这是个有远见的好点子。首先人家实现了科学管理，试想一个全部靠button+label实现的测试，测完之后不知道扔到那个废纸堆了。用工程来管理测试用例，形式上是一种进步。实质上呢，当联调的时候发现问题，逐个跑一下测试用例，很快定位错误所在，这时候你才能体会到当年的辛苦是值得的。其实这些只是享受到这些方面的便利，就好比是买了一大块巧克力，舔一舔就扔掉了，浪费大了去了。人家设计这种开发模式的初衷是为了更好地在编码中体现设计的指导作用，更好地贯彻设计指导开发的思想。当然，这一点暂时还没有深入我心，我只是在一个接口不多的小模块上实践了这种模式。

         一开始不进行代码版本控制，出现代码管理混乱，常常分不清哪里是新代码，哪里是老代码。翻了半天，要靠右键属性通过时间来判别，有时候文件夹乱放，每一次都要翻箱倒柜。还好，星之队拯救了我。

         当然，还是有一些好的经验的，比如常常召唤出两个胜利女神来，一个正常开发，一个快速的button+label验证对xx的小想法。

         最大的问题还是对时间的控制，控制好时间，就控制了一切。