解析极限编程:拥抱变化(原书第2版) [平装]

商家名称	信用等级	购买信息	订购本书
		解析极限编程:拥抱变化(原书第2版) [平装]
		解析极限编程:拥抱变化(原书第2版) [平装]

编辑推荐

《解析极限编程:拥抱变化(原书第2版)》：责任感,透明度，负责任。这些词没有一个是经常应用于软件开发的。在这本完全修订的极限编程（XP）的介绍中。Kent Beck描述了怎样通过把这些非常必要的观念整合进日常开发过程中，以改进你的软件开发。
《解析极限编程:拥抱变化(原书第2版)》第1版是经典之作。其中提出了一些想法，诸如让开发者为自己的代码写自动化测试,让整个团队每周做计划，因为这些当时很激进的改进小团队开发的想法,《解析极限编程:拥抱变化(原书第2版)》获了奖。五年来许多东西改变了。完全重写的第2版将XP的范围扩展到任何规模的团队。建议了基于以下几点的持续改进流程：
?与卓越软件开发一致的5个核心价值观。
?11个原则将这些价值观付诸行动。
?13个基本实践和1 1个扩展实践帮助你推动开发，超越当前的商业和技术限制。
无论你是有一个已经和客户紧密联系在一起的小团队。还是有一个在大组织或跨国组织中的大团队,你都会在书中发现大量思想去挑战、启发和鼓励你及你的团队成员去切实改进你们的软件开发。你将会发现如何：
?影响整个团队——XP风格
?通过结对编程和持续集成来增加技术协作
?通过开发人员的测试减少缺陷
?通过每周和每季度计划校准商业和技术决策
?通过建立富有信息的共享工作空间来改进团队协作你还会发现很多具体的改进方法，它们都基于强调同步增强软件开发的人性和效率的哲学。每个团队都可以改进。每个团队都可以现在开始改进。改进是可能的——超越我们现在可以想象到的程度。《解析极限编程:拥抱变化(原书第2版)》为推进你未来几年的改进提供了具体的方法。

媒体推荐

“来自经验的新见识和智慧，更清楚地解析极限编程艺术，本书将会帮助许多人实现杰出软件开发之梦。”
　　——Joshua Kerievsky，IndustriaL Logic公司创始人
“XP改变了我们业界思考软件开发的方式。鲜明简单，聚集于执行，坚持基于事实的计划胜过猜测，这些为软件交付设定了新的标准。”
　　——David Trowbridge，微软公司架构师

作者简介

作者：(美国)贝克 (Kent beck) (美国)安德瑞斯 (Cynthia Andres) 译者：雷剑文 李应樵 陈振冲

贝克（Kent Beck），一向挑战软件工程教条。促进诸如模式、测试驱动开发和极限编程等思想。他加入了Three Rivers Institute和Agitar Software,在Addison-Wesley出版社出版过多本著作。Cynthia Andres拥有心理学学士学位，从事组织行为学、决策分析和妇女研究方面的工作。从XP诞生以来她就跟Beck一起专注于XP的社会方面的研究。她也加盟了Three Rivers Institute。
译者简介雷剑文(Kim Man Lui)：在Kent Beck的支持下出版了《Software Devel-opment Rhythms》一书。最近得到中国经济出版社支持，雷博士用心理和科学大胆地向股票技术分析的真伪挑战。新书《假中寻真》说破原来想赢钱，必先学会不输钱，这才是务实的炒股态度。
李应樵：Marvel Digital公司的CEO，李博士的兴趣为科研的工业应用。李博士个人研究方向为Ontology Engineering，知识管理和科技管理及其应用。
陈振冲：现任香港理工大学教授，其研究方向和项目包括软件工程，数据挖掘和计算机智能等。

目录

本书赞誉
推荐序
译者简介
前言
致谢
第1章极限编程定义
第一部分探索极限编程

第2章 学习开车

第3章 价值观、原则和实践

第4章 价值观
沟通
简单
反馈
勇气
尊重
其他

第5章 原则
人性化
经济学
互惠互利
自相似性
改进
多样性
反省
流
机遇
冗余
失败
质量
婴儿步
接受责任

第6章 实践

第7章 基本实践
坐在一起
完整团队
信息工作空间
充满活力地工作
结对编程
结对与个人空间
故事
周循环
季度循环
松弛
10分钟构建
持续集成
测试优先编程
增量设计
那么现在
……
第8章 启程
第9章 扩展实践
第10章 完整团队
第二部分 XP哲学
第17章 XP诞生的故事
第18章 泰勒主义和软件
第19章 丰田生产制度
第20章 应用XP
第21章 纯度
第22章 离岸开发
第23章 永恒的编程之道
第24章 XP和社区
第25章 结语
参考文献

文摘

版权页：



插图：


架构师
xP团队中的架构师要查找并进行大规模的重构、编写系统级的架构压力测试，并实现故事。在项目的整个周期，架构师逐步地应用他们的专业知识到项目中。他们指导着项目架构的进化。小系统的架构应该与大系统的架构不一样。对于小系统，架构师要确保系统有适当小的架构。随着系统的增长，架构师要确保架构的跟进。
将大的架构变化分解成小而安全的步骤，是XP团队的挑战之一。权力与责任一致的原则表明，给一个人权力做决定而不必亲自承担后果，其他人还不得不服从他的决定，这样是不好的。架构师们像其他程序员一样签约参加编程任务，但他们同时要注意会带来巨大利益的大的改动机会。
测试能传达架构的意图。我曾同一个信用卡处理机的架构师交谈，他说在这样一个高性能要求的环境中，你不希望出现任何可能有障碍的架构。为了达到这个目的，他的团队有完善的压力测试环境。当他们想要改进架构时，他们会先改进压力测试直至系统崩溃。然后他们会改进架构直至刚好符合测试。
我向另外一个公司的架构师建议了这种策略。他抱怨道，他所有的时间都花费在编写规格说明及向开发者们解释这些说明上，他对没有时间去编码感到非常沮丧。我建议他写一个测试基础设施(testing in-frastructure)，然后用测试来代替规格说明及其解释。如果他发现了一个设计漏洞，就应该编写一个用于指出那个漏洞的测试。虽然我没能说服他尝试这个主意，但是我仍认为它是有价值的。

喜欢解析极限编程:拥抱变化(原书第2版) [平装]请与您的朋友分享,由于版权原因，读书人网不提供图书下载服务

查看更多 下一篇