第一篇博文《快速原型法和重构，可以迅速提高开发效率》

我想，做软件开发最害怕的就是需求变动。好不容易完成一个功能，客户看了，随便动动嘴，就要让你修改这里修改那里，在他眼中看似很简单的一个改动，其实要做不少的工作量。如果从商务角度去拒绝，不重要的改动确实可以拒绝，但客户难缠或者业务必须要达到的功能，也不得不去改。这时候，增加了工作量且不说，最重要的，感觉心里烦躁。本来自己心满意足的完成了一个任务，没得到一个崇拜的眼神和诚心的赞扬，结果不仅没表扬反而被别人挑刺。这心理落差是极大的。

或者说，接了一个项目后，只有一个模糊的功能，实际上细节不清楚，心里没有清晰的轮廓，那么也会让人心烦，不知道从什么地方下手

这两种经历，我都遇到过，而且让我受了不小的打击。

经过多个项目后，我发现快速原型法和重构是最有效的开发模式，当然我做的都是小型项目,这种方式适合小项目

快速原型在百度百科定义：快速原型模型需要迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。

我认为快速原型模型的本质是，快速搞清软件到底应该实现什么功能，客户实际需求到底是什么。这包括两方面，一是软件开发者搞清楚，二是客户自己清楚需要什么功能，因为有时客户自己也不清楚实际需求，或者当初考虑不全面，导致后来要求修改这里修改那里。而快速原型法，潜台词就是告诉客户，你有什么功能赶快告诉我，别到最后说这说那。

敏捷开发的作者说，不要害怕需求变化，要拥抱变化。说实话，刚开始看到作者说这句话，感觉作者站着说话不腰疼。我是很不喜欢变化，我喜欢做最简单的事情，就可以赚钱，比如说，一个客户要求做一个串口数据采集显示的软件，那我直接做了给他，只要可以采集数据并且显示出来，那么他就付钱，我不喜欢啰嗦。可实际上，没这样的好事，客户往往会改变一些需求，比如改变一下按钮的位置、显示的颜色字体、增加实时曲线等等。我最讨厌当我觉得软件完成的时候，客户再提这样的需求变化。这样让我心情很不好。

所以当我遇到这些实际问题的时候，开始尝试用敏捷开发的思维对待客户，先用最短的时间最省力气的办法给客户一个可以使用的简陋（或者说丑陋）的软件，发给客户后，自己就坐在办公室喝咖啡，qq上泡mm，耐心的等待客户反馈。然后第二天客户反馈，并且询问客户，为什么这样？结果这样效果很好，让我少走了很多弯路。

快速原型法另外一个内涵是，不做无用功或者少做无用功，不做或少做客户不需要的功能。

这类似工业控制的PID调节方法。不断根据反馈，实时调节输出，以达到最佳效果

第一次写博文，不知道把我对快速原型法的理解说明白说清楚没有。