代码改变世界

关于设计的度的一点小认识

2010-07-29 07:50  Virus-BeautyCode  阅读(...)  评论(...编辑  收藏

  

关于设计的度的一点小认识

 

引言

  最近读了《设计之道》这本pdf书,是园子的老师傅总结的,感谢他的分享。

  前几天葡萄城控件团队也发表了一篇《设计做到什么程度? 》,写的不错,有一定的指导意义,不愧是大厂出来的。

  正好自己今年也开始进入真正的设计领域,虽然设计的问题出来不少, 也是改来改去的,也是由于中间学习了好几关于设计本书,同时参考了好几个框架和代码示例。发现大家在这方面还是各有认识,没有绝对的标准,而且都有自己的道理。

  总之,感觉还是成长了不少。不过,同时也发现自己知道的太少了。学习的路还很长。

正文

      关于设计的“度”的问题,我想也是一个颇有争议的问题。主要有两个论点:

      1.       要不要预先设计
      2.       设计的“度”如何把握

      说一点题外话,最近也准备开始学习TDD和Agile了,看来一点这方面的资料,说的不准确的地方,还请各位指出。

      这两个问题看似是两个,其实它们有着千丝万缕的联系。

      关于第一点,在我初步接触的Agile理论中,还有就是一些人士写的文章中,都说不要预先设计,因为会搞成过度设计。我不这么认为。我个人还是比较推崇和赞成预先设计的,原因如下:

      •       不需要预先设计,那还要架构师做什么呢?大家开工就好了,然后在后面需求变化的时候再来refactoring就好了。当然了,这时候可能需要架构师做好一点的重构,但是他们(agile)好像说,重构也不要过度,满足当前需求就好,那不就是说还是不需要架构师吗?难道架构师在agile要失业,或者说要转型了吗?还是我理解的方向有问题呢?
      •       不错预先设计,会给后面的重构带来很大的麻烦。甚至于没有办法重构,只能推倒重来,因为可能是结构性的变化。这个我是深有体会的,相信大家也是深有体会的。
      • 不预先设计,就代表着将风险推后,会给后面的修正带来严重的后果。造成后期的维护异常困难,成本急剧升高。
      • 不要被眼前的快速开发蒙蔽了双眼,眼前的快速,将造成后期的速度成倍的减慢。

      当然了,做预先设计,就会涉及度的问题,也就是第二个问题,度如何来把握?

      我想大家也不是不赞成预先设计,只是由于害怕过度,所以放弃,我觉得不好。不能因为怕过度,就找个理由,找个什么“重构”的理由不进行丝毫的设计,我不相信这样的代码在后面还能重构,就算重构,所花的代价,完全可以在编码之前进行一点设计,就可以避免大量的浪费。

      我个人完全不赞成“事先不设计”的观点,还完全鄙视那些没有搞懂agile,拿refactoring来推脱设计的人士。

      我也没有其他意思,就是觉得设计完全必要的,但是要把握度,尽量不要过,但是也不要太草率,草率开工,后患无穷,今年的我是十分有感触的。

      如果设计的度可以划分为1,2,3,4,5等级的话,我觉得至少需要进行到3级,至少也要及格吧。往后面可能是过度了,但是往前的话,肯定是不充分,编写的代码在后面会被大量的抛弃。这还好,主要是浪费的时间和精力无法找回了,最重要的人的斗志,斗志减退了,就真的很难找回来了。

      我见过很多最终作总结的时候,说设计不充分,所以修改很痛苦,越到后面越修改的慢。但是,让他做设计的时候,他又说什么agile,不要过度,不要进行预先设计,我觉得这不就是矛盾吗?我也不针对某些人,但是这就是很明显的矛盾。只是觉得这样会浪费大家的时间,为什么不预先设计一点点呢?预先思考一点点,也许后面就不会那么痛苦了。

     

 

结论

      总之,个人觉得预先设计是非常必要的,是必不可少的。但是度需要把握,不要过深,否则会陷入其中很难自拔,设计过度了,加大了开发的难度,影响后续开发工作。但是也反对那些因为怕过度,就不进行设计,还拿agile来搪塞的tx。

      agile我最近会开始学习,我需要自己好好的理解一下,是不是他们口中说的思想,我觉得应该不是,肯定是很多人曲解里面的意思。不过也难免,毕竟是国外的思想,国外的环境和我们不一样,国外人的思考方式也和我们不一样,到了我们这里被一些人在曲解了,这样就会发生误会了。

      国外可以成功的理念,在国内不一样可以成功,甚至会失败。至少需要修正,根据国情来修正。

      本文没有其他意图,只是想听听各位经验丰富的老兵的一些经验之谈。感谢大家耐心的看完我的这篇唠叨。