作者 内容
 jyemii   与作者Robert C. Martin深度技术访谈关于终极制程(一)
[Mark Collins-Cope]：
Bob 你目前对于Kent Beck's eXtreme Programming对于软件开发的方法论相当支持。 由于你是使用UML的提倡者或至少你已广泛的撰写UML的文章；而您的支持XP似乎令人感到讶异。对于那些对此感到讶异的人你有甚么意见？

[Robert Martin]：
对于这些讶异我也感到很讶异;-). XP与 UML并不完全互斥。我仍然是UML的拥护者，我将持续使用UML并且撰写有关UML的文章。
XP是一个开发程序(development process). XP对于UML并没有说些甚么。有人说使用XP的人(XPers)不使用UML来组合他们的模式概念。无论如何，并不是这样的。在XP，我们还是要建立模式；同时我们还是要设计我们的软件。当然我们可以在设计中使用UML。
XP在分析与设计的方式有一点不同。不管如何，UML产生的图形（或者任何你使用的其它塑模方法）只有很少的例外情形是XP在生产他们的程序代码时所忽略。XP将价值放在程序代码以及使用案例(use cases)，并忽略中间步骤。
--------------------------------------------------------
待续 … www.dotspace.idv.tw
 01/11/05 14:21 酷帖！    臭帖！    回复  
原文(jyemii于2001/11/05 14:22粘贴)
与作者Robert C. Martin深度技术访谈关于终极制程(二)
  [Mark]：
目前开发程序在软件开发社群中是一个热门的重点。我们有RUP, Open, Catalysis, XP 等等，所有者些方法论似乎都对世界提出相对立的观点。甚么是软件开发或管理的平衡可以提供？对于软件开发是否有甚么事情是正确或错误的方式？

[Bob]：
是的，有。正确的方式是在最少慌乱的情况下达成任务。Kent Beck在开发程序有相当敏锐的观察 。开发程序就是关于管理恐惧。我们把开发程序放在正确的地方是因为我们恐惧。如果我们恐惧是大的我们在适当的地方使用大量(big)的程序，如果我们恐惧是小的我们在适当的地方使用少量的程序甚至没有使用程序。对于特定团队程序是否是正确的是视程序平衡他们的恐惧与企图心。
XP是适用于有企图心的团队；他们希望快速的使产品进入市场。XP管理者恐惧使用人的方法(people methods)而不是纸上作业的方法(paper method)。在XP；对于速度的恐惧经由双人组设计,撰写大量的测试,（至少每天）与客户沟通得以减低。
------------------------------------------------------------------

[Mark]：
所谓管理恐惧；我假设你的意思是害怕项目失败,不良的设计等等。有些恐惧的原因--例如过去的失败。在这种情况，难道没有好的理由好好的在项目生命周期中定义查验点(check points)以便在失败变得难以收拾之前发现并解决。

[Bob]：
查验点是一个好办法，当某些事是好的时，XP将旋扭转到10（译注：当某些事是值得采用时，XP便充分运用）。这就是为什么XP之所以『终极(extreme)』的原因。所以在每几分钟就有一个查验点。我们每几分钟就执行测试以确保系统仍然是正确的行为。我们每几分钟重新考虑我们的设计并在需要的时候重组(refactor)。我们不时重新评估(re-estimate)我们的进度并且重新对计划重新排列优先级，因此我们不会在延迟的假设下工作。
-----------------------------------------------------------------

待续 … www.dotspace.idv.tw
作者 内容
 jyemii   与作者Robert C. Martin深度技术访谈关于终极制程(三)
[Mark]：
你会称XP是RAD技术吗？为什么？
　
[Bob]：
不，RAD技术处理恐惧是依据开发者希望被鼓舞到某一层度愚笨的假设（译注：RAD是让愚笨的人也可以使用），XP并不是高风险的开发程序。他跑得很快，但也很安全。

XP由测试控制。只要多少行的测试程序代码在XP项目中便有多少行的产品程序代码。只要我们作任何改变那么测试就随时要执行。他们告诉我们当我们破坏一些东西 ，在XP检验未通过『所有』测试的程序代码是不合规定的。因此，程序代码绝不会有重大的破坏。
------------------------------------------------------------------

[Mark]：
UML现在包含8种表示法(notations)。你是否觉得UML有点庞大并且包含他本身的所有优点？XP的出现会有些事情冲击这点及更重量型(heavyweight)的开发过程定义吗？ XP是从正式的(formality)程序比较大的摆荡到非正式(informality)程序的一部份吗？
　
[Bob]：
UML的大小(size)并不是一种伤害。开发者并不会乖乖的使用UML表示法的所有部分。相反的我们只选择我们需要的并且忽略其余的。因此我很高兴UML是庞大的，因为UML给我们一大堆的工具可供取用。

我认为像XP这样的轻量型的开发程序是有一部份冲击庞大正式的开发程序。开发程序在最近多十年来变的愈来愈大愈沉重；同时没有明显的增加软件的品质来支持成长。就如软件工业所说的「喔；我们的巨大开发程序并没有带给我们所需的利益；我想要让开发程序更大一点 。」

我们之间许多人都已经忘了对抗逐渐肥胖的发展程序多年了。我想XP我们之间充分了解发展程序成长的人所发的一种陈述。

从另一方面而言，认为XP是自正式化(formality)或有纪律的(discipline)特性偏离的想法是一种误解。XP是以程序代码为中心(code-centric)；同时有一些更正式的编辑程序。XP也是有高度纪律的。XP的实务有非常精细的特征(narrow parameter)，你不能只决定不做他们。（译注：XP的规则设计彼此之间有相当大的关连性，缺乏某一项实务特性可能导致失败。所以不可随意选择要做哪些或不做哪些。）
-----------------------------------------------------------------

待续 … http://www.dotspace.idv.tw
 01/11/11 22:16 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
原文(jyemii于2001/11/14 09:10粘贴)
与作者Robert C. Martin深度技术访谈关于终极制程(四)
  [Mark]
所以程序的欠缺并不能归咎于采用较大型开发程序而导致软件失败的原因 ，你会归咎于哪一部份？
　
[Bob]
目前使用的开发程序注重文件而比较不注重人。文件无法思考，文件无法解决问题，文件无法因应改变而调适。我们可以安排我们所要的查核进度，我们可以产出所有我们要的分析及设计档，我们可以合作并交叉检验及规划我们所喜欢的。但只要人们被考虑为开发程序中第二顺位元的元素，这种开发程序将会失败。

Alistair Cockburn说的最好，开发程序是成功结果的第二顺位。第一顺位是人。XP重视人。XP提供一种框架其中人们可以有效的沟通。就如Kent Beck所言XP是企图让他说明真相而达到成功(XP is an attempt at making it OK to tell the truth.)。

-----------------------------------------------------------------
　
[Mark]
引用Ralph Johnson所言（这是听说的）XP开发程序是分析....测试....编写程序代码.....设计....你认为这是真实的描述XP吗？
　
[Bob]
不。无论如何，那只是一段差强人意对于XP开发插曲的描述。一个开发的插曲可能延续计几小时。

一个XP专案充满上百个小的微反复(micro iterations)。其中每一个反复包含分析,测试,编写程序代码,设计。其顺序是重要的。首先要了解（即分析）；同时也包含一些设计。然后我们撰写测试案例(test cases)；它描述我们所了解的。撰写测试表示我们同时必须在我们心中有设计的程序代码，然后我们撰写可以通过测试的程序代码；同时当然有一个设计的元素包含于我们的撰写程序代码。最后我们重组程序代码使之尽可能的简单(simple)及干净(clean)。所以在这四个步骤当中都有一个设计的观点(aspect)。
-----------------------------------------------------------------

待续 … http://www.dotspace.idv.tw

　

作者 内容
 jyemii   与作者Robert C. Martin深度技术访谈关于终极制程(五)
[Mark]
在系统整体软件架构(software architecture)（包裹结构(package structure),架构层次(architecture layering)等等），您一直是应用程序的好的设计原理的倡议者（非循环相关(acyclic dependencies),接口隔离(interface segregation)等等）。系统的架构（这里所定义的）是XP的风险吗？系统隐喻(system metaphor )的概念似乎不是；对我而言至少不是；等同于架构的定义，这一点你的想法是如何？
　
[Bob]
架构大概是任何软件项目单一最重要的观念。每有一个好的架构，一个系统堕入泥土中的颤抖水珠。我开发软件所使用的任何开发程序将是尽可能以产出最佳的架构为中心。

XP有一个架构的步骤即众知的系统隐喻。隐喻的概念并不能代表架构完整的面貌。相对的它是架构的结晶结构(crystalline structure)将要成长的种子。
架构无法于仪式(orgy)的前置设计中充分的决定。架构；像其它软件环境中的所有事物一样；必须发展。XP提供频繁的反复，而架构着重于确保强壮的架构随着软件成长逐渐发展成型。

在XP中的规则有部分着重开发者维护及发展架构。简单化的规则,沟通的规则,程序的规则。如果一个模式不是在他们所知的最干净,最简单化,最弹性的状态下开发者并不允许登入(check in)一个模式。开发者在任何时候当他发现重复的程序代码必须立即拆除。开发者不得单独工作，必须成对的工作，因此他们可以彼此要求架构的议题。

-----------------------------------------------------------------　
[Mark]
我同意你的意见有关于架构是重要的，同时你好像不是把一个架构的所有的概念摆在最前端。但把一个架构系统摆在最前端的观点并不是坏事，是吗？
　
[Bob]
不，一点也不。这就是为什么我们在XP建立一个系统隐喻。那有为什么每一个发行都以探索的步骤开始，同时每一个反复以重新评估目前的设计及架构开始。

-----------------------------------------------------------------

待续 … http://www.dotspace.idv.tw
 01/11/14 09:15 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 luodi   标题不如不要叫终极制程，直接写XP好了，看得很不习惯。:)
 01/11/14 09:26 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
作者 内容
 jyemii   与作者Robert C. Martin深度技术访谈关于终极制程(六)
[Mark]
做可以达成的最简单的事」是XP的设计格言。如果多一点事先的考量(forethought)及少一点立即性(immediacy)，重组现有程序代码的必要性便可以避免，不是真的吗？有一个相关的观点是一个方法论调适得多『完整(holistic)』？完整性(holistic)；我的意思是相对于『一点一点的(piece by piece)』--以一个比较宽广的功能需求观点并尝试设计一个解决方式可以涵盖；譬如；5个需求而不是一个。
　
[Bob]
以『多一点事先的考量』是可能的，我们可以减少一些重组的动作。所以为什么我们选择重组而不是运用事先的考量？简单的说重组是比较便宜而且比较可信赖。
我不是说事先的考量没有价值--确实如此。但是事先考量是不确定性(speculative)。而且把时间花在不确定的冒险是比把时间花在确定的冒险昂贵的。因此我比较喜欢重组的安全性(surety)而不喜欢长期的事先考量的不确定性。
因此；在每一个任务的前期；我会设计任务，并确认符合目前系统的架构。我会撰写测试，我会撰写可通过测是的程序代码，然后我会再次检视程序代码并且重组，一小步一小步，直到我认为这个设计是好的。没有长期的不确定性，只有短期的安全性。
这会导致革命吗？当然是！当重组的方法在一个局部最小值(local minimum)得以理解便将是时候了。此时会有一个比较好的方法应用于整个系统，但需要局部最小值更多的努力及更进一步达到总体最小 值(global minimum)。只要这类需求被界定，使用XP的人便勇于重组到新的总体最小化。他们不会害怕的原因是：

1.他们在每一步骤有测试的方式所以没有任何事物被破坏。
2.他们是双人组共同设计，所以每一步骤有利于两个人的心智。
3.他们实施共同程序代码拥有，所以他们对于现有程序的每一部份都很熟悉。

经由一些事先的考量避免错误可以变成更好的设计（总体最小化）吗？或许吧。要有多少的事先考量才能确保你都已找到可能的变量？事先考量你要付出多少？哪为什么要事先付出？XP的哲学是：当你需要时为你所需的付出，而且不要在你需要之前。
　
--------------------------------------------------------------
[Mark]
但如果你正需要一个特定的设计结构来涵盖下两个你要做的需求，难道你不会事先投入一些额外的工作来涵盖它吗？而且重组是否真的比设计来的便宜吗？
　
[Bob]
你的结构设计是否正确？如果你尚未实作其中之一的功能你如何保证结构设计是正确的？你可以确认实作你认为设计应有的样子会比较便宜吗？或者当你需要它而且立即需要时才实作设计会比较便宜？XP选择后者；其假设是事先付出在推测平均而言是较实时的付出于你当时正需要的更为昂贵的。XP证明这点其认为重组于丰富的单元测试及双人组程序设计是非常便宜的。

-----------------------------------------------------------------

待续 … http://www.dotspace.idv.tw
 01/11/23 16:43 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
作者 内容
 jyemii   与作者Robert C. Martin深度技术访谈关于终极制程(七)
[Mark]
我们都知道设计是困难的。思考设计是困难的，而且确实比撰写程序获得更少的立即回报。我个人的经验虽然是软件设计得到基本的正确要付出很多（这里我的意思是经过2到3个月的时间），而XP没有『做到设计(design deliverables)』本身，设计不够充分不是更危险？
　
[Bob]
否。一点也没有危险。事实上，设计在XP环境中是非常旺盛的。XP可以说就是设计。我们持续驱动程序码到我们所知的尽可能好的设计。我们绝不会说「我们要后退并随后修复。」

设计是如何我们必须达成协议。一个程序的设计是其程序代码的样子(shape)。切割(partition)程序代码成为方法,类别,包裹等等，及存在于这些元素之间的关系。我们可能以图形展示这些东西，但图形不是设计。他们只是设计的代表物(proxies)而已。真实的设计是在程序代码？XP不重视设计的代表物。XP重视的是以程序代码直接表达设计。同时XP重视程序代码的可能最佳设计。
XP将最高的价值放在这里，因而强迫我们撰写测试以让我们可以无畏的重组，也因此我们可以自由的移动程序代码朝向我们所认知的最好的设计。

-----------------------------------------------------------------
　
[Mark]
确实，我们工作的目标是我们程序代码的样子是容易维护,扩充等等。同时确实，我们似乎有时需要调整(restructure)--重组(refactor)--我们的程序代码。我想基本上我担心的是没有明确的『设计』阶段，你只是延迟在某一点你必须做的决定，既使我可以看到重视重组表示最终你可以到达。
　
[Bob]
再强调一次，XP认为 为你未来所需就在现在付出是比为你所知目前立即需要的付出要昂贵的多。这种方式的风险是可能比事先考量的方式有更多的修正(rework)，也就是说其成本超过了事先考量设计的成本，而这个成本在整个软件项目生命周期带来了所有额外的无用设计。XP认为修正在有单元测试及双人组程序设计的情况下不是昂贵的，而那是事先考量设计的成本；事先考量中错误的猜测及在软件中带着所有的事先考量设计的元素是昂贵的。
-----------------------------------------------------------------

待续 … http://www.dotspace.idv.tw
 01/11/23 16:45 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 maxtiger  回复: 与作者Robert C. Martin深度技术访谈关于终极制程(七)
：）
 01/11/23 16:55 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首