浅谈系统框架与开发模式 [转]
作者:C/S原创  发布日期:2011/04/11 18:14:00
  浅谈系统框架与开发模式 [转]

浅谈系统框架与开发模式 [转]


系统框架与开发模式

在博客中我也看到了好多关于系统框架的文章,就象有些朋友说的,这些系统框架大同小异,一般是分为数据访问层、实体层、业务逻辑层、业务外观层、表示层。然后就是这些层与层之间的调用,这些我想对于做过稍大一点的项目、或者小型以上团队开发的项目,都是会考虑到这些分层模式带来的系统扩展性优势。

  有些朋友都建议加一个common层,把一些共公的类与方法集中在一起,让大家一起调用,可以减少重复代码,这个我也是很支持的,也是这样做的。

  我相信目前摆在我们面前的,已经不是这些系统框架的问题了,而就是这些结构中体现出来的开发模式的问题。

  大家所说的要把公共的代码放在一起,这就是“重构”所要体现的思想,重构就是为了让代码更具的扩展性、维护性,能减少重复代码,这可以从根本上提高代码的效率并减少修改导致的BUG恶性循环。

 

重构一般发生在什么时候?


  代码设计期:这要求设计人员把公用的方法总结出来,放在公用的模块中,生成文档或是通过其他方式,反正就是通知大家这些公用方法,而这是非常有限的,设计人员无法思考出所有的公用模块与方法,相反,这些只是极小的一部分,因为更多的重构应该发生在下面。


  代码开发时:当我们第一次写一段代码时不会注意,写第二遍时我们会想:算了再写一遍吧。准备写第三遍时,我们必须要醒悟过来,这些相同的代码可以放在一个公用的方法中调用,对,在第三次时我想我们最好是这样做,因为你现在这样做,不仅仅是为了现在,而是为了将来。我们就会写成公用方法,并一定要把原来的两个方法采用“调用”的方式,可千万不要偷懒,谁也无法保证今后不会修改这个函数,而如果真的修改了,你没有能力找出最先的那两段代码了,恶梦从此开始。 来源:考试大-软件水平考试


代码修改时:项目已经开发完成,在后期的维护中,一次次的修改会使每一位程序员痛不欲生,没有了当初的热情、有几位已经退出了团队、对原系统遗忘的很多、修改变的越来越没有道理了,就这样,曾经热情高涨的代码编写变的应付了事了,重构再也没有勇气了,就这样的,没有了重构,死循环的恶梦真正的开始了,后面的修改与维护变的越来越困难了。然后,在这个时间进行重构仍然是非常重要的,在进行修改时,我们要仍然保持这种心情,我们只要相信,每一次修改是为了减少修改,而不是相反,那么,我们还是要相信重构。

  重构的过程就是这样,在慢慢的过程中,系统会变的越来越精简,修改也会变得变来越少,而且越来越容易,当我们在修改时发现:我只要修改这一个地方就可以了。这仍然是可能让我们保持热情的理由。

  可是问题呢:问题就是在这些重构过程中,如何及时的通知其他的队友,重构不是针对开发人员的,重构是针对系统的,当一个人进行了代码重构后,如何通知其他的队友:朋友们,我添加了XXX方法了,参考请看YYY,请大家进行一下相关的修改或注意以后的调用。

  其实我也是不知道如何维护整个系统的信息交流,我想首先想到的就是mail了吧,一封邮件的通知,可以完成一个重构人员的信息发布,可是接受者呢,在一封封的邮件中进行着一次次的修改,而且这些零散的邮件会让人找不到方向。

  那么好吧,放在一个集中的地方,大家把重构都放在一个公共的地方我想是比较好的方法,不过,大家得经常注意这些信息,而且要由项目经理,下令大家严格按照重构机制做系统。这样也好,系统完成后,也会形成一份统一的重构方法集合,可以作为系统开发文档的一部分,而且这部分是相当重要的。

  我其实找不到一种好的项目开发模式,从而有很多重构思想,在现实中没有充分的发挥,希望大家也讨论讨论,能让我们更多的进行实践,而不是纯粹理论。

  关于重构的细节,我想网上已经有很多资料了,我相信,那对我们是非常重要的,当然我也是只懂一点点,这需要慢慢体会与研究的。



C/S框架网|原创精神.创造价值.打造精品

扫一扫加微信
C/S框架网作者微信 C/S框架网|原创作品.质量保障.竭诚为您服务

上一篇 下一篇