新書推薦：
《
带献帝去旅行--历史书写的中古风景（论衡系列）
》
售價：HK$
69.6
《
出行创新设计：概念、范式与案例
》
售價：HK$
119.9
《
爱的能力：为什么我们既渴望爱，又害怕走进爱（第13版）
》
售價：HK$
83.8
《
环艺设计手绘：景观/室内 马克笔 手绘效果图技法精解
》
售價：HK$
95.8
《
明清与李朝时代
》
售價：HK$
81.6
《
感动，如此创造
》
售價：HK$
71.8
《
商业人像摄影
》
售價：HK$
95.8
《
抗争表演
》
售價：HK$
74.4
|
| 編輯推薦： |
《敏捷开发（纪念版）》通过丰富的案例来诠释了敏捷开发和敏捷设计的基础知识，介绍了UML模型如何转为实际可用的C#代码。在总体上概述敏捷运动之后，展示了敏捷实践过程，并通过大量有价值的源代码实例来展示了敏捷设计、开发与实践。
通过本书的阅读，读者可以掌握以下主题：
● 12个敏捷原则和14个极限编程实践
● 技术预研，故事拆分，速率，迭代和版本规划
● 测试驱动开发、测试先行设计以及验收测试
● 单元测试与重构
● 结对编程
● 敏捷设计与设计异味
● 5类UML图及其高效用法
● 面向对象的软件包设计及其设计模式
● 如何综合运用所有要点来实现一个真实的项目
|
| 內容簡介： |
|
《敏捷开发（纪念版）》介绍敏捷原则、模式和实践，包含4部分38章24个附录，首先概述敏捷开发、包含6个主题，分别为敏捷实践、极限编程、规划、测试、重构和编程活动。接下来介绍敏捷设计，解释了5个设计原则、UML及其应用，包括状态图、对象图、用例图、序列图和类图，并以一个完整的咖啡机编程案例来介绍具体的用法。通过薪水支付系统Payroll的实战练习，书中呈现了敏捷开发的整个过程及其实用价值。 《敏捷开发（纪念版）》适合真正想要通过敏捷方法来提升软件开发技能以及及时交付软件价值的所有读者阅读和参考，尤其适合开发、管理和业务分析岗位的人员学习。通过本书的阅读，读者还可以了解UML、设计模式、面向对象设计原则以及包括极限编程在内的敏捷方法。
|
| 關於作者： |
罗伯特·C.马丁
（Robert C. Martin)
业内人士尊称的“鲍勃大叔”（Uncle Bob），是国际知名的软件工程师和导师，一位有五十多年健康编码经验的程序员。cleancoders.com联合创始人和UncleBob咨询公司创始人，主要提供软件咨询、技能培训和视频教学服务。
他在专业技术领域具有较深的造诣。除了担任C Report杂志的总编辑，他还发表了大量有影响力的文章，受邀在许多国际性软件大会上发表演讲。他是SOLID五大原则的奠基人，是《敏捷宣言》联合签署人并担任过敏捷联盟届主席。他擅长的主题有软件匠艺、敏捷软件开发和测试驱动开发等。
马丁是个终生学习者，52年出生的他，还在考飞行驾照。
米咖·马丁
（Micah Martin）
软件工程师、咨询顾问、培训师，擅长的领域有面向对象设计原则与模式、敏捷软件开发实践。他是开源项目FitNesse项目的创始人和开发总监。他著述颇丰，同时也是很多软件大会的演讲嘉宾。
|
| 目錄：
|
详细目录
第Ⅰ部分 敏捷开发
第1章 敏捷实践 002
敏捷联盟 003
个人和互动优先于过程和工具 004
可以工作的软件优先于详尽的文档 004
客户合作优先于合同谈判 005
应对变化优先于遵循计划 006
原则 007
小结 009
参考文献 010
第2章 极限编程概述 011
极限编程实践 011
完整的团队 011
用户故事 012
短的周期 012
验收测试 013
结对编程 014
测试驱动开发 015
集体所有权 015
持续集成 016
可持续的开发速度 016
开放的工作空间 017
规划游戏 017
简单设计 018
重构 019
隐喻 019
小结 020
参考文献 021
第3章 计划 022
初探 023
技术预研、故事拆分和速率 023
发布计划 024
迭代计划 024
定义“完成” 025
任务计划 025
迭代 027
跟踪 027
小结 028
参考文献 029
第4章 测试 030
测试驱动开发 030
验收测试 035
意外获得的架构 037
小结 037
参考文献 038
第5章 重构 039
素数产生程序：一个简单的重构示例 040
重构 043
后检查 049
小结 053
参考文献 054
第6章 一次编程实践 055
保龄球比赛 056
小结 106
保龄球规则概述 107
第Ⅱ部分 敏捷设计
臭味和原则 110
参考文献 110
第7章 什么是敏捷设计 111
设计臭味 112
设计的臭味：软件腐化的气味 112
僵化 113
脆弱 113
顽固 113
粘滞 114
不必要的复杂 114
不必要的重复 114
晦涩 115
为什么软件会腐化 115
Copy程序 116
一个熟悉的场景 116
Copy程序的敏捷设计 120
小结 122
参考文献 123
第8章 单一职责原则（SRP） 124
定义职责 126
分离耦合的职责 127
持久化 128
小结 128
参考文献 129
第9章 开/关原则（OCP） 130
描述 131
Shape应用程序 133
违反OCP 133
遵循OCP 136
预测变化和“贴切的”结构 138
放置“钩子” 139
使用抽象获得显式封闭性 140
使用“数据驱动”的方法获取
封闭性 141
小结 142
参考文献 143
第10章 里氏替换原则（LSP） 144
违反LSP的情形 145
更微妙的违反情形 147
一个实际的例子 154
用提取公共部分的方法代替继承 158
启发式规则和习惯用法 162
小结 162
参考文献 163
第11章 依赖倒置原则（DIP） 164
层次化 165
倒置的接口所有权 166
依赖于抽象 167
一个简单的DIP例子 168
找出底层抽象 169
熔炉示例 171
小结 172
参考文献 173
第12章 接口隔离原则（ISP） 174
接口污染 174
分离客户端就是分离接口 176
类接口和对象接口 177
通过委托来分离接口 178
使用多重继承隔离接口 179
ATM 用户界面的例子 180
小结 187
参考文献 187
第13章 C#程序员UML概述（C#语言） 188
类图 191
对象图 193
顺序图 193
协作图 194
状态图 195
小结 196
参考文献 196
第14章 使用UML 197
为什么建模 197
为什么要建软件模型 198
写代码之前是否应该做好详细设计 198
有效使用UML 199
与他人交流 199
脉络图 201
项目结束文档 202
要保留的和要丢弃的 203
迭代式改进 204
行为优先 204
检查结构 206
想象代码 208
图示的演化 209
何时以及如何绘制图示 210
何时要画图，何时不要画图 210
CASE工具 211
那么，文档呢 212
小结 212
第15章 状态图 214
基础知识 214
特定事件 216
超状态 217
初始伪状态和结束伪状态 218
使用FSM图示 219
小结 220
第16章 对象图 221
即时快照 221
主动对象 223
小结 227
第17章 用例 228
写用例 229
备选流程 230
其他东西呢 230
用例图 231
小结 232
参考文献 232
第18章 顺序图 233
基础知识 234
对象、生命线、消息及其他 234
创建和析构 235
简单循环 236
时机和场合 237
高级概念 240
循环和条件 240
耗费时间的消息 241
异步消息 243
多线程 248
主动对象 249
向接口发送消息 250
小结 251
第19章 类图 252
基础知识 253
类 253
关联 253
继承 254
类图示例 255
细节 258
类的衍型 258
抽象类 259
属性 260
聚合 260
组合 261
多重性 263
关联衍型 263
嵌套类 264
关联类 265
关联修饰符 266
小结 266
参考文献 266
第20章 咖啡的启示 267
Mark IV型专用咖啡机 267
规格说明书 268
常见的丑陋方案 271
虚构的抽象 273
改进方案 275
实现抽象模型 279
这个设计的好处 295
面向对象过度设计 303
参考文献 304
第21章 命令模式和主动对象模式 310
简单的命令模式 311
事务操作 313
实体上的解耦和时间上的解耦 314
时间上的解耦 315
UNDO()方法 315
主动对象模式 316
小结 322
参考文献 322
第22章 模板方法模式和策略模式：继承和委托 323
模板方法模式 324
模式滥用 327
冒泡排序 328
策略模式 332
小结 338
参考文献 338
第23章 外观模式和中介者模式 339
外观模式 339
中介者模式 340
小结 343
参考文献 343
第24章 单例模式和单状态模式 344
单例模式 345
好处 347
代价 347
单例模式实战 348
单状态模式 350
好处 351
代价 352
单状态模式实战 352
小结 358
参考文献 359
第25章 空对象模式 360
描述 360
小结 363
参考文献 364
第26章 案例学习：Payroll系统的轮迭代 365
规格说明书 366
基于用例进行分析 367
添加新员工 368
删除员工 369
提交考勤卡 370
提交销售凭证 370
提交工会服务费 371
更改员工信息 372
薪水支付日 374
反思：我们从中学到了什么 376
薪水支付类别抽象 376
支付薪水时间表抽象 377
第Ⅲ部分 案例学习：薪水支付系统Payroll
支付方式 378
工会所属关系 378
小结 379
参考文献 380
第27章 案例学习：Payroll系统
实现 381
事务 381
添加员工 382
Payoll系统的数据库 384
删除雇员 388
考勤卡、销售凭证和服务费用 390
更改员工信息 399
更改员工类别 403
我犯了什么晕？ 409
支付员工薪水 413
我们是否希望开发人员来做商业决策？ 415
按月薪结算的员工支付薪水 415
支付小时工的薪水 418
主程序 431
数据库 432
小结 433
关于本章 433
参考文献 434
第Ⅳ部分 案例学习：打包Payroll系统
第28章 包和组件的设计原则 436
包和组件 436
组件的内聚性原则：粒度 437
重用-发布等价原则（REP） 438
共同重用原则（CRP） 439
共同封闭原则（CCP） 440
组件内聚性小结 441
组件耦合原则：稳定性 441
无环依赖原则（ADP） 441
稳定依赖原则（SDP） 447
稳定抽象原则（SAP） 452
小结 456
第29章 工厂模式 457
依赖问题 460
静态类型与动态类型 461
可替换的工厂 462
对测试支架使用对象工厂 463
工厂模式的重要性 465
小结 465
参考文献 465
第30章 案例学习：Payroll系统的包分析 466
组件结构和符号 467
应用共同封闭原则（CCP） 469
应用发布等价原则（REP） 471
耦合和封装 474
度量指标 475
在薪水支付系统中使用这些度量 477
对象工厂 479
重新思考内聚的边界 483
终的包结构 483
小结 485
参考文献 485
第31章 组合模式 487
组合命令 489
多重性还是非多重性 490
小结 490
第32章 观察者模式 491
数字时钟 492
观察者模式 512
模型 513
观察者模式与面向对象设计原则 514
小结 514
参考文献 515
第33章 抽象服务器、适配器和桥接模式 516
抽象服务器模式 517
适配器模式 518
类形式的适配器 519
调制解调器问题、适配器和里氏替换原则 520
桥接模式 524
小结 527
参考文献 527
第34章 代理模式和TDG模式：管理第三方API 528
代理模式 529
代理购物车应用 534
小结 550
处理数据库、中间件以及其他第三方
接口 550
TDG模式 553
测试和内存TDG 561
测试DbGateway 562
小结 568
参考文献 568
第35章 访问者模式 569
访问者模式 570
非循环访问者模式 575
使用访问者模式 581
访问者模式的其他用途 589
装饰者模式 589
扩展对象模式 596
小结 610
参考文献 610
第36章 状态模式 611
嵌套语句switch/case 612
内部作用域内有效的状态变量 615
测试动作 616
代价和好处 616
迁移表 617
使用表解释 618
代价和收益 619
状态模式 620
状态模式和策略模式 624
使用状态模式的代价和好处 624
SMC（状态机编译器） 625
SMC生成的Turnstile.cs以及其他
支持文件 628
代价和收益 634
状态机的应用场合 634
作为 GUI 中的高层应用策略 634
GUI 交互控制器 636
分布式处理 637
小结 638
参考文献 639
第37章 案例学习：Payroll系统的数据库 640
建立数据库 641
代码设计中的一个缺陷 642
增加雇员 644
事务 658
加载Employee对象 665
还有什么工作？ 680
第38章 案例学习：Payroll系统的用户界面 681
界面 683
实现 684
构建窗口 696
Payroll的窗口 705
真面目 720
小结 720
参考 721
Rupert：Alpha项目 722
附录A 两家公司的讽刺故事 722
附录B 源码即设计 739
|
| 內容試閱：
|
“可是老兄，你说你去年就会完成这本书的。”距离1999年Claudia发出这一正当的抱怨，已经过去7年了，但我（Bob）（前言为两名作者共同写成，因而在“我”的后面指出了具体的作者名称，以示区分）觉得已经做出了补偿。我要经营一家咨询公司，做大量编码、培训、辅导和演讲工作，写文章、专栏和博客，更不用提还要养家糊口并享受大家庭的乐趣。所以，这期间写三本书（每两年一本）真的是一个巨大的挑战。但是，我乐在其中。
敏捷开发是在需求快速变化的情况下快速开发软件的一种能力。为实现这种敏捷性，需使用能提供必要纪律和反馈的实践，需遵守保持软件灵活且易于维护的设计原则，需知道已证明能为特定问题权衡那些原则的设计模式。本书旨在将这三个概念整合成一个有机的整体。
本书介绍了这些原则、模式与实践，然后通过多个案例来演示其实际运用。更重要的是，这些案例都不是“成品”。相反，它们是进行中的设计。你会看到设计人员犯错，观察到他们如何发现并终纠正错误，会看到设计人员对一个难题苦思不得其解，并担心歧义和得失。总之，你看到的是设计实际在进行。
2005年初，我（Micah）在一个小开发团队做事，当时要着手用C#来写一个.NET应用程序。项目要求采用敏捷开发实践，这正是我进入该项目的原因之一。虽然以前用过C#，但我熟悉的还是Java和C 。
当时没想过用.NET会有多大区别，事实证明确实如此。项目进行了两个月，我们发布了个版本。不是完整版本，只包含所有预期功能的一部分，但足够用。他们也真的在用。仅过了两个月，公司就从我们的开发收获了好处。管理层高兴，嚷着要雇更多人，启动更多项目。
多年来一直出没于敏捷社区，我知道有许多敏捷开发人员能帮到我们。我给他们打了电话，请他们加入。终，没有任何一个搞敏捷的人加入我们的团队。为什么？或许重要的原因是我们用的是.NET。
几乎所有敏捷开发人员都有Java，C 或Smalltalk的背景。但几乎没听说过有敏捷.NET程序员。我说要用.NET进行敏捷软件开发，我的那些朋友可能根本没有把我的话当真，或者他们就是不想和.NET扯上关系。这是一个大问题。而且，发生过好多次。
为期一周的有关各种软件主题的课程使我能结识来自世界各地的开发人员。
就各种软件主题讲授大约一周的课程，使我有机会接触来自世界各地有代表性的开发人员。许多学员都是.NET程序员，也有许多是Java或C 程序员。虽然不好听，但根据我的经验，.NET程序员通常比Java和C 程序员要弱一些。显然，并非总是如此。但通过在课堂上反复观察，我只能得出这样的结论：.NET程序员在敏捷软件实践、设计模式和设计原则等方面通常要弱一些。据我观察，许多.NET程序员从未听说过这些基本概念。这种情况必须改变！
我父亲Robert C. Martin于2002年出版了的《敏捷软件开发：原则、模式与实现》荣获了2003年Jolt大奖。那是本好书，受到许多开发人员的推崇。遗憾的是，它对.NET社区影响甚微。虽然书的内容同样适合.NET，但鲜有.NET程序员读过。
我希望讲.NET的这一版能在.NET和开发社区其余部分之间建立起一座桥梁。希望程序员能读一读，了解构建软件的更优方式。希望他们开始使用更好的软件实践，创建更好的设计，提升.NET应用程序员的质量标准。希望.NET程序员不再比其他程序员弱。希望.NET程序员在软件社区取得更多话语权，就连Java开发人员也乐意加入一个.NET团队。
写书的过程中，我经常纠结于要不要把我的名字放在一本.NET书的封面。这样会不会将我和.NET联系起来，会不会有不好的暗示？但终我不再纠结。我是一名.NET程序员。不对！一名敏捷.NET程序员！我为此感到骄傲。
关于本书
20世纪90年代初，我(Bob)写了Designing Object-Oriented C Applications Using the Booch Method一书，是我的代表作，我对其影响和销量都很满意。其实你现在正在看的开始就是想作为那本书的第3版，只是后来完全不是那么回事。原作内容在本书所剩无己，不超过3章，而且都进行了大幅修订。书的意图、精神和许多启发并没有改变。在该书问世后的十年里，我在软件设计和开发方面学到了很多。本书反映了我学到的东西。
这是怎样的十年啊！该书是在互联网时代之前出版的。互联网问世后，需要掌握的缩写词数量大增。我们现在有了EJB、RMI、J2EE、XML、XSLT、HTML、ASP、JSP、ZOPE、SOAP、C#和.NET，另外还有设计模式、Java、Servelets和Application Servers。基本上，要使本书所有章节的内容保持“”是很难的。
本书和Booch的关系
1997年，Grady Booch（Grady Booch是统一建模语言(UML)的缔造者之一）邀请我帮忙写他那本大获成功的Object-Oriented Analysis and Design with Applications一书的第3版。我以前和Grady在一些项目上合作过，是其许多作品（包括UML）的热心读者和内容贡献者。所以，我高兴地接受了邀请，并请我的好友Jim Newkirk共同参与。
接下来的两年，我和Jim为Booch写了许多章节，花在本书上的精力自然就少了。但是，我觉得Booch的书值得投入。另外，当时还在想本书反正只是第2版，所以并不是特别上心。如果我要写一些有份量的内容，我会写一些新的、不一样的。
遗憾的是，Booch的书难产了。本来就很难在正常时间写书，在互联网泡沫的那段时间更是不太可能。Grady在Rational Software的工作更忙了，同时还忙于像Catapulse这样的风投企业。所以，项目陷入停顿。终，我问Grady和Addison-Wesley出版社能不能把我和Jim写的章节放到本书。他们慷慨地同意了。本书的几个案例分析和UML章节就是这么来的。
极限编程的影响
1998年末，极限编程(XP)崭露头角，挑战我们对于软件开发的传统观念。是应该在写任何代码之前创建大量UML图，还是避免一切形式的图，直接写大量代码？是应该写许多说明性的文档来描述设计，还是使代码更具说明性，从而无需辅助文档？要结对写程序吗？写生产代码前要先写好测试代码吗？我们到底应该怎么做？
这个变革来得恰是时候。20世纪90年代中期，Object Mentor帮助许多公司解决OO(面向对象)设计和项目管理问题。我们帮这些公司完成其项目。在这个过程中，我们向团队灌输了自己的态度与实践。遗憾的是，这些东西没有形成书面记录。相反，只是从口头上传达给了客户。
1998年，我意识到需要把我们的过程和实践记录下来，以便更好地向客户传达。所以我在C Report上写了许多关于这一过程的文章（有4篇文章。前三篇是“Iterative and Incremental Development”(I， II， III)。后一篇是“C.O.D.E Culled Object Development process”）。但是，这些文章没有达到目标。信息量大，有时还十分有趣，但它们没有将我们在项目中采用的实践和态度整理成文，面是对数十年来我形成的价值观的一种无意识的折衷。后是Kent Beck提醒了我。
本书和Kent的关系
1998年末，正当我为Object Mentor过程的整理而烦恼时，Kent和Beck在极限编程（XP）方面的成果让我眼前一亮。这些成果散见于Ward Cunningham（沃德·坎宁安，Wiki概念的发明者，设计模式和敏捷软件方法的先驱之一）的wiki（http://c2.com/cgi/wiki包含涉及广泛主题的大量文章。有数百上千的作者。有人说，也就Ward Cunningham才能用几行Perl代码发起一次社会革命），和其他许多人的作品混在一起。尽管如此，作为一个有心人，我还是掌握了Kent的要点。感兴趣的同时，我也有了一些疑虑。极限编程的某些东西契合我的开发过程目标。但另一些东西，比如缺乏一个明确的设计阶段，却让我疑惑。
我和Kent处于截然不同的软件环境。他是公认的Smalltalk顾问，我是公认的C 顾问。这两个世界相互很难沟通，存在像库恩范式（1995年到2001年任何可靠的学术著作采用的都肯定是“库恩”(Kuhnian)一词。它是指托马斯·库恩(Thomas S. Kuhn)所著的《科学革命的结构》一书(芝加哥大学出版社1962年出版)。库恩认为科学不是通过新知识的线性积累进步，而是经历周期性的革命，称“范式转移”。）那么大的鸿沟。
其他时候我绝不会邀请Kent为C Report撰稿。但是，由于我们对于过程的看法取得了一致，所以语言的鸿沟不再重要。1999年2月，我在慕尼黑的OOP大会上见到了Kent。我当时在讲OOD的原则，他就在对面的房间里讲XP。由于没法听到他的演讲，我在午餐时找到了Kent。我们讨论了XP，我提出了让他为C Report撰稿的请求。这是一篇很棒的文章，讨论了Kent如何和一名同事花一小时左右的时间在某个live system中进行一次全面的设计更改。
接着几个月，我慢慢梳理出了自己对XP的忧虑。担心的是如何采纳一个没有明显前期设计阶段的过程。感觉自己好像卡在了这里。对于我的客户及其整个行业，我难道不应该告诉他们值得花时间在设计上吗？
后，我终于意识到自己都没有真正注重过这样的一个阶段。即使在我写的关于设计、Booch图和UML图的所有文章和书里，都总是将代码作为验证图是否有意义的一种方式来使用。在我的所有客户咨询中，我会花一两个小时帮客户画图，再指导他们通过代码来利用这些图。我意识到虽然XP关于设计的说法有点陌生，有点库恩（如果在文章中两次提到库恩的话，论文的可信度更高），但其背后的实践我本来就熟悉。
我对XP的其他担心较容易解决。我私底下一直拥护结对编程。XP使我能光明正大地和伙伴一起编程。重构、持续集成、在客户现场工作……所有这些对我来说都很容易接受。它们很接近我向客户建议的工作方式。
XP的一个实践对我来说是新的发现。次听说“测试驱动开发”（Test-driven development，TDD）（Kent Beck著，中文版《实战测试驱动开发》）时可能感觉没什么：写生产代码前先写好测试用例，写所有生产代码的目的都是使失败的测试用例通过测试。但是，我对这种开发模式所带来的深远影响始料未及。该实践彻底改变了我写软件的方式：变得更好了。
所以，1999年秋，我确信 Object Mentor 应采纳 XP 作为其选择的过程，并且我应该放弃写自己的过程的想法。Kent已经很好地归纳了XP的实践与过程，我的小小尝试与之相比不值一提。
.NET
各大企业正在进行一场战争，目的是争取你的效忠。它们认为，只要拥有了语言，就拥有了程序员以及雇用这些程序员的公司。
这场战争的个争夺点是Java。Java是个由大公司为赢得程序员关注而创建的语言，并取得了极大成功。Java在软件社区深得人心，基本上是现代多层IT应用程序的事实上的标准。
相应的一个还击来自IBM，它通过Eclipse开发环境夺走了很大一块Java市场。Microsoft技术精湛的开发人员也不甘落后，他们提供了常规意义上的.NET和为特殊的C#。
令人惊讶的是，Java和C#很难区分。两种语言语义一致，语法也相似，以至于许多代码段没有差别。虽然Microsoft在技术创新上差点意思，但它赶超别人并取得终胜利的能力还是相当不错的。
本书版采用Java和C 作为编码语言。本书则完全采用C#和.NET平台。不要把这当成是背书。这场战争我们不选边站。事实上，大公司为争夺程序员的关注而发起的战争没有太大意义。未来几年一旦出现更好的语言，程序员的心思立即就会发生转移。
本书之所以出.NET版，自然是为了方便.NET读者。虽然书中的原则、模式与实践和语言无关，但案例分析不是。.NET程序员看.NET的案例分析更舒服，Java程序员看Java的例子更愉快。
魔鬼就在细节里
本书包含大量.NET代码。希望你能仔细读代码，因为代码在很大程度上就是本书的重点。代码具现了本书要表达的意思。
本书采用固定写作模式：大小不一的一系列案例分析。有的非常小，有的则需要用几章来讲解。每个案例分析都有一些前置材料，描述了该案例分析要用到的面向对象设计原则和模式。
本书首先讨论开发实践和过程，其中穿插了许多小的案例分析和例子。然后开始讨论设计和设计原则，接着讨论一些设计模式，对包进行管控的更多设计原则，以及更多模式。所有这些主题都伴随有相应的案例分析。
所以，要做好读一些代码和研究一些UML图的准备。本书技术性很强，它要传授的经验教训如同恶魔一样隐藏在细节里(细节决定成败)。
本书的结构
本书包含4部分38章和2个附录。
第Ⅰ部分：敏捷开发。本部分描述敏捷开发的概念。首先展示敏捷联盟宣言，概述了极限编程(XP)，然后通过许多小的案例分析来阐述一些单独的XP实践，尤其是对设计和代码编码方式有影响的那些。
第Ⅱ部分：敏捷设计。本部分讨论面向对象软件设计，包括它的定义，对复杂性进行管理的问题和技术，以及面向对象类设计的原则。本部分后用几章描述了UML的一个实用子集。
第Ⅲ部分：案例学习：Payroll系统。本部分描述面向对象设计和一个简单的批处理Payroll系统的C 实现。前几章描述本案例分析遇到的设计模式。后一章是完整的案例分析，是本书和完整的一个。
第Ⅳ部分：案例学习：打包Payroll系统。本部分首先描述面向对象包设计的原则，然后通过增量打包上一部分的类来演示这些原则。后几章描述了Payroll应用程序的数据库和UI设计。
附录A：两家公司的讽刺故事
附录B：Jack Reeves的“什么是软件”一文。
如何使用本书
如果你是开发人员，请将本书从头读到尾。本书主要为开发人员而写，包含以敏捷方式开发软件所需的资讯。先学习实践，然后是原则，然后是模式，然后是把所有这些结合起来的案例分析。整合所有这些知识将有助于你完成项目。
如果你是管理人员或业务分析师，请阅读第Ⅰ部分“敏捷开发”。第1章～第6章深入讨论了敏捷原则和实践，从需求到计划，再到测试、重构和编程。本部分将指导你建立团队和管理项目。
如果想学习UML，请先阅读第13章～第19章，然后阅读第Ⅲ部分“案例学习：薪水支付系统Payroll”的全部章节。这将帮助你在UML的语法和使用方面打下良好基础，同时帮助你在UML和C#之间转换。
如果想学习设计模式，请阅读第Ⅱ部分“敏捷设计”，从而先学习设计原则。然后阅读第Ⅲ部分“案例学习：薪水支付系统Payroll”和第Ⅳ部分“案例学习：打包Payroll系统”。它们定义了所有模式，并展示了它们在典型情况下的使用。
如果想学习面向对象设计原则，请阅读第Ⅱ部分“敏捷设计”和第Ⅲ部分“案例学习：薪水支付系统Payroll”和第Ⅳ部分“案例学习：打包Payroll系统”。它们描述了面向对象设计原则并展示了如何使用它们。
如果想学习敏捷开发方法，请阅读第Ⅰ部分“敏捷开发”。本部分描述了敏捷开发的需求、计划、测试、重构和编程。
如果想找乐子，请阅读附录A“两家公司的讽刺故事”。
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
