软件系统设计的问题:没适应用户需求和环境

注:此文来自新浪微博网友@哲学家灰太郎 的推荐。

在做系统设计的时候,常常遇到这样的设计,如某个技术牛人,他对某个技术非常熟 悉。那么在设计中,他会使用该技术作为主要设计,还有的看到什么流行就用什么技术。 有的采用二次开发框架减少开发量来做设计。但所有这些设计都共同犯了个错误,即你的设计是要适应用户的需求和环境,

也许他说,我的很适应啊?那么在你说这句话之前,你是否调查过呢?如果你认为用户提出的就可以了,那么就错了,用户是很难提出全面的问题,因为你是解决商,你必须得会去解决。

一个好的设计师除了了解需求,还得要挖掘用户真实的意图,有些意图虽然用户说不出,但一旦你挖掘出说给用户,用户会说啊,就是这样的。

一个好的系统设计师需要的是站在用户的立场去考虑问题,然而我遇到的许多设计师 却从来都是从自己的框架技术上考虑问题。当他们在预设,限制因素等等上出现问题的时候,那么系统就会变得和预期的差别很大。

举个例子:一个设计师设计了一个系统,采用消息队列和MDB,来操作业务,整个设计看起来的确很清晰和完整。 当我接手他们已经做好的系统,我用流程图和序列图把整个业务画了一遍,

发现流程线有多余及回路,复杂度高,这样的设计会有问题。

但接下来的问题来了,其系统对环境依赖很大,大量的xml配置文件,WAS相差0.0.19个版本 也出现系统不能运行,即使是测试环境和生产环境一致,也出现,系统不能运行。

结果我们花在环境部署上的时间达1个月。 另这样的设计由于技术有点难度,导致开发周期增长。

如果开始设计成简单的技术servlet+socket实现 将缩短2个月时间。且性能也很高。

总算部署好了,接下来问题又来了,系统内存暴涨。。在测试环境一点问题也没有,但到了生产环境出问题,由于生产环境不能随便装东西,不能随便去调试,导致没法找出问题。

后来总结发现,我们的系统是部署在客户的共享环境-就是你得和其他人的7、8个系统共享系统环境,不是独立部署,不能随便改设置,改了影响别人怎么办?比如你把MDB时间调高。。

也就是说必须沿用以前系统的设置,要么你的系统对设置不依赖性。否则就容易出问题。结果不得不走原路,用servlet+socket最简单的技术实现

从这个例子的教训告诉设计师:给用户的设计原则

1、性能要符合要求

2、要注意具体环境是什么?设计之初就要考虑

3、要考虑以后维护人的成本,是不是一个毕业生学一二个月就能维护呢?还是需要高手?

对于用户来说,稳定和可用性是第一的,技术不是主要,除非你的技术提高性能很高或很容易扩展。再好的技术,再牛的技术,造成不可用,或费劲,那么都是垃圾。

在设计中还有个现象,就是有的设计者试图设计一个二次开发框架,给客户做系统,配置配置就好了或稍加改动,这样对于自己来说是成本最低。 这的确是个好想法,许多地方应用也是很不错的,但这样的框架不是所有的用户环境都适用。

有的明知道不适应,还是先忽悠用户,以后再改再加,结果未来的系统将是一个四不像。

用这样的系统最大的风险就是 ,对厂商依赖,离开了二次开发框架则无法继续业务,需要扩展改框架还必须得原厂商来做,这时候可以报告价格了,也就是说客户被吊死在这个系统上,除非以后可以重新做一套。

有设计师说,你说的不对,我的二次开发时可以扩展的,没错,是可以扩展,但扩展的力度,复杂业务的扩展,导致,你必须在系统外再构建接口,或者系统内构建修改业务。 这样的系统那还算是二次开发框架吗,

最后发现修改的成本和开发新的差不了多少? 另外,框架升级怎么办?你总不能像WAS,weblogic那样吧具有通用性升级?你难道把所有J2EE、SOAP协议层也加进去?

因此一个好的设计师必须是:站在用户的角度(当然要兼顾自己的利润),

除了设计满足用户体验度的产品,对应系统的架构,必须考虑前面三点。

==============================================

系统框架设计一般分为三种,一种是基于中间件的可扩展的框架,一种是可重复的框架,一种是可扩展及重复的款架。

第一种是依赖于第三方中间件如strutsspring等等,这是通用做法的框架。

优点:使用多,不含业务,可以任意架构业务。,缺点:业务逻辑和业务组件必须要自己开发。

第二种做法是把业务逻辑抽象出来,形成自己的框架,通过配置可生成界面或操作,客户端通过服务端的数据解析生成界面和操作。

优点:方便,复用性,特别适用于展现架构。可通过可视化展现出来,通过二次开发即可,二次开发技术要求低。适应简单业务变化,适合于OA,类浏览器(如UCWeb等等)、内容管理,CRM,业务展现部分等等

缺点:不是所有的业务都可以抽象出来,可抽象的仅仅是共性的东西。如果扩展的话,必须客户端和服务端都要修改。(比如密钥和安全系统,账务,对账清算等等不是靠配置配置就可以的)

手机端和客户端的操作系统变化太快,客户端存在版本升级的问题,不能利用新的手机系统UI,要么就修改客户端,服务端也相应修改。维护工作并不减少。

由于这样的架构是单个厂商开发的,不具备通用性和开发性,如果你要接入其他系统,或其他系统接入,框架必须做大的修改(因为框架设计之初是不会考虑太多负责环境的),

整个架构依赖于厂商,离开了厂商将无法维护和增加(即使他们提供源码,也难底层代码维护)。

想扩展的时候,不得不继续,导致未来成本增加。

也就是说:方便性高,服务框架的引擎复杂度越高,反而灵活性,可维护扩展性低,环境适应差(比如环境忽然换到内网,或者不同网段,访问受限制等等就难扩展了)。

适应范围有限,特别复杂业务和安全的不适应。

第三种:根据不同的业务来设计框架,并利用成熟的如中间件等等,组合应用,保证底层的稳定复杂和安全,并可扩展新业务组件,以组件方式不断增加方式的递增扩展。

这种框架常用:消息队列,EJB,MDB,服务总线,服务调度和反射等等。

优点:不依赖于产商,具有灵活、可扩展性好,环境适应强,业务不需要如第二种做高度抽象出来,可直接实现到可扩展组件中。全部组件化管理,适在此基础上可方便扩展生成出第二种框架。

用不同层次的平台,从内容管理,CRM等(大材小用)到适用于内部系统,各种平台资源的结合和调用,适合各种安全体制,适用于政府、大型企业系统。

维护扩展方便,部署热部署方便。

缺点:和第一种一样,不方便直接可视化展现架构业务,不对技术要求高些,架构要在初期设计中设计完善,


收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部