书评一:

By Greg Smith on August 1, 2016

八年前,我发表了一份关于“敏捷项目管理”的报告之后,大卫•伯恩斯坦(作者)就找到了我。他说很喜欢我的演讲还可以帮助我在代码层面更了解Agile。从那时起,大卫帮助我更好地理解Agile的技术层面——特别是代码质量、可扩展性和降低代码流风险的实践。他的技术辅导帮助我服务了很多客户,其中几次他在Agile转换的过程中甚至亲身参与进来,伟开发团队做了大量的TDD研讨会和实验,使用了开发团队自己的代码做培训。

阅读《修改软件的艺术》就像作者给我的无数的辅导课程。对于那些有深厚技术技能的人,甚至是那些技术技能较少的项目经理,书中都能给他们提供简单实用的编码建议。David对Agile价值有深刻的理解,并以任何团队成员都能理解的方式对细节进行阐述。

总而言之,我给听我讲课的每个公司及团队推荐了这本出色的书。不关注代码,你也能从Agile里学到一些东西,但是如果你想要变得“优秀”,则需要遵从David的建议去延伸你的软件的生命以及价值。

书评二:

有趣&富有洞察力

By Student on November 6, 2016

阅读这本书的过程中,你会逐渐意识到作者是一个坚定的Agile倡导者(不是什么坏事)。作为开发团队中的一员,这本书里有很多非常有价值的东西,尤其是作者多年来与众多行业精英打交道的工作经验。

作者强调了对代码的质量和可维护性的需求。我们很多人都是最大的受害者。特别是那些自以为占了便宜的老板或者经理,他们向开发团队施压以求缩短时间周期。等将来他们就知道这是自讨苦吃了。作为聪明的开发人员,我们必须有自己的标准,而不是(总是)屈服于这些压力。我们的老板或经理的确能找到一个愿意更快地完成工作的人,他们会在短时间内对我们有意见,但最终我们会因为我们健壮、易于理解、易于维护的代码占上风。当然,我们必须用上佳的判断力来决定项目的质量需要多大的投资。

我意识到Agile在团队凝聚力、管理期望、良好的沟通、快速开发以及可维护的质量代码方面的巨大好处。正如这本书中所讨论的,许多团队都说他们做Agile,而他们没掌握Agile的真正要点,唯一的相似之处就在于他们站着开例会:)。Agile已经成为所有软件团队和公司描述自己的热门词汇,因为他们知道这是一种很好的营销方式,但是90%的公司都不是在做Agile。即使对于那些真正投入到Agile开发的团队来说,还是不得要领,Agile运动的一些创始人说,现在Agile实践与他们想要创造的Agile相去甚远,Agile的好处在现实中无法得到。

书评三:

针对各种规模的团队,集中的、可付诸行动的、合理的建议

By Amazon Customer on January 26, 2016

这本书在每个认真的Agile从业者的书架上都应有一席之地。

理解标题中的“遗留代码”很重要。当你完成一段代码并且继续下一个工作的时候,遗留代码就产生了——从这个点之后全都是维护。正如作者指出,代码维护的成本远远超过创建。作者提出的九种实践旨在提高代码的质量然后相应地减少后续维护的费用。

但是,除了书中列出了许多最佳软件开发实践之外,给5颗星的原因是解释和证实这些实践的方式。作者的谈话风格和他所提出的建议,让程序员和管理者都很容易地消化。作为身兼这两职的人,我觉得这本书既给了大局观又可作为参考材料。

书评四:

给程序设计者和他们的老板的重要的书

By Mike V on November 29, 2016

这本书本质上是给那些希望知道怎么让软件受控制的人。作者建议的9种做法对于所有想要编写高质量软件的团队来说都是至关重要的。而且不只是程序员,这些建议对产品所有者、业务分析师——真的是整个团队都是有益的。这难道不是重点吗?团队合作。

同样,这本书从经理到分析师到开发人员都是可以阅读的。它的写作既有技术上的,也有非技术性的,作者实现了他的目标。

连同Bob大叔,Martin Fowler和Michael Feathers等人的著作一起,都在我的“必读书单”之中。