关于设计模式的思考

    最近开始着手项目的代码重构,因为原有的代码框架已经越来越难以应对日益变更产品需求了,代码越来越臃肿繁杂,越来越难以维护,bug隐藏越来越得越来越深,不得已才想起了重构,重构是一个敏感的话题,很多程序员希望重构,特别是新员工,希望借此机会来锻炼一下自己,但领导对于重构有着很谨慎的态度,因为,提起重构,首先想到的就是人力物力成本和时间成本,而且更重要的是面临着重构后产品能否有预期表现的风险,所以,很多领导对重构不太感冒,很多产品经理对重构也漠不关心,因为他们只看产品的表现,不关系技术实现,所以,很多时候重构成了程序员的一厢情愿.我们公司这次重构刚好面临着下一版本产品需求没有成型这样一个空档期,大概一个月吧,领导同意我们借此机会重构代码,我欣然接受.重构机会难得,不能掉以轻心,不能随便应付了事,尽量充分应用自己哪怕少得可怜的知识来认真对待.

    今天在上卫生间的十来分钟的时间里我在想一个问题,既然是重构,当然就得把代码架构设计合理,便于扩展和维护,这种时候我们都会想到设计模式,设计模式也是程序员到了一定的水平自然而然就会想到的话题,但我今天想的不是具体的用什么设计模式,而是一些说得好听一点就是上升到哲学层面的问题:为什么会有设计模式一说,我们应该用什么心态对待设计模式,设计模式是不是一定就是好东西?

    我不是技术牛人,只是随便发表一些肤浅的碎片化的感想,任何事物的发展都有一个过程,刚开始都难免很原始,很初级,随后经过演化越来越高级,比如人的进化,还有人大脑的进化等等,任何领域的技能也都有这样一个演化过程,经过多少代人的共同努力,这项技术越来越先进,这也是为什么人类文明为什么越来越发达,学科越来越多样化的原因.因为很多领域经过提炼加工并经过后人的演进就会成为一门单独的学问.同样,软件领域也是如此,软从诞生初期恐怕没人知道设计模式是什么概念,用很原始很初级很直截了当的方式来实现软件的需求.但随着软件业的发展,产生了越来越多的技术,各种名词术语层出不穷,设计模式就是其中一个.

    设计模式是一些优秀的程序员前辈们在编程的过程中提炼总结出来的智慧结晶.是对一些软件优秀结构的解决方案的总结.这些模式可以套用在很多地方,但是,事物都是具有两面性的,怎么利用设计模式有利的一面,怎么合适地利用设计模式,是不是非得用设计模式等等这些问题都得考虑,不要迷信设计模式,不要机械呆板地使用设计模式.在我看来,设计模式的使用应该取决于场合,项目的大小,项目的性质,项目的周期,人力物力预算等等都要综合考虑,一些较大的项目将来的维护和扩展是一件非常重要的事情,合理的架构能为以后的维护和扩展带来极大的便利,相反,一个结构混乱,高耦合的架构将来的维护和扩展任务将会让程序员生不如死,而一些简单的小项目,周期要求也很短,这种情况下就不一定在每一个模块,每一个细节功能都把设计模式用到极致,一些直截了当的方案就可以了,如果程序员是一个理想主义者,处处考虑到重用性,也不关心项目的周期,为了可重用性不顾一切地优化结构,不停地更改,为了实现低耦合,可能付出了极大的代价,最终实现了一个优秀的架构,但项目也因拖延了太久而废弃了,做为程序员,我们应该考虑的事情有很多,不应该光从技术角度单纯地考虑,即使从技术角度这一方面来考虑,也应该站在一定的高度用系统的眼光来考虑,想起一个简单的例子,比如有一个题目是这样的,列出用abc这三个字母组成的所有排列组合.直穷举就可以了,没有必要再用排列组合公式计算了,但如果让你列出26个英文字母组成的所有组合,那就得用公式计算了,道理就是这样,一定要站在一定的高度,用系统性思维灵活地考虑问题.很多时候简单的解决方案因为我们僵化的思维而被遗忘.

    没有最优的架构,只有最合适的方案,方案的选取是对技术经理,技术总监综合能力的考验.