2008年三月月 发布的文章

软件业的'图纸'在哪里?

上周日和橱柜公司商量好,下午三点到我的房子量尺,橱柜设计师按时到达,拿着一卷尺开始了测量工作。有过装修经历的人都知道:在装修公司进场之前需要橱柜设计师出一份水电改造图,便于装修公司人员确定水电改造的具体方法。装修公司的施工人员与橱柜设计师之间仅需要一份设计图纸就可以完成水电路改造的沟通,这不由得让我想起这样一个问题:"软件开发领域的"图纸"在哪里呢"?

"图纸"是建筑行业的标准的共同语言,它能让设计师与施工者无缝沟通,同时由于建筑图纸的形象性,普通人看了基本也能了解一二,这样普通用户和设计师沟通起来也是很容易的,即使是一个外国设计师设计的图纸,只要使用了标准的图纸符号,中国的施工者也可以完美的将之实现出来,反之中国设计师的作品,外国施工人员也亦然可以实现之。软件行业的人总喜欢拿软件开发与建筑行业做比较,设计模式就是其中最典型的例子。不过这么多年来,软件开发过程仍然无法达到建筑业的那么"精确",这里的精确不是指过程和进度的精确,而是沟通的"精确"。

软件开发领域的"报怨声"已经持续了几十年了,需求分析人员无法获取用户的准确需求、系统设计人员无法将自己的全部设计思想很好的传达给编程实现人员,人们都在抱怨:缺少一种"共同语言",能让他们之间"无缝的沟通"。软件业的大师们绞尽脑汁、费尽心思、提出了多种沟通语言,以试图解决这个问题。这里面最著名的莫过于由OMG组织于20世纪末推出的"统一建模语言(UML)"了,顾名思义,UML试图统一软件开发领域所有过程阶段的"沟通标准",需求阶段有Use Case图;设计阶段有组件图、类图;部署阶段有部署图,另外还有序列图、状态图、活动图作为辅助。UML到目前为止也从1.0发展到了2.0版本,但其实际应用情况如何呢?乐观点说是:没有"图纸"在建筑领域应用的那么广;如果从我了解的和接触的实际情况来看,UML已经过了其高峰期,开始变得"不瘟不火"。

程序员多数喜欢简单化、个性化和形象化的表达思想,一块白板,无拘无束。虽然UML在形象化上做的还不错,但是却始终无法打动程序员的心扉。从另一个事实来讲,图纸是建筑行业的门槛或者说是基础,而与之对应,代码才是软件行业的门槛。这样一来似乎代码才应该是一种共同的语言,在"敏捷软件开发"的附录中就有这样一篇文章:"源代码即设计"。那是否说:"代码"就是"软件业的图纸"呢?"代码"在设计开发人员之间可以说是基本无缝的,但是对于普通客户而言,代码似乎太专业了。其实在建筑行业"图纸"也多在设计师和设计师、设计师与施工人员之间做沟通之用,大项目中少有客户与设计师沟通时使用"图纸",多数会用外观效果图。这样一来似乎软件开发领域的"代码"与建筑业"图纸"的概念达到了一定的一致性。"代码"作为沟通媒介的前提是:代码和设计的统一。为了达到这一目的,需要代码结构清晰,可读性,可沟通性要好,这也势必需要实现人员提高编码技艺。都说编程是一门艺术,从这里来看,名符其实。如果承认"代码"这一地位,那么实际上是确定了一个方向,以后向这个方向努力就是了,众所周知的"敏捷"在这个方向上做出了努力。

上面也已经说过,"代码"过于专业,并不能作为"统一沟通媒介"来统一整个软件开发过程,看来我们只能继续期待头脑中理想的"图纸"的出现了,也许它会诞生于将来的一个突破性的"发明"或"发现“;也可能它将是一个永远的"梦"。

面对'破窗户'的无奈

每天早晨都是坐公司的班车上班的,从家到公司大约需要40分钟,这段时间不短也不长。为了打发时间,也曾经想过要充分利用这段时间,我选择过听音乐、看书。但音乐听时间长了就听烦了;在车上看书时间长了还有些头晕,所以多数时间我还是选择"思考"。"思考"的同时,眼睛也一直在"欣赏"车窗外的风景。今天窗外一处新楼盘门市的两个破碎的窗户让我的"思考"有了方向。

建筑物上的几扇"破窗户",很多人即使注意了,也会不以为然。但是对于看过 Andrew Hunt 和David Thomas合著的"程序员修炼之道"一书的程序员们也许都会"见景生情",因为在工作中身为程序员的我们时常(甚至总是)和"破窗户"打交道。

万事万物都是有其共同的规律的:建筑物上的破窗户、牙齿上的"小洞"、软件中的低劣设计、糟糕代码的等等,在其出现的初期也许并未显现出问题,但是如果你没有及时修复,建筑物上也许会出现更多破窗户、被丢了很多垃圾、被胡乱的信手涂鸦;牙齿上的洞洞越来越大,周围的牙齿也受到牵连,开始出现"小洞";软件中低劣的设计风格被继承、糟糕的代码被复制并被散布到系统的方方面面,以至于到最后无法控制,或者是花费很大力气来修复。

面对"破窗户",常有这样几类情形:
1) 无法识别"破窗户";
2) 识别出"破窗户",但不愿修复;
3) 识别出"破窗户",有修复意愿,但"破窗户"难于修复,或者修复成本太高,或外部因素(时间、人员、成本)导致资源不足以修复这些"破窗户";
4) 遇到"破窗户",立即修复。
前两种情况,一个是水平问题;另一个就是职业素养问题了,这里不多说;我们常遇到的情况往往是最后两种,如果是最后一种,其实你是幸运的,多数这种情形下你从事的一个新的系统或者项目,没有太多的遗留代码,一切都在自己的控制之下,通过重构可以达到修复"破窗户"的目的;但是如果是第三种情况,那往往是最让人痛苦的-自己无法控制,即使有渴望有热情有能力去修复那些"破窗户",但迫于系统庞大,业务复杂,时间有限而不敢轻易出手,更让人痛心的是,系统中"破窗户"的设计和代码渐渐传染给新人,新人在维护系统时就会"以丑为美",继续在系统上"涂鸦",引入更多"破窗户"。由此可见及时的修复"破窗户"还兼有"整治歪风邪气"之作用。

在有"破窗户"的项目上增量开发风险很大,特别是当系统业务复杂、架构复杂时,添加一个很小的功能都应谨慎,最好能有完善的单元测试Case做保障。说到单元测试Case,设计起来又谈何容易,特别是对于由C写成的复杂业务系统,C语言本身就缺乏足够理想的单元测试工具,或者说像C这样的语言好似天生就和"单元测试"的概念无法和谐共生。对于复杂的业务单元,我们很难或者无法从纷繁芜杂的业务逻辑中剥离,或者说还是由于代码设计上的"破窗户"导致的不可测性,让"破窗户"得以延续。除非管理层狠下决心,重写系统。现在开始觉得与编写上层复杂业务逻辑相比,能编写一个独立底层库或者实现某种算法算是幸福了,因为你会有一种"可控"的感觉,而不是写完代码心里发虚的很;至于在有"破窗户"的系统上写业务逻辑,那就会又多出另外一种感觉-无奈了。

说说用xml做配置文件的优劣

最近收到客户的一个需求,要求我们将产品的系统配置数据和业务配置数据定期导出备份,以防万一数据库宕掉后可以用来"救火"。产品从起初0.1版本就一直延续着一种"section-key-value"的配置文件方式,同时我们也有可复用的库来完成配置数据的读取,可是在长期的使用过程中我们发现的不少问题,特别是在存储多样化的业务数据的时候,这样的配置方式带来维护上的很大不便。

"section-key-value"这样的配置文件方式或者类似于环境变量似的配置文件方式用来做系统自己的配置可以说既简单又实用,像著名的Apache服务器、版本控制系统svn等都是采用这种方式。在我们产品的初期,那时的业务相对简单,采用这样的一种配置方式还算是合适的。但随着业务复杂度的上升,种类繁多的业务数据的出现,这种配置方式的弊端渐渐显现。

最大的弊端就是"同步"问题。每当我们的产品升级时,我们一般都会先升级数据库的配置,然后再同步文档,最后同步配置文件以及相关读取代码。如果工作量较大,升级工期较紧的时候,常常忽略了将新增或修改的配置同步到配置文件;这样累积到一定时间之后,除了花费大力气去"补",别无它法。另外一个弊端就是上面提到的那个问题:从数据库导出配置文件始终是那么"别扭",曾经尝试过使用脚本导出、Java程序导出,但是始终不能让人很满意,挖掘一下深层原因:配置文件和数据库表设计"不搭调"。业务数据千变万化,导致从数据库导出配置文件的逻辑甚是复杂,维护起来十分不便;而且像"section-key-value"这样的结构,数据库中由于没有section的字串,导致这些section必须"写死"在代码中。

不错,我们在寻找替代品,目标锁定在xml。曾经在2005年做的一个项目中尝试过使用xml作为配置数据,取得了很好的效果。记得当时参考Ant的build.xml的配置方式,顺利解决了一个"自动化处理"的配置设计,那应该是部门第一次采用xml做为后台C实现的系统的配置文件。也是自那以后,我感受到了xml的强大描述能力。xml在Java世界可以说占据了大部江山,从DB导出数据到xml可以说轻而易举,这又恰好解决了本篇所提到的"同步"难题。

坐在公司的Bus上,大致想出了如下xml作为配置文件的好处:
1) 与DB表几乎无缝转换,方便导入导出;
2) 作为元语言,其描述能力毋庸置疑;
3) 在Java世界几乎是配置文件的首选或者说是标准也不过分,选择标准的,总会被支持的很好;
4) 诸多开源工具支持对XML的读写甚至支持加密;
5) 文本形式,方便浏览和信息查找(grep or find均可派得上用场),这也符合Unix编程艺术(TAOUP)作者在书中阐述的一个原则-尽量文本化。
6) DTD或schema验证,自动验证格式是否OK。
… …

当然缺点也是有的:
1) 如果不加密,是明文,保存账户、密码等数据时要小心,当然这也是文本配置的通病;
2) 如果设计不当,会导致"xml地狱",xml太多也太烦,很多Java世界的产品就有此弊病。

大致在心里估算了一下,读取xml承载的配置与读取传统的配置的代码量没有太大出入,但是如果xml设计的足够精致,后期的维护工作将大为减少。xml配置改造工作看来势在必行了。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多