模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。
作者 Vikas Hazrati 译者 张龙 发布于 2009年10月27日 上午5时43分
术语”技术债务“是由Ward Cunningham首次提出,指的是开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案,但从长远来看,这种方案会带来更消极的影响,亦即开发团队所欠的债务。敏捷专家们就技术债务到底是什么以及如何对其进行分类给出了自己的看法。
Martin Fowler认为下面的定义最能表现技术债务的含义:
技术债务类似于金融债务,它也会产生利息,这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多努力的后果。我们可以选择继续支付利息,也可以通过重构之前鲁莽的设计来将本金一次付清。虽然一次性付清本金需要代价,但却可以降低未来的利息。
Steve McConnell将技术债务分为两类:
Bob大叔补充到,有时人们将坏味道也看作是技术债务,但这是错误的,他说:
坏味道并非技术债务。坏味道就是坏味道。技术债务的评价标准是真实的项目约束,这些约束是风险和好处并存的。坏味道的产生永远都不是理性的结果,而是由懒惰和外行导致的,未来也没有机会偿还了。坏味道总是意味着损失。
Bob大叔说技术债务让人们时刻牢记保持代码的整洁,就好像一个人在背负巨大的抵押债务时需要时刻保持警醒一样。他又说一旦团队决定采纳技术债务,那就意味着保持代码的整洁将变得空前的重要。如果不这样,情况很快就会变得糟糕不堪,偿还这些债务的代价也变得越来越大。
Martin Fowler认为坏味道也是技术债务,只不过是另一种形式的技术债务而已。他觉得坏味道是一种不计后果(reckless)的债务,相对于根据精确计算而得来的谨慎的(prudent)债务而言,坏味道会让问题变得更加严重。他又加上了故意(deliberate)以及无意(inadvertent)从而将技术债务划分为四个象限。
Martin通过如下示例将技术债务划分为4个象限:
综上所述,实际的项目中将不可避免地存在技术债务问题,这是无法杜绝的,但问题的关键在于千万不能引入不计后果的债务,因为它会持续不断地产生坏味道,也很难对付。
查看英文原文:Dissecting Technical Debt
Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful about thinking about how to deal with design problems, and how to communicate that thinking. A particular benefit of the debt metaphor is that it's very handy for communicating to non-technical people.
由此可见,是否技术债务在很大程度上并不是由开发团队决定的,而是开发团队和客户在沟通的过程中达成的共识。此外,无论与否,都是缘木求鱼而已
本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。
项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。
在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。
Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。
Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。
1 条回复
关注此讨论 回复