复杂性的代价:
系统架构上的复杂性,如果并非出于必要,则一定是坏事.
它的影响主要:
1 . 带来大量不必要的代码,这些代码的每一行都需要编写,测试,而且需要带来很大的维护成本
2. 复杂的架构,往往也意味着性能的低下。
3. 复杂的架构往往会使构建比较复杂,并且往往依赖于一些复杂的工具.
4. 复杂的代码难于理解,也就是说,你很难往这的项目中再添加人员,要理解、维护这些代码,成本之大将超过预期收益.
XP 对于复杂性的理念是: 选择能够奏效的最简单的做法.
再来看看,导致复杂性架构的原因有哪些?
1. 使用复杂的技术解决方案,比如以前的EJB
2. 将对象分布化:
将对象分布化常常会诱发以下几个复杂的情况:
(1) 你需要在不同的服务器中传输对象,若是需要传输一个复杂层级的对象,将会非常困难.
(2) 分布式应用的部署将会非常的复杂,和难于监控.我们需要在不同节点之间保持代码同步,所以在一个集群上部署新的二进制程序将会是非常复杂的
(3) 所有远程调用都需要面对网络问题,对于类似的异常处理,也是增加复杂度的方面之一
(4) 对于分布式代码的测试变得异常复杂,因为要测试多种故障场景以及形形色色的部署现场.
另:
在人们中有一种广为传播的信念:分布式应用系统是高度可扩展的,这也是支持对象分布化的主要论点。
但是事实是,这基本是一个神话。 人们认为可以通过 4个tomcat容器,8个EJB容器来扩展应用,所有请求都通过WEB层来进行远程调用。
这里的主要问题是: 每次远程调用消耗的性能过于高,将设理论上这样的调用真是有所收益的话,也早被网络消耗光拉。
我们更加倾向于: 将应用完整镜像到一个集群,每个镜像放在集群中的机器上,用同一个JVM来跑应用,通过硬件或者web容器的负载均衡技术来对前台的请求来进行分流。让每个机器上的代码都相同,而且每一个应用都是跑在各自机器的一个JVM实例中,这样的效率要远远高于分布式应用.
3.模式病
系统架构过于偏向于模式的应用,生搬硬套,导致应用过于复杂
4.各个软件厂商的忽悠
厂商将复杂的应用以最佳实践方式放出来,以显示他们的产品又多强大,但是往往他们给的最佳实践或许对真正的需求帮助并不大,反而会将应用架构带入泥潭
结论: 借用quick sort作者,也是图灵奖获得者C.H.A.R.Hoare的一句有深意的话来说:
“有两种软件开发的方法:一种是尽量把事情做得简单,让人一看就知道系统明显没有缺陷;一种是把事情尽量复杂,这样一来,也就没有明显的缺陷。”
分享到:
相关推荐
非常简单的J2EE购物车非常简单的J2EE购物车
DWR-J2EE 简单例子 DWR-J2EE 简单例子 DWR-J2EE 简单例子 希望帮助一些入门的新手
j2ee的个人简单总结,主要是针对基础的汇总。
关于j2ee的介绍包括一些J2EE初学者需要注意的问题和基本的框架
J2EE登录案例,其中包括了Struts和Struts2等登录案例,代码中对初学者容易错的地方,有提示性注释。
J2EE简单实例,还有一些BUG,只供初学者学习
一个简单的打卡系统,运用到SSH框架 适合新手学习
基于J2EE 开发的简单进销存软件,有表结构,基础数据等
J2EE 实现简单登录只是简单的登录功能没其他的了
用struts和SQL Server做的简单购物系统
这是一个简单的J2EE初级项目。。主要是用servlet 实现操作
基于Hibernate+spring+struts的J2EE简单运用
这是一个简易留言版系统,用户可以登录,注册,留言
技术点:Servlet、JDBC、JSTL 功能:系统实现了模型—视图---控制器模式(MVC),划分为二个子系统:基于注册用户的电子商务交易平台和管理员的数据管理系统(会员管理,商品管理和订单管理)
适合初学者,最简单的j2ee管理系统开发,快没分才发布的。
对于j2EE的简单web开发,其中有各种j2EE web开发过程中会使用到的技巧,如el表达式,jstl自定义标签,过滤器的使用等 通过这些来实现登录 注册 修改 删除 分页 等功能
用了javabean和jsp做的简单的网上选课系统,大家借鉴一下。
基于TOMCAT和ORACLE10G,J2EE实现的小型ERP物流管理系统,适合作为学习以及课程作业等使用。使用请用MyEclipse导入工程!
简单的书籍管理 适合初学者学习
桂电信科J2EE程序设计实验二 JSP实现简单的登录模块