寂寞季节

因为彼此寂寞,我们走进共同季节
posts - 7, comments - 7, trackbacks - 0, articles - 3
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

公告

2004年11月1日

最近看了一篇CSND上的一个帖子,提到了该问题,看来他的困惑也是我的困惑。
我将最近做的项目一步一步展开,做一些问题的分析。
先做一个例子: 以一个工厂信息化系统为例,先从大的方向说起,然后在根据自身的具体情况做一些讨论。

提到工厂的信息化系统很个笼统的问题,先从大的方向做些了解:
    大的方向:    
        要知道用户所说的信息化到底是什么。是使用电脑来办公,还是用电脑做信息发布的平台,还是用这些信息系统来管理,还是使用这个信息系统来辅助管理。
        做这些事情到底需要做到什么水平,客户心目中的期望值有多高,他们对于信息系统的了解有多少,他们对于信息系统的控制能力有多少。
    细节方向:
     了解目前客户信息化状况,   然后你还要具体的了解一下,他们说的管理人财物究竟是个什么水平的管理,是一个单纯的流水账,还是一个辅助的系统,或者是一个复杂的自动管理系统。而他们说的售前售后系统到底意味着什么,是单纯的一个简单的纪录,还是一个CRM的雏形,还是要使用数据挖掘的一个CRM。而他们说的物料系统,包括不包括采购,包括不包括部件的外包,是一个简单的系统,还是要搞一个SCM(供应链系统,不是配置管理)。
    人员的管理,是不是包括人事系统和劳动保障系统,需要不需要和政府的系统连接,是不是好要包括HR的很多东西,和财物的接口是按照什么方式进行。办公自动化究竟是怎么自动化,包括不包括很多管理的内容.
    等这些了解之后,在来看项目规模到底有多大,周期有多少,参与的人员应该有哪些。

posted @ 2004-11-01 10:47 情怀依旧 阅读(420) 评论(0) 编辑

引用(O6Z)
    减少耦合首先要从判断什么是耦合开始,这个问题我们不会有太多的分歧。
我们都应该明白耦合不是不可避免的,所以完全的去耦合根本就不可能。而实际上任何的应用在现实中,以及在我的认识中都受到其他因素的影响。这也使我们的设计实际上根本就不可能完全的达到去耦合。于是我们可以从职责的细分开始,也就是让职责可以在一个合适的粒度上,这样这个粒度的职责就总是被调用,而不是去调用别人然后又被调用这样的互相紧密关联。
同时我们也要注意到去耦合根本就不只是一个存在于面向对象领域的特殊概念,而是在任何的方式下都存在的问题。我也要注意到去耦合所要解决的问题是更好的面对变更,或者说是更好的可以被扩展。忘记这两点,单纯的探讨去耦合是没有意义的。也就是说我们要认识到,如果你的程序需求完全的确定,不需要考虑变更,你为区耦合作出的努力根本就没有价值。而且去耦往往还意味着,对于运行效能的降低。而实际上去耦的同时往往可能会带来新的潜在的耦合。实际上这里还是要落实到你的程序段落的职责是不适很明确的问题。
而耦合会带来系统的关联钝化,让你很难确认你的关注点。这其实也带来了你去耦的难度。而这实际上还是你的系统职责不清稀带来的去耦隐患。你要做的还是明确各个部分的职责。
而说到最后,实际上情况非常简单,就是你明确你的系统的职责。这可以用单一职责规则来得到保障,也就是你的程序中一个要素变化的原因,就只能是一个,一个改变只能带来一个直接的结果。任何的去藕无非就是在这个原则下就职责和职责的原因以及后果进行细分和组织。

posted @ 2004-11-01 09:43 情怀依旧 阅读(2415) 评论(1) 编辑