OriginaltextiscopyrightedbyMartinFowler
MartinFowler
ChiefScientist,ThoughtWorks
原文出处|繁体版|译者：DaimlerHuang
对很多粗略接触到ExtremeProgramming的人来说，XP似乎宣告了软件设计的死刑。不只很多的设计被嘲笑为"BigUpFrontDesign"[译注1]，连很多技术像UML、富有弹性的程序架构(framework)，甚至连模式(pattern)都不受重视，或是近似忽略了。事实上，XP内含很多设计理念，但是它与现有的软件流程有着不同的运作方式。XP藉由多种实务技巧(practice)赋予演进式设计(evolutionarydesign)崭新的风貌，让演进变成一种实用的设计方法。它也让设计者(designer[译注2])面临新的挑战与技巧，学习如何使设计精简，如何使用重构来保持一个设计的清楚易懂，以及如何逐步地套用模式。
PlannedandEvolutionaryDesign(经过规划的设计与演进式的设计)
TheEnablingPracticesofXP(XP有效的实作技巧)
ThevalueofSimplicity(简单的价值)
WhatonEarthisSimplicityAnyway(究竟什么是简单)
DoesRefactoringViolateYAGNI(重构违反了YAGNI吗？)
PatternsandXP(模式与XP)
GrowinganArchitecture(发展结构)
UMLandXP(UML与XP)
OnMetaphor(关于隐喻)
DoyouwannabeanArchitectwhenyougrowup(你将来想成为一个软件结构师吗？)
Thingsthataredifficulttorefactorin(很难重构的东西)
SoisDesignDead(所以，设计死了吗？)
Acknowledgements(致谢)
RevisionHistory(修订的记录)
ExtremeProgramming(XP)挑战很多软件开发常见的假设。其中最受争议的就是极力排斥up-frontdesign，而支持一种比较属于演进的方式。批评者说这是退回到了"codeandfix"的开发方式，顶多只能算是一般急就章的程序设计罢了。支持者也常看到XP对于设计方法(如UML)、principle(设计准则)、patterns等的排斥。别担心，仔细注意你的程序代码，你就会看到好的design浮现出来。
我发现自己正陷于这个争论当中。我的工作着重在图形化设计语言-UML以及patterns，事实上我也写过UML和patterns的书。我如此的拥抱XP是否表示我放弃了这些理论，或是将这些反渐进式(counter-revolutionary)的概念从脑中清除了？
PlannedandEvolutionaryDesign
PlannedDesign的做法正好相反，并且含有取自其它工程的概念。如果你打算做一间狗屋，你只需要找齐木料以及在心中有一个大略的形象。但是如果你想要建一栋摩天大楼，照同样的做法，恐怕还不到一半的高度大楼就垮了。于是你先在一间像我太太在波士顿市区那样的办公室里完成工程图。她在设计图中确定所有的细节，一部份使用数学分析，但是大部分都是使用建筑规范。所谓的建筑规范就是根据成功的经验(有些是数学分析)制定出如何设计结构体的法则。当设计图完成，她们公司就可以将设计图交给另一个施工的公司按图施工。
PlannedDesign将同样的方式应用在软件开发。Designer先定出重要的部份，程序代码不是由他们来撰写，因为软件并不是他们"建造[译注3]"的，他们只负责设计。所以designer可以利用像UML这样的技术，不需要太注重撰写程序代码的细节问题，而在一个比较属于抽象的层次上工作。一旦设计的部份完成了，他们就可以将它交给另一个团队(或甚至是另一家公司)去"建造"。因为designer朝着大方向思考，所以他们能够避免因为策略方面不断的更改而导致软件的失序。Programmer就可以依循设计好的方向(如果有遵循设计)写出好的系统。
建造者(builder[译注3])和设计者之间这种微妙的关系在建筑界也看得到，只是在软件界更加凸显而已。之所以会如此强烈是因为一个关键性的差异。在建筑界，设计师和工程师的技术有清楚的分野；在软件界就比较分不清楚了[译注2]。任何在高度注重design的环境工作的programmer都必须具备良好的技术，他的能力足够对designer的设计提出质疑，尤其是当designer对于新的发展工具或平台越来越不熟悉的状况下。
现在这些问题也许可以获得解决。也许我们可以处理人与人之间的互动问题。也许我们可以加强designer的技术来处理绝大部份的问题，并且订出一个依照准则去做就足够改变设计图的流程。但是仍然有另外一个问题：变更需求。变更需求是软件项目中最让我感到头痛的问题了。
处理变更需求的方式之一是做有弹性的设计，于是当需求有所更改，你就可以轻易的变更设计。然而，这是需要先见之明去猜测将来你可能会做怎样的变更。一项预留处理易变性质的设计可能对于将来的需求变更有所帮助，但是对于意外的变化却没有帮助(甚至有害)。所以你必须对于需求有足够的了解以隔离易变的部份。照我的观察，这是非常困难的。
部份有关需求的问题应该归咎于对需求的了解不够清楚，所以有人专注于研究需求处理，希望得到适切的需求以避免后来对设计的修改。但是即使朝这个方向去做一样无法对症下药。很多无法预料的变更起因于瞬息万变的商场，你只有更加小心处理需求问题来应付无法避免的情况。
这么说来，planneddesign听起来像是不可能的任务。这种做法当然是一种很大的挑战。但是，跟演进式设计(evolutionarydesign)普遍以codeandfix方式实作比较起来，我不觉得planneddesign会比较差。事实上，我也比较喜欢planneddesign。因为我了解planneddesign的缺点，而且正在寻找更好的方法。
TheEnablingPracticesofXP
XP因为许多原因而备受争议，其中之一就是它主张演进式设计(evolutionarydesign)而不是planneddesign。我们也知道，演进式设计可能因为特定的设计或是软件开发趋于混乱而行不通。
想了解这些争论的核心，就是软件研发异动曲线。曲线的变化说明，随着项目的进行，变更所需要的成本呈现指数的增加。这样的曲线常以一句话来表示：在分析阶段花一块钱所作的变更，发行之后要花数千元来补救。讽刺的是大部分的计画仍然没有分析过程而以非标准的方式进行，但是这种成本上的指数关系还是存在着。这种指数曲线意味着演进式设计可能行不通，它同时也说明着为什么planneddesign要小心翼翼地规划，因为任何的错误还是会面对同样的问题。
这些有效的实作技巧有几个部份，主要是Testing和ContinuousIntegration。如果没有testing提供保障，其它的XP实作技巧都不可行。ContinuousIntegration可以保持团队成员信息同步，所以当你有改变的部份，不必担心与其它成员资料整合会有问题。同时运用这些实作技巧能够大大影响开发曲线。这让我再次想起在ThoughtWorks导入testing和continuousintegration之后，明显的改善了研发成果。改善的程度好到令人怀疑是不是像XP所主张的，必须要用到所有的实作技巧才能大幅改善效率。[译注4]
Refactoring具有类似的成效。那些曾经采用XP建议的原则来对程序代码进行refactoring的人发现，这么做要比无章法或是特殊方式的restructuring明显的更有效率。那也曾经是Kent指导我适当的refactor得到的难忘经验，也因为这么一次巨大的转变促使我以这个主题写了一本书。
Continuousintegration、testing和refactoring这些有效的实作方法让evolutionarydesign看似很有道理。但是我们尚未找出其间的平衡点。我相信，不论外界对XP存有什么印象，XP不仅仅是testing、coding和refactoring。在coding之前还有design的必要。部份的design在coding之前准备，大部份的design则发生在实作每一项详列的功能之前。总之，在up-frontdesign和refactoring之间可以找到新的平衡。
ThevalueofSimplicity
XP大声疾呼的两个口号是"DoTheSimplestThingthatCouldPossiblyWork"(只做最简单可以正常运作的设计)和"YouAren'tGoingtoNeedIt"(就是YAGNI-你将不会需要它)。两项都是XP实务中简单设计的表现形式。
YAGNI一词时常被讨论，它的意思是现在不要为了将来可能用到的功能加入任何程序代码。表面上听起来好象很简单，问题则出在像framework、重用组件、和弹性化设计，这些东西本来就很复杂。你事先付出额外的成本去打造它们，希望稍后将这些花费都赚回来。这个事先弹性设计的想法被认为是软件设计有效率的关键部份。
第二个支持simpledesign的理由是复杂的设计违反光线行进的原理。复杂的设计比简单的设计还要令人难懂。所以随着渐增的系统复杂度，更加难以对系统做任何修改。如此，若系统必须加入更复杂的设计时，成本势必增加。
现在很多人发现这样的建议是无意义的，其实他们那样想是对的。因为你所想象一般的研发并没有被XP有效的技巧所取代。然而，当规划式设计和渐进式设计之间的平衡点有了变化(也只有当这样的变化发生时)，YAGNI就会变成好的技巧。
所以结论是，除非到了往后的阶段有所需要，否则你不会浪费精神去增加新的功能。即使不会多花成本，你也不会这样做，因为就算现在加入这些功能并不增加成本，但是却会增加将来做修改时的成本。总之，你可以在套用XP时明智的遵守这样的方法，或是采取一种能降低成本的类似的方法。
WhatonEarthisSimplicityAnyway
因此，我们希望程序代码能够越简单越好，这听起来没什么好争论的，毕竟有谁想要复杂呢？但问题来了，究竟"什么才叫简单呢？"
在XPE一书中，Kent对简单系统订了四个评量标准，依序是(最重要排最前面)：
通过所有测试。
呈现所有的意图。
避免重复。
最少数量的类别或方法。
通过所有测试是一项很普通的评量标准，避免重复也很明确，尽管有些研发人员需要别人的指点才能做到。比较麻烦的是"呈现所有的意图"这一项，这到底指的是什么呢？
这句话的本意就是简单明了的程序代码。XP对程序代码的易读性有很高的标准。虽然在XP当中，"巧妙的程序代码(clevercode)"这个字眼经常被滥用，不过意图清楚的程序代码，对其他人来说真的是一种巧妙。JoshKerievsky在XP2000论文中举了一个很好的例子，检视在XP领域可能是大家最熟知的JUnit的程序代码。JUnit使用decorators在testcases中加入非必要的功能，像是同步机制及批次设定等，将这些程序代码抽出成为decorator，的确让一般的程序代码看起来清楚许多。
但是你必须扪心自问，这样做之后的程序代码够简单吗？我觉得是，因为我了解Decorator这个patterns。但是对于不了解的人来说还是相当复杂的。类似的情况，JUnit使用pluggablemethod，一种大部分的人刚开始接触时都不会觉得简单的技巧。所以，也许我们可以说JUnit对有经验的人来说是比较简单的，新手反而会觉得它很复杂。
XP的"OnceandOnlyOnce"以及PragmaticProgrammer(书名)的DRY(Don'tRepeatYourself)都专注在去除重复的程序代码。这些良好的建议都有很显著而且惊人的效果。只要依照这个方式，项目就可以一路顺利的运作。但是它也不能解决所有问题，简单化还是不容易达成。
最近我参与一个可能是过度设计的项目，系统经过refactor之后去除部份弹性的设计。但是就像其中一位开发者所说的"重构过度设计的系统要比重构没有设计的要来的容易多了"做一个比你所需要简单一点的设计是最好的，但是，稍微复杂一点点也不是什么严重的事情。
我听过最好的建议来自Bob大叔(RobertMartin)。他的建议是不要太在意什么是最简单的设计。毕竟后来你可以，应该，也会再重构。愿意在最后重构，比知道如何做简单的设计重要得多。
DoesRefactoringViolateYAGNI
这个主题最近出现在XP讨论区上，当我们审视设计在XP扮演的角色时，我觉得很值得提出来讨论。
YAGNI的观点是不要增加一些现阶段不需要的复杂功能，这也是简单设计这项技巧的部份精神。重构也是为了满足尽可能保持系统的简单性这个需要，所以当你觉得可以让系统变得更简单的时候，就进行重构。
简单设计不但利用了XP的实务技巧，本身也是其中一项有用的实务技巧。唯有伴随着测试，持续整合，及重构的运用，才能有效地做出简单设计。同时，让研发异动曲线保持平缓的基础也就是保持设计的简单。任何不必要的复杂都会让系统变得难于调整，除非这个复杂性是你为了所预测的弹性而加入的。不过，人们的预测通常都不太准确，所以最好还是努力地保持简单性。
不管怎样，人们不太可能第一次就能够获得最简单的东西，因此你需要重构来帮助你更接近这个目标。
PatternsandXP
JUnit的例子让我不得不想到patterns。XP和patterns之间的关系很微妙，也常常被问起。JoshuaKerievsky认为patterns在XP被过分轻视，而且他所提出的理由也相当令人信服，我不想再重提。不过值得一提的是，很多人都认为patterns似乎与XP是有冲突的。
其中一项论点是简单设计的力量自然会将项目导向patterns。很多重构的例子明确地这么做，或者甚至不用重构，你只要遵从简单设计的规则就会发现patterns，即使你还不知道patterns是什么。这样的说法也许是真的，不过它真的是最好的方式吗？当然如果你先对于patterns有个大略的了解，或者手边有一本书可以参考，会比自己发明新的patterns要好些。当我觉得一个pattern快浮现的时候，我必定会去翻翻GOF的书。对我来说，有效的设计告诉我们pattern值得付出代价去学习－那就是它特有的技术。同样地就像Joshua所建议的，我们需要更熟悉于如何逐步地运用patterns。就这一点而言，XP只是与一般使用patterns的方式不同而已，并没有抹煞它的价值。
我对于采用XP的人使用patterns的建议：
留意使用patterns的时机(但是别太早)。
留意如何先以最简单的方式使用patterns，然后再慢慢增加复杂度。
如果用了一种pattern却觉得没有多大帮助－不用怕，再次把它去掉。
我认为XP应该要更加强调学习patterns。我不确定它要怎么和XP的实务技巧搭配，不过相信Kent会想出办法来的。
GrowinganArchitecture
软件架构是指什么呢？对我来说，架构这个字眼代表系统核心组件的概念，也就是难以改变的部份，剩下的都必须建造在这基础上。
那么当你使用演进式设计时，架构又扮演着什么样的角色呢？XP的批评者再一次地声称XP忽视架构，因为XP使用的方法是尽快地写程序，然后相信重构会解决所有设计的问题。很有趣地，他们说得没错，这有可能是XP的缺点。无疑地，最积极的XP专家－像KentBeck,RonJeffries,及BobMartin－尽其所能地避免预先结构性的设计。在你知道真的要用到数据库之前，不要加入数据库，先用档案来代替，在之后的阶段再用重构加入数据库。
我常被认为是一个胆小的XP专家，这点我不同意。我认为一个概括性的初始架构有它的用处在。像是一开始要怎么将应用分层，如何与数据库互动(如果你需要的话)，要使用哪种方式去处理网站服务器。
基本上，我认为这些就是近年来我们所研究的patterns。尤其当你对patterns的认识越深，你就会越熟悉要怎么去善用它们。不过，关键性的差异是在于这些初期架构的决定是可以更改的，只要团队认为他们早期的判断有误时，就应该要有勇气去修正它们。有人跟我讲了一个项目的故事，就在项目快要发表时，决定了不再需要EJB，并且要将它们从系统中移除。这是一个相当大规模的重构，不过最后还是完成了。这些有效的实务技巧不仅让事情变得可能，而且很值得去做。
如果以不同的方式来做这件事呢？如果你决定不采用EJB，将来会难以加入吗？你是否要在试过各种方式却发现依然欠缺什么，然后才使用EJB？这是一个牵涉很多因素的问题。不使用复杂的组件当然可以增加系统的简单度，而且可以让事情进展比较快，但有时候从系统中抽掉某个部份会比加入它要容易多了。
所以我建议从评估架构可能的样子开始。假如你看到将会有多个使用者使用到大量的资料，一开始就直接使用数据库。若你看到很复杂的商业逻辑，就套用domainmodel。你会怀疑是否偏离简单的特性，这当然不是YAGNI的精神。所以你要有所准备，在发现所使用的结构没有帮助时尽快简化你的结构。
UMLandXP
在我投身于XP领域之后，由于我与UML的关系让我遇到一个挥之不去最大的问题：这两者不是不兼容吗？
当然有些不兼容。XP显然不重视diagram。虽然台面上大家对"好用就用"有共识，但是实际上却是"实际上采用XP的人不画蓝图"。这种印象因为如Kent这些人不习惯作图的现象而强化了。事实上我也从来没看过Kent主动使用固定的标记法画下软件蓝图。
我觉得这种情形来自两个因素，其一是有人觉得软件蓝图有用，而有人不觉得有用。难就难在觉得蓝图有用的人不是真正必须动手做的人，而必须动手做的人却不觉得有其必要性。事实上我们应该接受有人喜欢用，而有人不喜欢用。
另一种情形是软件蓝图常引人进入繁重的流程中，这些流程耗时费力却不见得有用，甚至还会产生坏处。我认为应该教导人们如何使用蓝图却不落入这样的陷阱，而不是像那些提倡者仅仅消极的说"必要时才用"。
所以，我对于有效使用蓝图的建议是：
蓝图的用途是在开始撰写程序代码之前探讨设计内容。印象中总是觉得这样的动作在XP是不合法的，但并不是这样。很多人都说如果你遇到棘手的问题，就值得先做些设计。但是当你进行设计时：
保持简短。
不要做得太详细(只挑重要的做)。
把结果当作是草图，而不是定案。
最后一点值得深入探讨。当你做预先式设计，无可避免的会发现一些错误，而且是在撰写程序代码的时候才发现。如果你适时变更设计，它就不是问题。麻烦的是如果你认定设计已经定案，没有从coding过程学到经验而跟着先前的设计将错就错。
变更设计不代表一定要更改蓝图。画这些蓝图来帮助你了解设计，然后就把图扔开，这么做是非常合理的。这些图能够帮上忙就有它的价值了。它们不必永远存在，最有用的UML图形也不会是收藏品。
不少实行XP的人使用CRC卡，这与UML并不冲突。我常常交互运用CRC卡和UML，我也总是依照手上的工作选择最有用的技巧。UML图形的另一个用途是持续修订的文件。它一般的形式，就是在casetool中看到的模型。最初的想法是留着这样的资料有助于建构系统。事实上却常常没什么用。
它们隐含在CASEtool或thickbinder，让人忽略它。
所以要希望这种持续修订的文件有用，就从这些看到的问题下手：
只用一些改起来不至于让人觉得痛苦的图。
把图放在显眼的地方。我喜欢画在墙上，鼓励大家一起动手修改。
检讨这些图是不是有人在用，没用的就擦掉。
使用UML的最后一个问题是文件的交接，像是不同团队的接手。XP的想法是文件就像说故事，所以文件的价值由顾客来决定。于是UML又派上用场，所提供的图形可以帮助沟通。别忘了程序代码本身就蕴含了所有详细的信息，图形的作用只是提供概观以及标示重要的部份。
OnMetaphor
好吧，我也许该坦承-我一直没有抓住metaphor的精神。它有用，而且在C3项目中运用得很好，但是并不表示我知道怎么用它，更不用说要解释怎么用了。
XP实务技巧中的Metaphor是建立在WardCunningham's为系统命名的做法上。重点是想出一个众所周知的词汇，以这样一个字来比喻整个范畴。这个代表系统的名字会套用在class和method的命名上。
我以不同领域的观念性模型，利用UML和它的前身与领域专家一起建立了一个命名系统。我发现你必须很小心，你要保持最精简的注释，而且要当心别让技术性的问题不知不觉的影响这个模型。但是一旦你完成这个工作，你就可以为各种领域建立一组词汇，这些词汇是大家都能了解并且可用来与研发人员沟通的。这种模型无法与class设计完美的吻合，但是足够给整个领域一个通用的代名词。
目前我找不到任何理由说明为何这样的一个字汇无法成为一个比喻，就像C3这个成功的例子；我也不觉得以系统为主找到在该专业领域的一个词汇有什么坏处。同时我也不会放弃可以运作自如的为系统命名的技巧。
人们常批评XP乃是基于觉得一个系统实在是至少需要一个大概的设计。XP专家则以"就是metaphor啊！"来响应。但是我还是没有看到一个对于metaphor令人信服的解释。这是XP的缺憾，必须由XP专家来理出头绪。
DoyouwannabeanArchitectwhenyougrowup
对软件来说，architect一词可以代表很多事情。(软件界很多词都可以代表很多事。)这通常符合一句话：我不仅是一个程序员，我还是一个设计师[译注2]。还可以进一步解译成：我现在是一个设计师-我对于完成所有程序来说太重要了。然后这个问题就变成，当你要展现技术领导的时候，你是不是该把自己与烦琐的程序撰写分清楚？
这个问题引起众多的不满。我看到人们对于再也无法担任设计角色这样的想法感到生气。我最常听到：在XP没有设计师的挥洒空间。
就设计本身的角色来说，我不觉得XP不重视经验或好的设计。事实上多位XP的提倡者-KentBack、BobMartin、当然还有WardCunningham-都是我从而学习设计的对象。然而这也代表着他们的角色从大家既有的印象中开始转变成为技术领导者。
知道XP的人就能够了解我描述的是XP"教练"的清楚角色。的确，在XP玩的文字游戏中提到领导技术就是在描绘"教练"这个角色。其意义是很清楚的：在XP技术的领导特质是透过教导程序员和帮助他们做决定而呈现。这是一种需要良好人际管理和技术并重的技巧。JackBolles在XP2000说：孤单的大师有点机会了，合作和教导是成功的关键。
在研讨会的晚餐会上，我和Dave在谈话时对XP有了些对立的意见。当我们讨论到以前的经验，我们的方法有相当的类似。我们都偏好adaptive，iterativedevelopment，也认为测试是重要的。所以我们都对他反对的立场感到疑惑。然而他提到"最后我要的是程序员照着设计忙于重构"。事情一下子明朗起来。后来Dave又对我说"如果我不信任我的程序员，我何必要用他们呢？"，观念上的隔阂就更加清楚了。在XP里头，有经验的研发人员所能做的最重要的一件事就是尽量将所有技术传继给新手。不同于一个决定所有重要事情的建筑师，你有一个能够教导研发人员如何做重大决定的教练。就像WardCunningham指出，这么做不只是增进了新手的能力，对项目的好处更大于一个孤立无援的超人所能做的。[译注7]
Thingsthataredifficulttorefactorin
我们能用refactoring来处理所有设计方面的决定吗？或者，有些问题太普遍而且难以在将来加入设计中？此时，XP的正统做法是所有需求都可以轻易的在需要的时候增加，所以YAGNI总是能够适用。我猜是不是有例外？有一个不错的，被讨论到的例子是软件的国际化。这是不是一种现在应该立即进行，否则以后再加入时会觉得痛苦的事情？
有一部份能够为YAGNI辩护的理由是有些预先做的功能可能最后并不需要，或者它并不如预期的结果。不做这些所省下的力气比用refactoring来更改成为符合需要所用的力气要少。
SoisDesignDead
没什么原因，只是设计的本质已经改变。XP的设计追求以下的技巧：
持续保持清爽的程序代码，越简单越好。
重构的技巧，所以当你觉得必要的时候都可以有信心的动手。
具有patterns的知识：不只是照它的解法，更要感觉何时可以应用，或是如何导入patterns。
知道如何将设计说给必要的人了解[译注8]，用程序代码、或是图形、或上述所有的工具：交谈。
以上挑出来的技巧看来都挺吓人，但是要成为一个优秀的设计师本来就很难。XP也不是要让它变得简单，至少我就不觉得。但是我想XP让我们对有效率的设计有全新的看法，因为它让渐进式设计听起来是可行的方式。而且我也很支持演进-否则谁知道我会变成什么呢？
Acknowledgements[译注9]
过去这些年我从很多好朋友身上偷学到不少好的想法，很多都已经记不起来。但是我记得从JoshuaKerievski那里偷到的好东西。我也记得FredGeorge和RonJeffries给我很好的建议。我当然也不能忘记Ward和Kent不断有好的想法。
我也感谢曾经提出问题和指出打字错误的朋友。同时感谢CraigJones提醒我好几个漏掉的“a”。
RevisionHistory
2000年7月：原始文件在XP2000发表，并刊载于MartinFowler.com网页。
[译注1]一种在着手进行程序代码的撰写之前，就先按照既定的程序分析、设计、制图、撰写文件等等耗时费力的工作方式。
[译注2]在台湾你觉得“程序设计师”、“软件设计师”和“软件工程师”有什么不同吗？相信大部分的人觉得都是同一种角色。但是从英文字意就比较容易区别“programmer”、”designer”、”architect”等等不同的角色。这样的语言文化差异性，也是我在内文中留下不少原文的原因。在部份字句中，留下原文并不影响阅读的顺畅，但是可以避免文意因为翻译所造成的模糊或扭曲。
[译注3]在建筑业应该是称呼“施工人员”比较顺耳，而在软件业应该是“programmer”比较恰当。但是这两者都是“builder”。
[译注5]Story是一种类似usecase的描述。
[译注8]有效的沟通也是译者常遭遇的问题之一，有些人无法以不同的方式为事情下批注，有些人对于门外汉还是满口专业术语，有些人不能观察顾虑到听者是不是已经了解所阐述的精髓。这些都不是有效的沟通。我们似乎还不够重视人际沟通这门学问，如何以对方能懂的方式说给对方听，真是不容易呢！译者只是发出感叹，却也亟需要培养沟通能力，才不会让共事的同事摇头。