客户端敏捷开发之道【一】:设计模式篇

发表于2016-11-22
评论7 3.22w浏览

想免费获取内部独家PPT资料库?观看行业大牛直播?点击加入腾讯游戏学院游戏程序行业精英群

711501594
文/GAD X.F.Earlonus
  正式参加工作已逾三年,打算把工作沉淀下来的方法论整理出来,以作纪念。思来想去,还是觉得用「敏捷之道」贯穿这个系列最为合适。由于每年新沉淀的方法论,是在以往的经验基础上总结的,因此本系列文章具有一定的前后依赖关系,建议按顺序阅读。

  以前实习的时候,曾听一位前辈说过:“掌握设计模式,即是忘记模式”。如果您对这句话心存困惑,那也许本文读下去是值得的。

(一)设计模式到底在什么情况下使用?
  在我们学生时期,无论是编程竞赛,还是编程作业,几乎没有感觉出设计模式的意义。而进入工作岗位后,又忽然间发现它的重要性,这是为什么?
其实区别只有一个,那就是:工作以后,我们的代码要不停的改,而学生时,作业提交了,就不用再改了。
  当我们设计一个复用的组件时,下一次调用即可不用再重写。当我们生成一个基类时,下一次设计类似的方案,只需要写变化的部分。事实上,无论当我们使用哪种模式还是依据各种原则做开发时,本质上都是为了「下一次」改代码做准备。所以设计模式的目标是:当需求不停的变化时,让我们可以在原有代码上,更好的适应这些变化。当我们还在学生时期时,我们的代码一次开发,提交后不再修改,此时设计模式没有任何意义,我们也感觉不到任何意义,因为没有二次开发。而当我们进入工作时,需求迭代的压力骤然袭来,此时,熟练运用设计模式便成为了我们的基本功。
总结一下,设计模式的故事就是这一句:无变化,不设计,面向变化做设计。

(二)开放封闭原则,到底在讲些什么?
  开放封闭原则是Bertrand Meyer在1988年提出的,原文如下:Software entities should be open for extension,but closed for modification。事实上,开放封闭原则可以覆盖很多设计模式,因此这里想以这个原则为例,探究设计模式原则到底在说什么。
  事实上,开闭原则是一个科幻原则,因为无论使用什么模式来符合这条原则,都不可能完全不对原来的代码做修改,即使最符合这个原则的模式,至少也要插入一行代码(写这段话时,忽然想到用配置文件可以做到,不过不钻牛角尖,嗯)。所以,我对这个原则有另外一个理解:
少改少错,多改多错,不改不错。之所以要说开放封闭原则,其实是想借此说明这样一个道理:设计的原则,其实是告诉我们一定要改代码时,怎样改比较好。

(三)那些设计模式,到底在讲些什么?
  先说结论:每一种设计模式都对应着一种变化。
  由前面我们已经知道,设计模式是用于应对变化,而设计原则又告诉我们怎样应对变化,那么设计模式最终将告诉我们应对何种变化。
  例如:当我们开发弹窗时,可以预见到弹窗会有多种样式,而他们的基本行为都是差不多的,未来还会开发出其它样式的弹窗,此时工厂模式将是你的不二之选。
  例如:当我们需要调用一个非常复杂的过程时,代理模式/装饰模式/适配器模式,无意是你的首选。你将以很小的成本,提供外部调用一个复杂的过程。
  每一种模式都对应着一种变化,换句话说:当我们知道了要怎样变化时,才知道要用什么模式

(四)解决变化的问题,依靠设计模式是不够的
  一般来说,在我们客户端工作中,最大的问题并不是不知道要用什么模式来应对变化,而是不知道要怎么变化。甚至,连产品经理很多时候也不知道要怎样变化。因此,一个非常恐怖的问题是:
我们并不是不知道怎么应对变化,而是不知道怎么变化。
针对这个问题,我总结的方法是:
1)不对不确定需求做设计(不做过度设计)
  我给过度设计的定义是,对不确定的需求做的具有一定开发工作量的设计。过度设计有两个必要条件:
1、需求不确定
2、需要一定开发成本。
  如果需求确定,有一定的开发成本,也是值得的。如果需求不确定,但是几行代码可以完成,也算不上过度设计。如果竟然需求也不确定,同时还要一定开发成本,并且还要实现,那么这部分开发就可以认定为过度设计。
2)一旦确定变化趋势,对框架动态重构,不留技术债务
  框架设计是一个动态的过程,旧设计无法满足新变化,出现新变化时的开发负责人就有义务对框架做重构,以满足变化需要。
其实说到底:彻底弄清楚需求,是设计好代码的前提。

  整体来说,了解设计模式,以及设计模式背后的东西,是成为一个好码农的第一步。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台