需要设计模式吗？

        答案是肯定的，但你需要确定是模型的应用是否过度？我得承认，世界上有很多天才的程序员，他可以在一段代码中包含6中设计模式，也可以不同模式而把程序设计做得很好。但我们的目标是追求有效的设计，而设计模式可以为这个目标提供某种参考模型、设计方法。我们不需要过于追捧GOF的设计模式，但合理的运用设计模式，才是正确的抉择。

        很多人看过GOF的《Design Patterns》，对这23种模式也背的滚瓜烂熟。但重要的不是你熟记了多少个模式的名称，关键还在于付诸实践的运用。为了有效地设计，而企鹅熟悉某种模式所花费的代价是值得的，因为很快你会在设计中发现这种模式真的很好，很多时候它令得你的设计更加简单了。

        其实在软件设计人员中，唾弃设计模式的可能很少，盲目夸大设计模式功用的反而更多。言必谈“模式”，并不能使你称为优秀的架构师。真正的出色的设计师，懂得判断运用模式的时机。

           还有一个问题是，很多才踏入软件设计领域的人员，往往对设计模式很困惑。对于他们来说，由于没有项目实际经验，OO的思想也未曾建立，设计模式未免过于高深了。其实，即使非常有经验的程序员，也不敢夸口对各种模式都能合理应用。

          重构是必然的！

          既然我们无法给出一个完美的设计方案，因为客户的需求总是变化的，重构也就成为必然。问题是，这样没有添加任何功能的重构，你是否愿意为此付出精力、时间去完成。当客户要求的DeadLine将要带来的时候，你还认为你的重构工作有必要吗？

          有时候，软件设计常常身不由己。然而，纯从技术角度来看，重构非但必然，而且重要。既然我们都明白，复杂的未尝就是好得，简单的也不一定是容易的。要保持你的设计尽可能的简单，可能还需要时时借组重构利器，来“改善你既有的代码的设计”

          对于重构，Martin Fowler给出了很多条款。这些条款并不是政治课本上教条，也不是“日月神教”的神奇咒语，念着它们就可以防身。这些条款确实很重要，但你需要的是学会他后，然后忘记他，就像张无忌的太极拳那样，我不是故弄玄虚，事实上只有这样，重构的精神才能完全融入到你的设计中。    

      TTD单元测试和其他

       软件的生命是什么，是质量！而保证质量的惟一方法，就是测试。传统的软件开发过程，强调首先进行需求分析，再从需求分析中抽象出概要设计，进而做出详细设计，然后编码，最后才是测试以验证代码的正确性。而测试驱动开发（TTD）改变了编码的过程，开发仅仅包括三方面的活动：编写测试用例，编码并进行测试，重构代码以消除重复代码使其更简单、更灵活、更容易理解。通过测试来驱动开发，听起来是那么的离经叛道，然而实施起来，又是那么合理、正确和简单，前提是：我们不能在一开始就获得正确的设计！TTD避免了对不完整需求造成的不成熟的设计，通过单元测试，保证了代码的正确性与高质量；通过重构，使设计更加简单、灵活。