谈谈我对“小步快跑”的理解

        看到书中第三章的标题，已经隐隐知道作者要讲述的情节。看完全章节后，果然不出所料，同时产生强烈地共鸣。下面从三个方面来阐述自己对于软件开发小步快跑的理解。

        （一）开发方式中的小步快跑
        在软件开发中，选用传统瀑布模型的开发方式越来越突显它的弊端。现在更易为项目组所认同的是敏捷迭代模型的开发方式。迭代的特点就是典型的小步快跑，它将一个项目化整为零，分为几个冲刺阶段，每个阶段都只针对当前开发的那部分内容。在整个开发过程中，与客户充分交互，同时不断对客户发现的问题及时修正。由于将完整的项目拆分成小阶段，步伐比对较小、频率快，加上沟通比较顺畅，最后开发出来的产品往往比较容易得到客户的认可。而反观传统瀑布模型的开发方式，步伐太大，节奏缓慢。为何这样说呢？开始的需求阶段与最后的测试验收阶段，与客户交互较多，而中间阶段则很少与客户交流，及时通过互动来纠偏。出现需求与测试验收两头重，中间轻的情况，步伐不可谓不大！由于中间环节与客户的沟通不到位，造成最后开发的产品与客户预期有相当大的差距。项目的最后阶段就是不断地修改代码，苦不堪言，极大打击项目组的积极性！因此也常常造成项目的延期，进展相当慢。这里所说的情节与书中出现的可能会有一些差别，但是书中提到：在整整数月的时间，我们都无法知道，我们做得对还是不对。这一点与上文所述相同，所以不约而同地，小步快跑就成为大家普遍认同的开发方式。

        （二）编码工作中的小步快跑
        相信很多人提到重构，都会自然而然地想到那本名著《重构——改善既有代码的设计》。初写代码，很想快速写出漂亮的代码，抛弃新手的帽子。书的内容还没有完全看完，就有了一种修改代码、优化代码的冲动。可到底应该大刀阔斧地重构，还是小步快跑地重构，相信看完下文你心中会有答案。开始接触重构时，看到代码中有不少地方需要“动手术”，就噼里啪啦一阵猛改。改的时候那个舒坦劲就别提了，可是因为没经验，大幅度修改的过程中没有及时跑一跑代码，看看结果是否一切OK。到最后满心期待地运行代码时，整个人就傻了，为何那么多BUG？！接下来的时间真的惨了，不断改不断出现BUG，原来感觉有“臭味”的代码运行得好好的，可是后来感觉“香气四溢”的代码却怎么也跑不起来！焦急、无助、困惑……回头认真看书，细细品味。接下来，那个豪气冲天的修改方式没了，取而代之的是频繁地小幅修改，并及时验证修改的准确性，真正品到小步快跑的好处。

        （三）将小步快跑走得更彻底些
        书中运用小步快跑的方式，通过一段不断重构的代码进行演示。对于作者给出的最终代码，个人觉得可以进一步优化。对于三八妇女节、五一劳动节、情人节之类的各种节日，我认为应该单独提出来成为一个节日类，用于统一维护所有的节日。这样以后增加新的节日时，只需对这个类单独修改即可。使用这个类时，通过传入Date由该类自行判断是否为节日，如果是节日则返回该节日的名称。不知这样是不是更合理些？

        重构是我很感兴趣的一个话题，期盼拜读作者的佳作！