重构和设计模式

免费打工仔

我们注重讨论一下重构和设计模式的重要关联。我们都知道设计模式对于大规模软件设计的重要性，但大部分朋友和我一样，同意对设计模式的应用很容易陷入“过度设计”、“形而上学”的陷阱中。为了模式而模式，是很多初学者必然经历的问题。但是在最近几个月中，似乎我在下面文字中找到了解决这个问题的比较好的方法。

以下一段文字是在《敏捷软件开发 原则、模式与实践》第二十四章节“OBSERVER模式-回归为模式”结论中的一段话（中文译本P275）。

如果你熟悉设计模式，那么在面临一个设计问题时，你的脑海中很可能会浮现出一个模式。随后问题就是直接实现这个模式呢，还是通过一系列小步骤不断地去演化代码。本章展示了第二种方案的过程。我不是直接断定OBSERVER模式就是手边问题的最佳选择，而是持续地一个接一个地解决问题。最后，代码非常明显地朝着OBSRVER模式的方向前进，所以我改了名字，并把代码整理成规范的形式。

在演化过程中的每一刻，我都可以发现问题已经解决并停止演化。或者，我也可能发现可以通过改变路线并朝着另一个方向发展来解决问题。

对于以上一段话的理解，让我受益匪浅。在设计模式的使用中简单设计和重构会让我们更好的掌握最终的结果。代码应该根据变化的需求是不断生长演变，而不是由某些程序员在开始通过UML定义出来并被固定成什么样子。设计模式有各种各样的实现方式和变体，（其中大部分）很难在最初就明确他们的样子。

在Orz的MVC设计中明确经历过这样一个过程，在最初的设计中，并没有强调Controller层的作用，在我个人的设计中一直以为配置View和Model的可执行程序应该是所谓的控制器（ Controller ），但是这样设计有两个最严重的问题，其一是控制器内容过于简单（基本没什么东西），二是模型层（Model）没办法完全剥离对视图层（View）的调用，这明显违背MVC中分离视图和模型的目的。这让我陷入一个尴尬的设计中，我在之前只能称Orz是一个不完全的MVC模型，或者是一个嵌套的MVC来自圆其说。

但是后来按照《敏捷软件开发 原则、模式与实践》里面的方法，我在脑子里对Orz的游戏进行了一些思考上的优化，发现以前认为没什么作用的基础（或者是规则）层慢慢的完成了大部分Controller的功能，并能成功的隔离了模型直接对视图的依赖。

我忽然发现，原来可执行程序并不是我一直想要找的控制层，而随着优化和重构，控制层竟然凭空的出现在基础（或者是规则）层里面（在本例子终就是AVGFramework）。这件事情让我很惊奇，就如同在不断的优化过程中，代码找到了我。而不是我设计了代码。

这种事情发生过很多次，在不断优化以及重构的过程中，代码自己突破了开发者的设计，朝着更好的地方实现。我一直坚信，程序员并不是和设计代码，而是根据好的规则找到代码。在正确的重构和优化的过程中，代码会如同树木一样，自我生长，不断完善。

反过来，这些认识也加深了我对《极限编程》中所谓“拥抱变化”的信仰。需求和设计如同两颗互相缠绕的小树，不断变化，不断成长。程序员通过一系列敏捷方法（肥料）去让他们成长为一个优秀的软件。我个人因此受益良多。

最后还是广告

http://class.gd

jiduanderen

好贴!有很大的启示作用!
回复是尊重!

tarkey

我做游戏十来年，对于重构的心得就是，很多时候一个项目完成了，所有代码你也觉得很完美了，低耦合，可扩展性强，但是下个项目确实完全不同的东西，甚至平台/编程语言都不一样了，于是之前的东西就放在那成了摆设，甚至今后到再也不会基于它做任何升级/应用了。

所以项目做多了，现在我的原则是：不到万不得已的情况下，尽量避免重构。

现在对于我的挑战就是：如何用最低廉的成本来按时高质量的完成项目，其中包括让一张白纸一样的新人能够在最快的时间理解当前项目的代码结构，出现BUG尽快定位到人，各种周边自动化工具。

设计模式这个东西，现在我看来在项目里面最好别用，要用，也要弄得通俗易懂，别整那些proxy, observer, factory之类的名字，新人进来了还要花时间去教他们理解。

对于XP里面结对编程的理解，我现在觉得在游戏项目中，并不一定是两个程序员在结对，更合适的应该是策划+程序或者美术+程序或者策划+美术这样的结对开发。

免费打工仔

tarkey: Re:重构和设计模式

我做游戏十来年，对于重构的心得就是，很多时候一个项目完成了，所有代码你也觉得很完美了，低耦合，可扩展...

重构不是解决下一个案子的问题，很多时候是解决现在的案子的需求变化。

最近很让我爽的一件事情，就是之前我的代码违反了单一职责原则，找个时间都把接口分离了。
虽然重做的时候没觉得多大作用。
但是现在需要更改一些部分，就是增加一些流程，因为之前分离的彻底，基本上只要把某些模块修改就好了。

这次让我觉得很爽，在不知觉的情况下写了以后需要的代码。

重写和重构是两个选择，很多和厉害的人可以重写。但是对于一些开始设计很难准确的比如我这样的人，莫不如重构。试问又有几个人说设计刚开始就能完美呢。

另外有一点，开源软件必须重构。持续的发展才是硬道理，没几个人可以好像微软一样一个版本一个版本的发。基本上都是不断更新小版本好的，比如apahce的三段式版本号。

重构更好的原因是可以和测试驱动以及足够的设计两个天衣无缝。

足够的设计需要重构到良好的设计
而重构有需要单元测试保证重构的安全性。

我的理解是，单独用重构可能会有些问题，至少单元测试要补充上去。这样就安全很多。如果用的习惯了，重构还真是好东西。

tarkey

你还是生活在自己的世界中，和团队合作全然不是这么回事。

clayman

http://realtimecollisiondetection.net/blog/?p=81

免费打工仔

tarkey: Re:重构和设计模式

你还是生活在自己的世界中，和团队合作全然不是这么回事。

敏捷团队比较适合10几个人的，如果大了的话，是应该划分成小团队的。
很走运，我的团队还真没有太大的，做的项目也都偏小。所以这对我很适合，我比较喜欢6~10人的团队，结对正好。少了就不是很舒服了。

大的团队也要看做什么 cmm这种我不是很懂，如果xp的话，是需要分组的吧。 你来讲一下吧。：） 谢谢我也想讨论一下。

我在认真的想你说的问题，为什么认为团队合作不适合“重构”呢？

1 是没有好的保证去同步大家的接口吧。
2 是没有好的工具同步代码

这是因为部分采用XP而忽略了每种XP方法之间的依赖导致的。

1 首先没有结对编程 和交换结对对象 以及代码公共所有权，这三个原则的话，因为沟通问题，重构很可能导致互相影响。
2 如果没有持续集成和自动测试的话，重构导致的臭虫会让开发者自杀。
3 工期压力，导致放弃重构。没有采用“可持续的开发速度”。

所以可能对于某些非敏捷的团队，片面的使用“重构”确实很困难。重构和测试驱动不同，很难单独实践，必须有另外的方法来保证重构的安全和效率。

所以团队能否重构，取决于领导者是否能明确贯彻XP以及顶住上层领导的压力。团队的XP是很难的，主要是因为国内对XP的人士还不够。

当然，我不敢说XP是万用药，但是如果没有其他保证的话，重构确实很困难。

但是 如果个人希望重构的话，那么接口要设计很好，内部实现局部重构，不要影响别人，似乎就能躲避团队的毛病。不过也很困难。

我不明白的是，如果不重构，当需求改变或者代码臭味增加之后，如何调整方向回到正确的路上呢呢。重写么？

至少国外一些敏捷团队是可以重构的，这个我是相信的。只是我们能否有能力拿来用而已。

还是要打个广告
http://class.gd

OpenGPU

学习了
斑竹达人~~说得太好了！！！！！！！！！
:>

-------------------------------------------------------------------------------------------


欢迎访问开源图形处理器体系结构论坛(OpenGPU论坛) http://www.opengpu.org/bbs/

OpenGPU Graphics Open Source community（图形开源社区），聚焦领域(focus domain)包括：
  * GPU Architecture（图形处理器体系结构）
  * Graphics Algorithm（图形算法）
  * Open Source Rendering Engine（开源渲染器）
  * Open Source GPU Simulator/RTL Implement（开源GPU模拟器）
  * Mobile GPU Developing （移动图形设备的开发）
  * GPGPU Programming （面向通用的图形处理器编程）
                      （包括CUDA/OpenCL /DirectCompute）

免费打工仔

OpenGPU: Re:重构和设计模式

学习了
斑竹达人~~说得太好了！！！！！！！！！
:>

-------------------------------------------...

谢谢，我也是刚开始实践这些方法。
很多人告诉我“尽信书不如无书”
但我以为，至少先要“尽信”，然后才“不信”。
先去全盘接受，在逐一学习和适应，然后再改变。这样总比还没有了解之前就批判好。
所以我做了http://class.gd这个项目，因为我本身也是刚开始学极限编程，很可能会有很多不对的地方，我拿出来晒是希望得到大家的讨论和指正，然后才能辩证的理解。

tarkey

XP也好，其他软件工程的东西也好，实际操作起来还是一个人的问题。
游戏开发行业最大的问题就是人员流动，比任何行业都要突出。
如何来配置合适的开发管理过程来适应不断的有有经验的程序员离职和完全没有任何经验的程序员加进来是最重要的问题。

做软件开发的最忌讳生活在自己的世界中，认为自己所构建的世界是最完美的，对于我来说，任何配置只要能开发出产品，产品只要卖得好，就是成功的团队。

XP在国内的教育中并没有被推广，99%的应届生毕业了都不知道XP是什么东西，甚至连STL是什么都不知道，甚至只用过Turbo C，连C++都没摸过，你跟他们去推广XP？不嫌成本太高？降低开发门槛是一个项目成功的关键。我看过无数的号称很牛逼的开发团队，最后都胎死腹中，无论是涂鸦的引擎，还是某些号称尖端的引擎研发团队。他们失败就失败在无法看清国内的开发环境，失败了就怪招不到合适的人，怪环境，完全不从自己身上去找原因，殊不知他们原来一直都生活在自己的世界里。

所谓的流程在心中，就是你在带团队的过程中，你会发现很多很搞笑的代码，很搞笑的设计，以及很搞笑的BUG，不要去责怪他们，也不要去帮他们改，你只需要知道，这样的东西会不会对最终的产品造成影响就行了，这个就是在自己心中，不需要说出来。要记住，你是在做项目，不是在做教育，也不是在培训，你的一切就是保证项目能够顺利发售，除此之外的一切都是在浪费成本。

尽管我知道曾经我发售的游戏中还有很多我已经知道的BUG，但是已经发售了，卖了30多万份，这就足够了。