需要设计模式吗?
答案是肯定的,但你需要确定是模型的应用是否过度?我得承认,世界上有很多天才的程序员,他可以在一段代码中包含6中设计模式,也可以不同模式而把程序设计做得很好。但我们的目标是追求有效的设计,而设计模式可以为这个目标提供某种参考模型、设计方法。我们不需要过于追捧GOF的设计模式,但合理的运用设计模式,才是正确的抉择。
很多人看过GOF的《Design Patterns》,对这23种模式也背的滚瓜烂熟。但重要的不是你熟记了多少个模式的名称,关键还在于付诸实践的运用。为了有效地设计,而企鹅熟悉某种模式所花费的代价是值得的,因为很快你会在设计中发现这种模式真的很好,很多时候它令得你的设计更加简单了。
其实在软件设计人员中,唾弃设计模式的可能很少,盲目夸大设计模式功用的反而更多。言必谈“模式”,并不能使你称为优秀的架构师。真正的出色的设计师,懂得判断运用模式的时机。
还有一个问题是,很多才踏入软件设计领域的人员,往往对设计模式很困惑。对于他们来说,由于没有项目实际经验,OO的思想也未曾建立,设计模式未免过于高深了。其实,即使非常有经验的程序员,也不敢夸口对各种模式都能合理应用。
重构是必然的!
既然我们无法给出一个完美的设计方案,因为客户的需求总是变化的,重构也就成为必然。问题是,这样没有添加任何功能的重构,你是否愿意为此付出精力、时间去完成。当客户要求的DeadLine将要带来的时候,你还认为你的重构工作有必要吗?
有时候,软件设计常常身不由己。然而,纯从技术角度来看,重构非但必然,而且重要。既然我们都明白,复杂的未尝就是好得,简单的也不一定是容易的。要保持你的设计尽可能的简单,可能还需要时时借组重构利器,来“改善你既有的代码的设计”
对于重构,Martin Fowler给出了很多条款。这些条款并不是政治课本上教条,也不是“日月神教”的神奇咒语,念着它们就可以防身。这些条款确实很重要,但你需要的是学会他后,然后忘记他,就像张无忌的太极拳那样,我不是故弄玄虚,事实上只有这样,重构的精神才能完全融入到你的设计中。
TTD单元测试和其他
软件的生命是什么,是质量!而保证质量的惟一方法,就是测试。传统的软件开发过程,强调首先进行需求分析,再从需求分析中抽象出概要设计,进而做出详细设计,然后编码,最后才是测试以验证代码的正确性。而测试驱动开发(TTD)改变了编码的过程,开发仅仅包括三方面的活动:编写测试用例,编码并进行测试,重构代码以消除重复代码使其更简单、更灵活、更容易理解。通过测试来驱动开发,听起来是那么的离经叛道,然而实施起来,又是那么合理、正确和简单,前提是:我们不能在一开始就获得正确的设计!TTD避免了对不完整需求造成的不成熟的设计,通过单元测试,保证了代码的正确性与高质量;通过重构,使设计更加简单、灵活。