书评-Jolt大奖精选丛书

| Comments

Jolt大奖精选丛书

2012-08-18@oschina.net 书评链接

这次书评活动有6本书,写书评的确花了不少时间呀!

###《编写有效用例》书评### 刚毕业的时候,在公司就看到这本书,当时看了一下,不过不怎么懂。 只是隐约知道有用例这么个概念,后来慢慢地接触到业务用例,测试用例等内容,才逐渐对用例有了一些理解。 再后来,因工作需要,经常使用UML来画用例图,小人的身影更是随处可见了。直到现在,虽然用例接触有不短的时间了, 不过用例这东西还真的没有非常系统的学习过。

没想到过了那么多年,又重新看到这本书,倍感亲切,让我有了系统学习一下的热情。 这本书和其他软件工程书籍不大一样,因为它专注于用例的编写。里边提供了很多写用例的原则,读完可以对用例概念有深入的认识。 另外,和很多书籍不一样的是,书中使用的例子都是作者实际项目中抽取出来的,而且例子数量非常的多,我非常喜欢真实饱满的例子 ,因为这样才有现实指导意义。以前看过有些书,例子是简单的傻瓜化,遇到真实的场景显得苍白无力。 这本书,实战味道比较浓烈,学到一点用一点。即使是用例方面的新手,也很容易用得上。

另外,我注意到一点,书中强调了项目相关人员和利益模型,梳理系统用例与业务用例的边界,这些都是以前我不曾注意或不甚理解的地方。 我非常同意一书中的一个观点:我们需要的是有用的用例,而不必是一个最好的用例。

的确,实践总是我们的目的,学习的过程不要忘记练习一下。 对于我来说,有了这本书,以前的实践经验更容易得到修正,以后写用例一定会更加得心应手。

###《代码阅读》书评### 据我所知,《代码阅读》这本书是这个领域唯一的著作。 这本书我曾经读过两遍,我把书中的一些实践方式用于平时工作中,感觉收获很大。

首先,作者提供的例子都是现实存在的代码,并不是玩具程序。这样才让书中的例子更具说服力,作者提供的操作手法也更有借鉴意义。 例如我现在手头上的项目,不包括页面光java的代码就超过100w,还有数百万的c++代码,这些代码经历了很多人的摧残。 到现在,作为一个开发人员,每天都要面对着这么多代码,在这些代码上打转,努力去修复问题,添加新特性, 还需要每日和每周做code review,保证代码质量。阅读代码的能力显得格外重要, 因此我特别喜欢第6章和第9章关于大项目和架构方面的内容,让我有信心对付这些大块头项目。

另外,源代码开放活动已经成为软件业不可或缺的力量,而且现在成熟稳定的开源项目日益真多,每个人或多或少都会有所涉及。 一方面工作上的项目经常使用了这些开源代码,有时候出现问题需要定位,另一方面,通过开源代码,可以学习新的架构, 编程思想,优秀开发的技巧和经验,从而提高自己的能力。无论是什么样的情况,阅读开源代码是很有必要的。 而这本书,提供了阅读代码的最佳实践,能够帮助我们更快的理解这些代码。

当然,这本书不单单教导如何去阅读代码。我认为,书中关于编码规范,命名方式,文档方面的内容,从代码阅读的角度, 提出了自己的看法,所以当你进行编码规范规范制定等工作的时候,有一定的指导意义。如果你想立马学习代码阅读的技巧, 作为过来人,我觉得开头先研习一下书中第10章关于代码阅读工具的内容是个不错的开始,有工具的支持,边学习边操作, 理解书中的代码阅读技巧也会跟容易一些,乐趣也就多一些了。

###《持续集成:软件质量改进和风险降低之道》书评 ### 真正接触持续集成是2年前来到新公司的时候,那个时候公司请了ThoughtWork公司的咨询顾问来。 顾问给我们灌输了持续集成的概念,并使用CruiseControl帮助我们搭建了持续集成环境。 随着时间的推移,我们这里多个项目组都加入了持续集成的环境,并搬来了大电视让整个过程可视化, 并加了一些警示的声音,效果很是震撼呀。持续集成是个有趣的东西, 还制定了相应的军规:红灯停,绿灯行,黄灯停一停。(和电视上显示的项目状态的颜色有关)

正如书上说描述的,持续集成减少重复的过程,把编译,集成测试,部署等环节自动化, 的确节省了我们的时间,并避免了人工干预的风险。另外,我们在持续集成里边加入单元测试, findbugs,checkstyle, cppunit等测试项,这样代码质量问题可以得到更快更好的反馈,经常因为有些问题代码被快速检测出来而感到庆幸。

样章只有持续测试这一章节的描述,项目的可靠性必须得通过持续不断的测试来保证。 正因为如此,我们在持续集成里边加入单元测试等功能之外,还使用自动化测试用例进行测试, 当然因为测试用例巨大,耗时较长,我们通常是选择在晚上进行的。

按照我们的理解,对项目有利的东西,只要能够自动化,都可以考虑加入持续集成,这将给项目带来更多的好处。

###《代码质量》书评### 工作了这么多年,也接触过各式各样的系统,看过千奇百怪的代码,知道代码质量的重要性对我们是多么的重要。 每每想起那些可怕的错综复杂的代码,还有那些线上千奇百怪的问题,总会深深感到不安,实在太让人揪心了。 所以在日常工作中,我非常强调代码质量,用各种培训去提升开发人员的技能水平,用代码评审等手段试图保证代码质量。

现今随着硬件成本的降低,人力成本的提升,我平时考察考察代码质量多从可读性,可维护性,性能的角度出发, 正因为如此,Diomidis Spinellis这本书的目录让我眼前一亮,它从多个维度考察代码质量, 讨论了如何满足非功能性需求,我从未用如此全面的角度衡量代码的质量,的确充实了我的知识库, 让我在平时工作中用更全面的眼光衡量代码的质量。

另外,和代码阅读一样,书中的丰富的例子来源于现实代码,让作者的观点更具说服力。 最近团队来了不少新员工,在代码质量控制方面花了不少功夫。有时候,他们并不理解代码质量的重要性,认为代码能运行就可以了。 让新员工理解这些非功能性需求的重要性,能够在平时中注意考虑非功能性需求的,这都是非常重要而且非常迫切的需求。 我想,借助于这本书理论与实践的结合, 继续这项工作更有信心了。

###《面向对象分析与设计》书评### 这是一本关于面向对象分析与设计的书籍,通常和对象打交道的书,几乎都是在写设计模式一样, 当我看到这本书的时候,第一反应就是这样。因为我使用面向对象语言进行开发设计已经有一段时间了, 除了设计模式方面的书籍,真的很少碰到面向对象方面让人耳目一新的著作。但在浏览了书本的目录和前言部分之后, 我对这本书有另外一个感觉: 这是学习掌握UML的一本绝佳的书籍。正是这一点吸引我继续阅读下去。

本身作者Grady Booch就是UML的创始人之一,书中也有大量关于UML图的内容,由他使用UML来讲述再好不过了。 另外,UML里边类图,状态图等,本质上也离不开面向对象理论的支持。理论与实践相结合,这是很多书籍做不到的地方, 也是我感觉使用面向对象进行分析设计经常遇到困难的痛处。所以,即使我使用面向对象进行设计开发, 也用过UML画过各式各样的图,但书中的内容仍然吸引着我。

这本书提供的样章相当的多,阅读花了不少时间。书中介绍了面向对象的各种概念, 并运用了大量的例子展示了面向对象设计的经验技巧,这些都是很难描述清楚的东西, 而且容易变得很枯燥的东西,庆幸的是,作者在这方面的文笔相当好,阅读起来非常顺畅。

###《灾难拯救:让软件项目重回轨道 》书评### 终于看完这本书的样章了!我不是一个项目管理人员,但我觉得了解一些项目方面的东西是有好处的。 我面对的也是一个不是很顺利的项目,有着比较纠结的代码基,人员众多而且人员流动也比较大,线上问题也时不时的出现。 虽然采用了一些敏捷开发的手段控制进度,但也不是特别的顺利。要命的是,这是一个需要长期维护发展的关键项目,不能随意推到重来。

我认为这本书对于我们这种类型项目来说,还是有相当的指导意义的 。 如前言说的,这是一本救治之书,它探讨了像我们这种随时面临失败的项目,如何去拯救,如何重回正轨。 书中提到面临失败项目,实施拯救需要的10个步骤。很显然,有些步骤我们已经在现实中采用了, 并且也取得了一些成果:例如确定最低目标,风险分析等内容。但能够完整描述这些步骤, 也真的是不容易做到,有了这本书的指导,我相信实施这些步骤是具有可操作性的。

整本书有一个顺序脉络在那里,就是步骤的描述,所以应该从头到尾的读会比较合适,因为每个步骤是有一些关联的, 如果跳来跳去,可能不能深入理解步骤的真正意义。最后一章是整本书的总结,把前面描述的10个步骤整合在一起, 并对时间安排,实施拯救计划进行指导。对于担心书中描述的理论是否可行的人来说, 这章无疑是打了强心针一样,只要按照书中的建议进行操作,应该是能够验证效果的,需要的只是:行动。

"书评"系列文章:

Comments