| jyemii |
 XP:抄近路的诡计(六)
Doug Rosenberg及Kendall Scott对于XP的质疑
----------------------------------------------------------------------
准备、射击、瞄准
---------------------------------------------------------------------
就如统一开发程序(Unified Process)描述的四个阶段（反复(iteration)、精细制作(elaboration)、建构(construction)及转换(transition)）；这些在在项目的每一个反复中执行，XP说的是「故事(stories)、测试(testing)、撰写程序代码(coding)及设计(design)」。强烈的与大设计比较；统一开发程序符号表示法(symbolizes)，XP方法论提供『微量渐进式发展(nanoincrement)』，它的基础是不超过一周的渐进式开发，甚至是短到一天。更快、更快、更快！
我们不反对找到软件开发程序更快速的方法--只要这种方式产生的结果不是「准备、射击、瞄准」。<译注3>
由于拒绝花任何一些有意义的时间指出在开始『生产』之前应做甚么，并且坚持在一个进行中的基础下『以小的方式(in
the small)』做大的工作(great work)；从某种角度当烟幕消散时将神奇的产生整个系统被矫正，XP人似乎认为他们已找到银色子弹(silver
bullet)<译注4>以反击大设计的假设：偏向于在细节部分陷入泥沼。
这是一个很明显的短视(short-sighted)方式。我们可以以分析及设计到一个非常可接受的层次降低失败的风险而无须把身体连同洗澡水抛弃。早期进入程序代码撰写并不代表没有风险；这个风险只是不同的本质（在某些情况可能更难以捉摸）。我们应该尝试最小化项目整体的风险层次，而不是部分的风险。
当Doug七年前开始教授OOAD，最通常的失败点是在
训练研讨会(training workshop)；总是发生在从需求层次（使用案例）系统行为观点移动到一个细节设计层次（循序图/合作图）行为观点所做的努力。
尝试跳过这个阶段--在这本书中我们称之为跳过『甚么-如何(what-how)』的差距--从一个纯需求(pure
requirements)观点到一个细节设计观点是异常的困难。人们总是发现的是经由增加动态模式（坚实的分析(robustness
analysis)）的『初始设计(preliminary design)』观点，他们持续能够让团队通过这个转换点。
我们仍然能够平衡渐进式开发的利益（可能使用一些较大的渐进式程序），严格的测试及其它可能被证明有用的技术，如双人组程序设计。以这种方式，我们保证我们不止将会总是拥有一个执行的方案(functioning
program)，同时我们可以让最好的开始是『一开始就朝正确的方向』，同时减少对以这种劳力密集(labor-intensive)方式重做及重测试的需要。
---------------------------------------------------------------------
文件是无用的
---------------------------------------------------------------------
一个真正的Xtremist相信程序代码不只是设计同时是文件。『无情的重整(Merciless
refactoring)』（另一个XP用语）将一直一直一直产生完全干净的程序代码；既使是最没有经验的开发者也能够达成。一个信徒杜撰了一个名词『极端的清澈(Extreme
Clarity)』，其中他定义为「一个程序的属性就像程序代码展示每一个人需要知道的系统所有东西；立即上手；一目了然；非常的准确(accurate
to six places)」
我们没有强辩这不是一个我们想要的结果。而就非程序代码(non-code)文件而言，维持与想象中的快速撰写程序代码机制同步的可能性不是真的吗？而口头的沟通比在多数项目中写下来的作用好不是真的吗？总而言之，「所有的文件要被怀疑是过期及主观的偏见」这些声音对我们而言就像一个无理的对文件的恐惧。
事实上，在一个开发成果的背景，够格的技术撰写者知道一些相关程序代码的东西将通常能够赶上开发者及分析者并且维持到目前为止。同时，有效的口头沟通是关键性的重点，但不能免除把数据写下来--为外部的人、为新人、为未来的参考者、为某些目前可能不是很明显的原因。就主观的偏见而言，嗯，所有的写下的都有某种的偏见，但软件文件设想是传达是甚么(what
is)，而不是可能是甚么(what could be)，同时如果那不如此做，不是媒体的错误。
除了口头沟通任何事物的缺乏表示撰写程序代码的人必须回答问题。
依据历史观点，在近半世纪被无数次用作为『工作保障(job
security)』的机制。在太多的案例中，这些人把文件放在他们的脑袋中（或者是团对把文件放在他们集体的脑袋中）在维护程序设计师出现时已是过去式了。
这里有一个Doug的故事
「我有一个程序设计师为我工作，负责我们的数据流图编辑。他的进度常常延迟。我们开会讨论这种情况。他说--我引用他的话而我记得非常清楚：『你不能让我更快，你不能让别人来帮助我，你不可以解雇我』他很有信心的说，因为所有的设计文件都在它的脑袋中。我非常震惊于他的说法，第二天我解雇了他。这是我做的决定中最好的一个。我以一个人取代他，这个人所写的程序代码非常好，而且随时把他所做的记入文件中。」
不管如何，为后人记录图表并不是十分重要的事。检视(reviewing)图表--并据以设计--在撰写程序代码之前是十分重要的事。如果你能让团队中的高级程序设计师检视（并修正）系列的图表中将要撰写程序代码的情节(scenarios)，同时你在撰写程序代码之前已查核(verify)架构（静态模式）可以支持所有的情节，你将有一个比较轻松的撰写程序及测试的时光，同时你将使得后续要做的拆开程序代码、重新撰写程序代码及重新测试的工作降至最低。
而这里有从Beck所说的：「多数的人表达他们的恐惧；就是把CRC卡转换成数据库（Notes或Access）、Excel，或某些该死的项目管理程序。」因此我们现在看到XP人把客户视为不确定（考虑他们的需求时）并且恐惧（就持续追踪将要发生的事）。我们期待XP信徒(XPites)证实他们的『怀疑』如此XP可以假设拥有传说中的FUD(恐惧(Fear),不确定(Uncertainty),怀疑(Doubt))三位一体，如以往对微软的观感一般。
---------------------------------------------------------------------
<译注3>对于这点Kent Beck及Martin Fowler在『Planning
eXtreme Programming』一书中第三章有所说明。
<译注4>银色子弹亦即中文的万灵丹。
待续 …
http://www.dotspace.idv.tw
|
