Robert C. Martin博客中文版

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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