rmartin-CSDN博客

原创 Scrum Master也山寨 (之二) -- 傀儡Master

笔者通过分享一家外资知名公司的Scrum Master面试经历来和大家分享下为什么Scrum Master会成为'傀儡'

2010-07-06 16:50:00 7554 10

原创 Scrum Master也山寨

就Bob大叔最近的关于Scrum一篇深入的批判性文章，笔者愿意结合7年敏捷的经验，就当下流行的Scrum Master和大家深入的探讨下。

2010-07-05 15:45:00 7597 12

翻译 Scrum是在这些方面‘被失败’

最近，Bob大叔就采纳Scrum/Agile是否有短板的疑问作出了其“七宗罪”的回应。他说到，总的来说Scrum是有些严重的缺陷，并且也就大多数已经采用了Scrum的团队提出了避免这些问题的建议：技术上没有建设：Scrum是个项目管理的框架，却没有针对技术做出任何建议。Bob建议团队“需要借鉴其他敏捷的方法学，比如XP（极限编程）。XP在技术方面的这套实践是很有帮助的：TDD（测试驱动开

2010-02-27 17:54:00 6345 2

翻译来自石器时代的困惑

本文是Uncle Bob对软件行业由来已久的三个颇具争议的问题的回应。其中有小部分与其它一些篇章太有相关性，不易阅读，译者未将其纳入本文之中。有兴趣的朋友可以参考Uncle Bob原文。 TDD这个世上还有人还觉得TDD会导致开发速度减慢的话，就好像是活在石器时代的人一样。对不起，不过这可是事实。TDD不会令你变慢，它只会使你加快。好吧，

2010-01-02 16:27:00 5534 3

翻译 TDD精神障碍综合征

近期，我的一些关于TDD、设计模式、同步乃至数独问题的博客好像招惹了很多TDD反对者的怨言。不乏有人态度粗鲁、具攻击性、嘲枫、轻蔑而且不成熟。嗯，万圣节就快到了。尽管他们自圆其说，但确实也提出了一点儿合理的疑问。为了公平起见，我想在这里回答会比较合适。 TDD有科学依据吗？确有充足的依据。用Google简单检索了下，

2009-12-29 13:06:00 6960 4

翻译容器外的JSP页面测试技术

Jsp测试技术开发web应用程序最恼人的一点就是想要测试的话你就必须向将其部署好。当然，并不是所有部分都这样。如果你是经过了精心的设计的话，你可以在Java程序中测试业务逻辑。你可以在应用服务器不运行的情况下测试数据访问、接口以及存储过程。不过如果是测试GUI的话（由Jsp所产生的HTMl），你就必须向将其部署，然后才可能测试。很多的团队求助于Sellenium，Mercury或是其他的一

2007-05-21 10:41:00 11110 1

关于此的好的、坏的想必你都已经了解得很多了。本篇文章会抛开商家们的流言蜚语，用一种简单易懂的方式来阐述面向服务编程。这会是你所看到关于SOA的独一无二的介绍。在日常业务中有些事物并不时常改变，比如说美国加油站一直以来都在用加仑为单位销售汽油，餐馆依然使用菜单，牙科医生还是会每六个月就销售一次清洁用品。每种业务都会有一些方面不时常变动，而这部分往往占据了是业务的绝大部分。我们就称这些为核心业务功能（

2007-04-18 17:44:00 9621 3

翻译用户界面测试系列之一

GUI测试是测试驱动开发的经典难题之一。很多团队在他们项目中的很多部分都采用过TDD，但却因为某种原因而无法在GUI模块中充分进行。在这一系列的撰文中我要告诉你GUI测试其实是个可解决的问题。这些年来，TDD社区已经积累了一些工具、框架、类库或是其他的技术。这些技术让你能够完整的测试GUI代码就像测试其他模块一样。Ruby on Rails在Web开发世界里，没有任何社区能够像Ruby

2007-01-30 09:26:00 10550

翻译晦涩的Java日期处理

本文实在是旨在对Java标准库中日期处理之晦涩不堪现状的怒斥。在你反驳之前，请确信你了解过Joda（译注1）。我们问题的引发是因为所交付的客户不接受（因为某种原因）在其项目中使用开源的资源。我与我的同事们最近在开发管理类库的一个简单的Java应用程序。昨天，我开始编写一个用来计算过期图书的罚金的模块，完成该模块就要算出截止日期与当前日期的间隔天数。其实也就是两个日期做下减法，可是，Java标准

2006-12-22 10:56:00 13347 5

翻译软体艺术系列--抽象工厂（原文最终修订于2006年10月18日凌晨04:25:06）

2002年三月四日，星期一早上11点钟...我可不想还像上周五那样迟到，于是就和大家一同走入会议室，而且看见Adelaide正要准备开始演说。我们的小小团队成长的迅速。有几位同事我还都没见过面。数了数，房间里座着25位成员，Jean也在其中。为了引起注意，Adelaide敲了敲桌子，大家也都坐定。她很显然，有些紧张，不过也信誓旦旦。于是先镇定了一下，然后就开始了演说。“大家好，Jasm

2006-12-07 14:28:00 8602

翻译结对编程的成熟度模型（原文最终修订于 2006-10-08 上午10:52:35）

上周，我花了四个工作日的时间和Tim Ottinger坐在一起来开发FitNesse的一项新功能。考虑到Tim在FitNesse上还是个新手，于是我就从先为他介绍一些底层架构开始，然后再一起开发新功能。看来Tim觉得这样还挺管用，随后他就要求把自己添加到了可修改FitNesse的人员列表中。我们一起开发的功能是一个新的导航功能，叫做“向后查找”。它支持你按照如下方式来定义页面：其中的Som

2006-10-16 10:57:00 10252 2

翻译敏捷的底线

过去的四年以来，软件业一直在努力的追赶着像是极限编程这样的敏捷方法的步伐。它们有什么好处呢？能奏效么？我们是不是应该去相信这些关于它们的传言呢？我们是不是也应该在项目中进行尝试？这些结论值得信赖么？刊物、文章都在对应用敏捷方法所带来的难以置信的效果大肆的进行渲染，也有一些文章把敏捷方法贬损为使得软件开发倒退回石器时代的方法。我们听说过人们为此而取得的了不起的成就，也听说过其他一些人告诉说敏捷让

2006-10-11 16:33:00 11243

翻译面向对象设计的11原则--你称得上OO专家么？（原文最终修订于2006-04-10 下午06:19:40）

面向对象设计是什么？都包含了哪些内容？它所带来的好处是什么？需要你为之付出些什么？在如今这个年代，问这些问题似乎显得很愚蠢，因为这年头几乎每位软件开发人员都知道如何使用某种面向对象编程语言。可是这个问题还是很重要，因为在我看来，绝大多数人在使用这些语言的时候并不知道为什么，而且也不知该如何最充分的运用它们。软件业曾经爆发过的所有变革里，其中曾经有两个派系如此广泛的深入人心，它们就是结构化编程和

2006-09-28 10:18:00 18895 1

翻译软件文档--扬弃还是传承（原文最终修订于 2006-04-12，上午12:41:14）

在本人的《敏捷软件开发：原则、模式与实践》一书中曾提到“Martin对编写文档的第一原则是：除非是必须马上撰写文档而且意义重大，否则的话就干脆不要写它”。有些人把这个意思曲解为敏捷开发一种不需要文档的开发过程，这并不属实。文档是所有软件开发过程中必不可缺的环节，打着“敏捷”的幌子拒绝编写文档是一种不健全的偏激行径，而且这与那些不假思索就容忍产品中包含十几种不同文档，且自称是“开发过程的终极回归

2006-09-26 15:44:00 8604

翻译赛门铁克公司的极限之旅

摘要经过了极限编程的洗礼，赛门铁克的开发人员、测试人员、技术撰稿者和管理者们都感到收获颇丰...甚至其高层管理者都为之震撼正文这是一个阳光明媚的三月早晨，我在犹他州的American Fork市，这里的小型工业园区被Wasatch众山所环绕，其中有一座双层建筑，在它的二楼的一间宽敞的四面玻璃的房间里，25个工作人员（一共有120位工作人员）正环绕着中间的一组办公桌和电脑围成一圈。这是一

2006-09-12 15:52:00 10175 1

翻译 Java,C++和Ruby的性能PK（续文）--关于凸包算法（convex hull）的效率

译者序本篇blog实际上是Bob大叔对xreborner的一连串的发贴给于的回复（xreborner在上篇blog中对Bob大叔提出了一系列犀利的维护C++权益的观点）。正文我在最近的一篇blog中对比了C++、Java和Ruby的时间消耗，其中一个参与者（xreborner）提交了一个convex hull的凸包算法代码。我花了好久来研究其中的蹊跷，直到把算法绘制于图上，才发现自己是

2006-09-09 23:14:00 11859

翻译让软件走近“恐怖地带”的元凶--未经测试的代码（原文最终修订于 2006-09-05 晚上10:33:27）

Cedric Beust（译注1）在最近一篇blog中引用了我的几篇发贴，其中包括关于“junit邮件列表”，“测试覆盖率需达到90%以上才算是有效代码”，还有“如果没有这么高覆盖率的话，那就一种非专业行为”（译注2）等。Cedric对此的回复是这样的：那是有点极端了，不过也并非全盘错误。而这句话没能鉴别出来的是其实有太多种层次上的“非专业”。我都能想出一些比“发布未经测试的代码”来得更严重的

2006-09-05 11:45:00 7999

翻译使用Mock Object危险么？（原文最终修订于 2006-09-02 下午03：53：51）

Cedric Beust（译注１）在最近的一篇blog中提到：“使用Mock Object（译注２）能给你的是虚假的满足感，所以你应该避免使用它们，除非迫不得已。” 使用Mock Object的动机是确保所模仿的对象能够被正确的使用，这与确保系统在整体上能够正常地工作是两码事。实际上，这是单元测试和验收测试之间必要的不同之处。单元测试只测试一个单元（唏嘘之声~）。一个优秀的单元测试只测

2006-09-03 19:22:00 9238 1

翻译三大编程语言的性能PK--Java, C/C++和Ruby （原文最终修订于 2006-09-05 下午06:19:40）

译者序本文虽然标题略有争议，但Bob大叔撰写此文并非是要说明Java>C/C++>Ruby，而是延续上篇“性能调优--永远超乎想象”的风格，借以说明程序的性能一般都超乎我们想象的观点，因此请读此文的C/C++爱好者少安毋躁:-)正文你可能会觉得下面的图表比较有意思，因为它是分别用三种编程语言（Ruby, Java, C/C++）写的埃拉托色尼质数过滤算法（译注：Sieve of Era

2006-08-30 11:36:00 42404 162

翻译性能调优--永远超乎想象（原文最终修订于 2006-08-28 晚上11：48：38）

多年以前，我在开发一个C++的应用程序。我的同伴Jim Newkirk（当时的）过来告诉说，我们的一个公用函数运行得非常的缓慢。这个函数是用来转换二进制的树结构数据为普通文本，并存储到文件中的。（这是在XML出现之前，但概念类似于XML）我审视了这个函数一会儿，发现了一个线性查找算法，于是毫无疑问的将这个线性查找算法替换为二分查找法（译注：binary search），然后就把这个函数交回给

2006-08-28 13:30:00 14273 9

翻译软件分析 Vs. 架构设计（原文最终修订于 2006-05-29 下午06：44：14）

何谓软件分析（analyse）？它有没有一个成文的定义？如果你曾读过软件教科书或是著作，就会发现有多少个作者，就有多少种分析的定义。具有讽刺意味的是，我们知道软件分析是必不可缺的，但却没有其真正的定义。一个用来区分软件分析与设计（design）的普遍方法是认为分析指“做什么” ，而设计指“怎么做”。乍听起来很有信服力，很显然，如果能在一开始就知道想要系统“做什么”，那至于系统应该“怎么做”就会

2006-08-24 15:53:00 10820 1

翻译 OO难题在Ruby中有了新解（原文最终修订于 2006-08-21 凌晨02：27：38）

单一职责原则（SRP）认为，一个类应该有且只有一个改变的原由。换个说法，一个类中的方法应该出于同样的一种原由而改变，它们不应被不同原由所驱使，而导致朝着不同的方向改变。举个例子来说，考虑一下以下的Java类：class Employee{ public Money calculatePay() {...} public void save() {...} public String

2006-08-23 16:23:00 4472 1

翻译如何让Ruby代码更简练？!（原文最终修订于 2006-08-18 下午02：42：25）

你可以用它来做什么呢？请阅读...我四前年曾接触过Ruby，就是为了看看这个语言到底什么样。我用了它一段时间然后就把注意力放到Fit，Fitness（译注1），和Java/.Net上了。然而最近，随着Rails的兴起，我又开始关注Ruby了；也开始认识到这是一个多么高效、亲和的语言。学习一项事物最有效的还是通过实战学习。所以我决定从一个Ruby的Kata（译注2）开始，这样就可以反复去练习

2006-08-22 10:26:00 6182 1

翻译 TDD的三条军规（原文最终修订于 2006-04-09 晚上09:45:01）

这些年来，我喜欢用下面这三条简单的规则来描述测试驱动开发：除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。只允许编写刚好能够导致失败的单元测试。（编译失败也属于一种失败）只允许编写刚好能够导致一个失败的单元测试通过的产品代码。对于任何功能，一定要从编写它的单元测试开始；但是到了原则2，你就不能再为那个单元测试写更多内容。只要一出

2006-08-17 16:52:00 9293 6

翻译微软眼中的TDD （原文最终修订于2006-06-11，下午03:20:52）

微软最近发布了测试驱动开发的方案（点击这里）。这些方案与Visual Studio 2005 Team System的使用密不可分。老实说，我对他们试图去把他们自己的工具与TDD（译注1）绑定起来并不觉得什么。他们是个商业机构，而这就是一种商业行为。让我觉得什么的，是他们如此完全的曲解了TDD，甚至反其道而行之。如果工具不支持TDD（它的确不能）的话，他们不应该声明它能够。在最近一篇blog（

2006-08-16 16:56:00 6130

翻译用Rails将敏捷Web开发进行到底！（原文最终修订于2006-08-14，凌晨03:49:12）

前些天我正好有时间学习Rails（译注1）。我就去了《用本主义程序员》的（译注2）网站（http://www.pragmaticprogrammer.com），而且购买了beta版的《用Rails进行敏捷web开发》。我于是就开始了阅读。这本书从初阶开始（就像大多数好书一样）。它指导你通过Ruby（译注3）和Rails的安装和设置，而且还提供给你一些简单的示例和测试让你可以确保你所运行的是正确

2006-08-14 20:23:00 6264 4

翻译敏捷开发的精神内涵（原文最终修订于2006-08-11 上午10:49:50）

从根本上来说，所有的敏捷开发实践，诸如TDD（译注1）、结对编程（译注2）、持续集成（译注3）和重构（译注4），都有一个统一的观念--永远不被阻拦。这就好像是一个优秀的撞球选手总要确保他的每一次击球都能为下一击创造好机会，每个优秀的敏捷开发者每有一点进展也都要确保下一步。一个优秀的敏捷开发者决不会走出一步，然后就无法再有进展，或是让别人没办法再有进展。那你怎么知道你的进度停下来了呢？如果你无法

2006-08-11 15:45:00 4083 1

翻译架构设计--仅是软件开发之第二大影响力？！（原文最终修订于2006-07-01 凌晨03:20:31）

SDWest2006（译注1）对我来说是个有趣的大会。我除了星期三之外（当时我正飞往费城参加一个客户会议 == 因此错过了Jolt颁奖部分）每天都在演讲。我也参加了一些谈话和会议；其中最引人关注的是Mike Cohn的计划与估算的谈话。我的两个谈话都是半天的关于Ood原则的导引。这些谈话都参与的非常好，现场反映也很热烈。这里是我谈话的几份演讲稿：类设计之高级原则在OO设计中

2006-08-10 17:44:00 2683 1

翻译 Java枚举，酷！（原文发表于2006-04-25 下午01:13:48）

当我头一次看到Java 5中的新登场的枚举类型（译注：enum）时，我还是持怀疑态度的。这些枚举类型允许你定义成员和方法（译注：variables and methods），甚至是抽象方法！你能用它来做什么呢？嗯，我现在已经找到了这个问题的答案。（至少是部分的）在评阅和改进外面的一些源码的过程中，我有机会找到了一组用来代表月份的私有静态常量（译注：static final constants）

2006-08-10 14:55:00 6874 4

翻译跋涉于代码的泥潭之中（原文发表于2006-06-02 下午04:45:17 ）

我正在写一本叫做净化代码（译注：Clean Code）的书。这本书里满载了各种代码示例；有的较短，有的较长。在我看来，如果你想教人如何写出好代码，你就必须给他看很多代码示例。一个我的评论者抱怨说，他觉得不是一定要“跋涉于代码的泥潭之中”。这种说法让我感到吃惊，这种话以前我也听过很多次，不知道源自何处；不过这倒是很容易解释通，如果我们“跋涉”于代码的泥潭之中，那么代码一定如同泥沼、湿地、或是

2006-08-09 11:31:00 3372 4

翻译绿色护腕（原文发表于2006-06-10 下午01:14:07 ）

我已经收到了很多的请求，是关于测试优先（译者注：TEST FIRST，一种敏捷开发所倡导的优秀方法）绿色护腕（译者注：Green wrist-band，一种优秀敏捷人的荣誉）的。如果你也想要一个的话就发信过来，要贴邮票，写上你自己地址：Green Wrist BandObject Mentor Inc.1800 Nations DriveSuite 215Gurnee, IL,

2006-08-08 17:40:00 2092 1

翻译当心：工具的美貌（原文发表于2006-06-29 下午12:12:33 ）

我这周在芬兰的弗罗茨瓦夫（译者注：Wroclaw）为一位客户作咨询。（那是过去叫布雷斯劳（译者注：Breslau）的德国城镇，而现在发VRAHT-swahf的音。）这周末我拜访了这里的考古博物馆，就在城镇的广场旁。当我观看这博物馆的时候，我被那些创造箭、钩、斧子、罐、篮子和所有其他日常生活中的物品的远古人类的细心所震撼了。这些物品肯定曾花去几小时、几天、或是几周去创建；而且那个时代的人民也认为所花

2006-08-02 15:17:00 2418 2

翻译敏捷人还没接受它么？！（原文发表于2006-07-31 上午07:27:59 ）

本文是对Cedric发贴的回复一些赞成Cedric提出了一些不错的观点，尤其是指出了如果敏捷开发的“传道士们”只使用教条的论点，而不去接触那些遇到实际的问题的真实的开发者，那么他们就没法再将敏捷进行到底。早期的接受者已经采纳了；而下一代是比较摇摆不定的，想影响他们我们就必须用更强的与现实开发紧密相连的论点。然而，我非常不赞成Cedric所提的关于“风险的考量”的观点。从我的观

2006-08-01 15:03:00 5620 6

Robert C. Martin博客中文版