基本信息
- 作者: RobertC.Martin
- 出版社:清华大学出版社
- ISBN:9787302071976
- 上架时间:2017-5-18
- 出版日期:2003 年9月
- 开本:16
- 版次:1-1
- 所属分类:计算机 > 软件工程及软件方法学 > 软件方法/软件工程
编辑推荐
《敏捷软件开发:原则模式与实践》是综合性、实用性的敏捷开发和极限编程方面的指南,讲述了在预算和时间要求下软件开发人员和项目经理如何使用敏捷开发完成项目:使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程;包含了极具价值的可重用的C++和Java源代码;还重点讲述了如何使用UML和设计模式解决面向客户系统的问题。《敏捷软件开发:原则模式与实践》于2003年荣获第13届软件开发图书震撼大奖,适于用作高校计算机专业本科生、研究生和软件学院的软件工程和软件开发相关课程的教材或参考书,也适于软件开发和管理人员提高自身水平学习之用。
内容简介
作译者
目录
第一章 敏捷实践
1.1 敏捷联盟
1.2 原则
1.3 结论
参考文献
第二章 极限编程概述
2.1 极限编程实践
2.2 结论
参考文献
第三章 计划
3.1 初始探索
3.2 发布计划
3.3 迭代计划
3.4 任务计划
3.5 迭代
3.6 结论
参考文献
第四章 测试
4.1 测试驱动的开发方法
媒体评论
注:因厂家会在没有任何提前通知的情况下更改产品包装、产地或者一些附件,本司不能确保客户收到的货物与商城图片、产地、附件说明完全一致。只能确保为原厂正货!并且保证与当时市场上同样主流新品一致。若本商城没有及时更新,请大家谅解! [/dd] [/dl] [/div]
[/div] [div id="state"] [strong]权利声明:[/strong]
京东上的所有商品信息、客户评价、商品咨询、网友讨论等内容,是京东重要的经营资源,未经许可,禁止非法转载使用。
[b]注:[/b]本站商品信息均来自于合作方,其真实性、准确性和合法性由信息拥有者(合作方)负责。本站不提供任何保证,并不承担任何法律责任。
印刷版次不同,印刷时间和版次以实物为准。
[strong]价格说明:[/strong]
[b]京东价:[/b]京东价为商品的销售价,是您最终决定是否购买商品的依据。
[b]划线价:[/b]商品展示的划横线价格为参考价,该价格可能是品牌专柜标价、商品吊牌价或由品牌供应商提供的正品零售价(如厂商指导价、建议零售价等)或该商品在京东平台上曾经展示过的销售价;由于地区、时间的差异性和市场行情波动,品牌专柜标价、商品吊牌价等可能会与您购物时展示的不一致,该价格仅供您参考。
[b]折扣:[/b]如无特殊说明,折扣指销售商在原价、或划线价(如品牌专柜标价、商品吊牌价、厂商指导价、厂商建议零售价)等某一价格基础上计算出的优惠比例或优惠金额;如有疑问,您可在购买前联系销售商进行咨询。
[b]异常问题:[/b]商品促销信息以商品详情页“促销”栏中的信息为准;商品的具体售价以订单结算页价格为准;如您发现活动商品售价或促销信息有异常,建议购买前先联系销售商咨询。
[/div] [/div] [div id="comment" class="m m2"] [div class="mt"] [h2]商品评价[/h2] [/div] [div class="mc"] [div class="loading-style1"][b][/b]加载中,请稍候...[/div] [/div] [/div] [div id="comments-list" class="m"] [div class="mt"] [div class="mt-inner m-tab-trigger-wrap clearfix"] [ul class="m-tab-trigger"] [li class="ui-switchable-item trig-item curr" clstag="shangpin
书摘
当软件出现下面任何一种气味时,就表明软件正在腐化。
僵化性(Rigidity):很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其他改动。
脆弱性(Fragility):对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
牢固性(Immobility):很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。
粘滞性(Viscosity):做正确的事情比做错误的事情要困难。
不必要的复杂性(Needless Complexity):设计中包含有不具任何直接好处的基础结构。
不必要的重复(Needless Repetition):设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一
。晦涩性(Opacity):很难阅读、理解。没有很好地表现出意图。
1.僵化性
僵化性是指难以对软件进行改动,即使是简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动,那么设计就是僵化的。必须要改动的模块越多,设计就越僵化。
大部分的开发人员都以这样或者那样的方式遇到过这种情况。他们会被要求进行一个看起来简单的改动。他们看了看这个改动并对所需的工作做出了一个合理的估算。但是过了一会儿,当他们实际进行改动时,会发现有许多改动带来的影响自己并没有预测到。他们发现自己要在庞大的代码中搜寻这个变动,并且要更改的模块数目也远远超出最初估算。最后,改动所花费的时间要远比初始估算长。当问他们为何估算得如此不准确时,他们会重复软件开发人员惯用的悲叹,“它比我想像的要复杂得多!”
2.脆弱性
脆弱性是指,在进行一个改动时,程序的许多地方就可能出现问题。常常是,出现新问题的地方与改动的地方并没有概念上的关联。要修正这些问题就又会引出更多的问题,从而使开发团队就像一只不停追逐自己尾巴的狗一样(忙得团团转)。
随着模块脆弱性的增加,改动会引出意想不到的问题的可能性就越来越大。这看起来很荒谬,但是这样的模块是非常常见的。这些模块需要不断地修补——它们从来不会被从错误列表中去掉,开发人员知道需要对它们进行重新设计(但是谁都不愿意去面对重新设计中的难以琢磨性),你越是修正它们,它们就变得越糟。
3.牢固性
牢固性是指,设计中包含了对其他系统有用的部分,但是要把这些部分从系统中分离出来所需要的努力和风险是巨大的。这是一件令人遗憾的事,但却是非常常见的事情。
4.粘滞性
粘滞性有两种表现形式:软件的粘滞性和环境的粘滞性。
当面临一个改动时,开发人员常常发现会有多种改动的方法。其中,一些方法会保持设计;而另外一些会破坏设计(也就是生硬的手法)。当那些可以保持系统设计的方法比那些生硬手法更难应用时,就表明设计具有高的粘滞性。做错误的事情是容易的,但是做正确的事情却很难。我们希望在软件设计中,可以容易地进行那些保持设计的变动。