☆☆☆☆☆
简体网页||繁体网页



点击这里下载

类似图书 点击查看全场最低价

　　小记者︰能说说你对《无瑕的程式码──敏捷完整版》的读后心得吗？
　　工程师︰自从读了这本《敏捷完整版》之后，我再也不怕面对那些惯老板、惯客户了。而且客户满意度、专案完成度都一百分呢！

　　这本书是《无瑕的程式码》系列书的第三册，也是《名家名着》系列书的第三册。主题是「敏捷开发」，而重点仍旧是回归到「如何撰写出好的程式码」。

　　什么是「敏捷开发（Agile Development）」呢？简单来说，它是软体开发的一套方法，特点是只要透过这套方法，就能使你的专案更敏捷。

　　我们为何非得要让专案变得敏捷呢？原因无他，就是因为我们有惯老板、还有惯客户。也就是说，对于现今的市场环境而言，专案不够敏捷是不行的。这一点，相信所有的软体工程师都无法否认吧！

　　可是你可能会反驳说，各行各业都有惯老板和惯客户啊（至少在台湾是这样），为什么软体业就要一套特别的方式来应付他们呢？这就是要回归到一个最根本的问题，「什么是软体？」，或者更精确地说「什么是软体设计？」，而这个问题和所有的软体工程师（或程式设计师）习习相关，因为这是工作的本质。

　　各式各样的工程有着所谓的程序，例如桥樑工程师会先进行结构分析，他们会建立电脑模型并进行模拟，接着他们会建立比例模型，并在风洞中或用其他一些方法进行测试。当这些程序都完成了，才会将设计图交给桥樑的建造工人去建造出真实的桥樑。

　　以上是桥樑工程的开发程序，那么软体开发的程序呢？在很久很久以前（真的是很久很久以前了），软体开发也发展出了所谓的程序，也就是瀑布型开发程序。在瀑布型开发中，系统分析师会依照需求与规画，画出所谓软体的设计图（例如UML图），然后由「程序员」根据这些图去写出程式码，最后建置（build）成可使用的软体。

　　依照瀑布型开发程序开发出来的软体，客户只能选择要用，还是不要用。不要用的话，是否有其他选择？如果没有，那么客户即便不满意，也就只能将就着用（只是边用边骂而已）。当然，这是指套装软体的开发而言。

　　用一个例子来做比方，数十年前，台湾只有国道一号的日子，一位民众想要开车从彰化到新竹，就只能有一个选择，即便他不满意苗栗那段高爬坡会折损车辆寿命，他也别无选择。但当国道三号建造完毕后，他就有了第二个选择，因此他会选择他喜欢的国道来行使。建造国道的总经费是昂贵的（无论是时间还是金钱），但最贵的部分是在于建造部分，而非设计部份。所以国道并不多。竞争者很少。但这种商业模式在软体业是行不通的。

　　若用早期的瀑布型开发程序来对比于国道建设，真正的建造部分，其实就是软体建置（build）的部分，这部分只要一台电脑，一个编译器，一个连结器，还有一点点的时间就完成了。所以代价是极低的。或许有人会说，不对，建造的部分应该也要包含按照UML图去Coding的人工与时间成本。所以这部分的代价应该也是昂贵的。

　　这种说法表面上看似合理，但有多少程式码是完全依照UML图编写的呢？在撰写程式码的过程中是否会修改原有的UML设计呢？早期这类情况并不严重，但晚期因为客户的挑剔，这种情况早就屡见不鲜，甚至任何软体工程师在开发专案时，心中早有预期会出现需求发生变化的情况。

　　国道的建造工人是无权修改设计图的，他只能「按图施工」。而程序员却去修改了设计图，这将使得设计图无法作为最终产品的设计文件。因此，在这种情况下，最终产品的设计文件其实只有一份是准确的，这份文件就是「程式码」。同时，在这种情况下，程序员应该已经不再只是「程序员」或「码农」了，因为他参与了设计，换句话说，他应该称之为程式「设计师」或软体「工程师」。（在敏捷开发中，并不只有那些绘制UML图的才叫做设计人员，正确地说，绘制UML图的人常常也是负责写程式的人）。

　　好的，如果你已经承认「写程式」也算是「设计」的一环，那么软体建置（build）的成本（也就是软体的建造成本，而非设计成本），应该是无庸置疑的低廉了。这也就是为什么，客户说，那边改成XXX颜色，可以吗？你会很干脆地回答，当然没问题，然后五分钟内就给客户看改完之后的结果。想一想，如果要改的是一整段国道护栏的颜色，相信没有客户敢做这样要求，因为他们能预期到，这会花很多很多的钱。

　　所以说，建造软体的花费是很少的，大多数的钱都是花费在「设计」上的。但对于其他工程就不一样了，设计花费的钱相对于建造花费的钱来说，低廉了许多。

　　也就是软体的这种特殊性，导致了客户（更有可能的是上司）常常想要东改改、西改改，需求常常在变化。在现今这个快速变化的世界里，惯客户与惯老板们为了竞争优势（他们心中的竞争优势），提出需求的变化根本是家常便饭。

　　在确定了「需求会变化」、甚至是「会频繁地变化」这个软体工程师一定得面对的事实后，软体工程师该怎么办呢？有一群大师级的软体工程师，开始发明了一系列因应的对策，包含设计模式、极限程式设计、测试驱动开发等等的技艺，还总结了一些物件导向的设计原则。这些都有助于应付变化。最终，这些人集合起来成立了一个「敏捷联盟」，取名为敏捷（Agile），意思是软体开发者及软体本身应该如何敏捷地应付需求的变化，当中牵涉到的范围极广，从成员的组织到程式码的组织都必须敏捷起来，这是门现代软体设计的显学，国外大厂早已採用多年。

　　Robert C. Martin（Bob大叔）是敏捷联盟的创始成员之一，也是当中付诸行动并且有所成效的成员之一。他拥有极具说服力的文笔与口才。在这些年中，不断出书、演讲、作为顾问实际前往开发现场指导，并自创「Clean」一词，其着作还曾获得Jolt大奖，《Clean Code》一书也成为Amazon该类别最畅销的着作，这些都对于敏捷开发的推广有着极重要的贡献。

　　根据《Clean Code》内文的说法，《Clean Code》可说是本书的前传，而本书是完整说明如何实践敏捷的书籍。如果您也喜欢Bob大叔的着作，如果你也是Clean派的弟子，或者你想实际体验敏捷开发，那么你一定不能错过这本书。

　　本书的写作风格是循序渐进，由浅入深的，作者会先提出一个问题，然后分析问题，接着实作它，然后是检讨它，展现出初次实作时的错误与失策，接着就展示如何透过作者所主张的技术来解决这些问题。这是一本非常讲究实务的实践书籍。此外，本书主要使用的是C#程式码，这是由Bob大叔的儿子Micah Martin根据C#与.NET平台的特性重新改写Jolt得奖着作而来的，改写幅度包含所有的程式码与内文，并採用了更容易理解的案例来详述敏捷开发。如果你平常使用的是其他语言，也不必在意，因为传播的介质不重要，传授的内容才是本书的价值所在。

　　对于一些技术细节，本书果真是大师级的作品，原创性极高，在UML章节中，Bob大叔示范了他如何使用UML（果真和一般人不太一样），还示范了如何使用UML才能帮助你而非是制造混乱的来源。对于设计模式而言，除了GoF的知名设计模式之外，Bob大叔还在本书中提到几个他自己常用的设计模式，有些可以视为GoF 23个设计模式的变形，有些则不是，但重点是这些模式都非常好用，可以应用在不同的应用场合，同时Bob大叔也釐清了，某些模式为何不该在哪些场合中使用，他是以效益来看待这件事的，而这也是本书的最大特色：务实。

本书赞誉

　　这也许是第一本把敏捷方法、模式和最新的软体开发基本原则完美结合在一起的图书。当Bob Martin发言时，我们最好洗耳恭听。
　　John Vlissides ──《设计模式》作者

　　这本书中充满了对于软体开发的真知灼见。不管你是想成为一个敏捷开发人员，还是想提升自己的技能，本书都同样有用。我一直在期盼着这本书，它没有令我失望。
　　Erich Gamma ── JUnit之父，《设计模式》作者

　　我期待这本书已经很久了，关于如何去掌握我们的行业技能，本书作者拥有非常丰富的实际经验可以传授。
　　Martin Fowler ── 软体开发大师，《重构》作者

　　前几天，我找到了记有我对Bob大叔第一印象的备忘录。上面写着'优秀的物件思维'。你手中的这本书就是能让你受益终生的'优秀的物件思维'。
　　Kent Beck ── 软体开发大师，JUnit之父，设计模式先驱

　　读过无瑕的程式码，一定要再读「敏捷完整篇」，否则就是您的损失，它会解答您所有的疑惑。
　　《博硕文化》、《名家名着》 总编辑 ── 陈锦辉
 

作者简介

Robert C. Martin

　　人称Uncle Bob，程式设计经验超过40年，Agile Software（敏捷软体开发）的提倡者之一。创立Object Mentor，这是一间专注于C ++、Java物件导向、模式、UML、敏捷方法学和极限程式设计的顾问谘询公司。

　　在这些领域，作者撰写了相当多的名着，并获得有IT奥斯卡奖之称──Jolt震撼年度大奖。本书为该得奖作品的C#版。该得奖年度，Jolt仅颁布通用类、技术类各一本着作得奖，通用类由本书原版获得大奖，而技术类书籍则由另一本广为人知的《Thinking in Java（第三版）》获得。

Micah Martin

　　Robert C. Martin之子，他也是一位敏捷软体专家，本书的C#程式码主要是由他帮忙改写，并包含了许多.NET平台上的特性。
 

关于本书

Section I 敏捷开发
Chapter 1 敏捷实践
Chapter 2 极限程式设计概观
Chapter 3 计画
Chapter 4 测试
Chapter 5 重构
Chapter 6 一次真实的程式设计场景

Section II 敏捷设计
Chapter 7 什么是敏捷设计
Chapter 8 SRP：单一职责原则
Chapter 9 OCP：开放－封闭原则
Chapter 10 LSP：Liskov替换原则
Chapter 11 DIP：依赖反向原则
Chapter 12 ISP：介面隔离原则
Chapter 13 写给C#程式设计师的UML概述
Chapter 14 使用UML
Chapter 15 状态图
Chapter 16 物件图
Chapter 17 使用案例
Chapter 18 循序图
Chapter 19 类别图
Chapter 20 咖啡的启示

Section III 薪水支付案例研究
Chapter 21 COMMAND模式和ACTIVE OBJECT模式：多功能与多任务
Chapter 22 TEMPLATE METHOD模式和STRATEGY模式：继承和委派
Chapter 23 FACADE模式和MEDIATOR模式
Chapter 24 SINGLETON模式和MONOSTATE模式
Chapter 25 NULL OBJECT模式
Chapter 26 薪水支付案例研究：Iteration 1
Chapter 27 薪水支付案例研究：实作

Section IV 打包薪水支付系统
Chapter 28 包和元件的设计原则
Chapter 29 FACTORY模式
Chapter 30 薪水支付案例研究：包分析
Chapter 31 COMPOSITE模式
Chapter 32 OBSERVER ── 演化为模式
Chapter 33 ABSTRACT SERVER、ADAPTER和BRIDGE模式
Chapter 34 PROXY和GATEWAY模式：管理协力厂商API
Chapter 35 VISITOR模式
Chapter 36 STATE模式
Chapter 37 薪水支付案例研究：资料库
Chapter 38 薪水支付系统使用者介面：MODEL VIEW PRESENTER

Appendix A 两间公司
Appendix B 什么是软体
 

None

无瑕的程式码 敏捷完整篇：物件导向原则、设计模式与C#实践 电子书 下载 mobi epub pdf txt 2024

类似图书 点击查看全场最低价

查看全网最低价