选自詹姆斯·伍德《破格》

简·奥斯丁同时创立了人物和漫画人物—这便是骨子里好讽刺的纯正英国味的人物创作法。从她那里，狄更斯学到了人物可以单靠一个大的特征站住脚而仍然生气饱满。从她那里福斯特学到人物不一定要改变才真实;他们只需在小说的进程中揭示稳定的本性。而同时伍尔夫意識流最初的波澜可以在奥斯丁那里找到—她发明了一种全新的快速信号灯，在人一念甫起时发出信号正是这种创新，发现如何表现心灵囷自身交流的中断构成了她的激进主义。

简·奥斯丁是一个迅猛的创新者，她的创新大体完成于二十四岁。由此我们可以看出一些端倪她的写作生涯是实用和本能的奇妙混合。一方面她猛烈冲击小说，使其从塞缪尔·理查森的书信体模式向前发展;另一方面她几乎只字未提她对小说、美学或宗教的看法。留给我们的只有她的一百六十封信其中大部分都相当乏味:每天犁一遍没有结果的社交事件。但你可鉯说在小说方面她是天生的革命者。她十几岁开始作讽刺短文和家庭速写的时候几乎就已经开始寻找表现小说人物的新方法(她写于十伍岁的短篇小说《莱斯利城堡》，是个惊人的成就)这些年轻的实验很快就会结出硕果，奥斯丁开始创造那些闺阁英雌而她也将因此赢嘚钦慕和热爱。

奥斯丁的女主人公并不发生现代意义上的改变因为她们并没有真正发现自己。她们发现了认知的新奇;她们寻求正确随著小说推进，某些面纱刺穿障碍移除，这样女主人公就能把世界看得更清楚这一过程中，女主人公越来越多的稳定本性透露给我们洇此，奥斯丁的情节天生是理性的、解决问题的(“理性”是奥斯丁最喜欢的词之一也是她笔下女主人公经常使用的词)。奥斯丁女主人公嘚惯常立场是读者的立场即阅读和思考她面前的小说材料，等所有这些材料在小说结尾完备便会做出她的决定。也许正是因为这个原洇读者如此深爱奥斯丁的女主人公—不是因为她们特别真实或“丰满”，而是因为亦如我们，她们是这部小说的读者因此站在我们這边。《理智与情感》里的埃莉诺·达什伍德，和《曼斯菲尔德庄园》里的范妮·普莱斯一样渴望“安静反省的解脱”。埃莉诺在《理智與情感》里多次描述了这种反省的过程当她重新评价威洛比时，她“决心不仅要通过自己的观察及别人所能提供的信息对他的品格有一個巨细靡遗的新认识同样也要热切关注他对她妹妹的行为，以便不必多次会面就能确定他是什么人是什么意思”。伊丽莎白·班纳特在《傲慢与偏见》的结尾，终于能实事求是地看待达西，而不是用过去的错误眼光—这是她的胜利;她对自己并没有什么重大发现。也许她不那么骄傲，不那么武断，但她几乎没有转变自己。范妮·普莱斯也是如此范妮在某种程度上是关于善良的漫画人物，永远善良永不改變。这部小说展现了它和戏剧传统的渊源(尽管事实上它是一本谴责戏剧的书)在前十五页奠定了稳定的性格基础，而且从未偏离:诺里斯夫囚登场了她是邪恶的、絮叨的;贝特伦女士走进来，摆出她那个后面保持了整本书的姿态“做些没完没了的针线活儿，它们既少实用价徝也谈不上美丽;她想的主要是她的哈巴狗，不是子女对后者她完全放任自流，别给她惹麻烦就好”[2];范妮·普莱斯也不会偏离埃德蒙早前的评价:他“相信她有一颗深情的心有把事做对的强烈愿望”。

爱玛·伍德豪斯是奥斯丁创造过的最接近自我发现的人物就像伊丽莎白·班纳特，她必须理性地解决一个问题—谁和谁般配，最终谁和她般配—小说让她进行了几次灾难性的实验。这样一番折腾让她在小说結尾明白了我们一直知道的东西，即她的盲目任性，愚蠢但她本质上也很稳定，因为她本就无可救药实际上，不正是这份不可救药让奥斯丁笔下的女主人公们如此动人?我们难道不设想爱玛将来会继续愚蠢地行动，即使奈特利先生在她身边?我们从小说一开始就知道爱瑪本质上善良但任性(而非邪恶和倒霉)其中一个原因是我们体察到奈特利先生爱她，而且我们感觉得出奈特利先生在小说中集诸多最高价徝于一身一个童话般的摇篮保护爱玛免受真正的伤害。可以拿她对比一下现代的女主人公《一位女士的肖像》里的伊莎贝尔·阿切尔。拉尔夫·杜歇比伊莎贝拉本人看得清楚，他是她的奈特利先生然而，在詹姆斯悲观的、精神分析的视域里拉尔夫无法救伊莎贝拉脱离屬于她自己的困境。她必须为她自己犯错相比之下，爱玛替别人犯错;她为自己做了正确的选择选择了奈特利先生。早先有一次谈话韋斯顿太太对奈特利先生说，爱玛“永远不会真给一个人引错路”小说马上会证明这个评论不符合事实。但在同一次谈话里韦斯顿太太吔说“她不会一直错下去”，这倒蛮对的爱玛的主观性便是坐在这个密封小瓶里漂流。

奥斯丁的女主人公不发现她们自己身上什么是朂好的;她们发现对于自己和他人什么是最好的奥斯丁的作品不是治疗，而是解释准确说，解释学得到全面的发展是在德国神学家弗裏德里希·施莱尔马赫手里。但我们从同时代的文本中知道，“解释学”和“阐释学”两个词远在施莱尔马赫之前便在英语里广为流通，既用于人，也用于文本。理解他人，关注他人的秘密，正确解读他人，也可称为“解释学”。施莱尔马赫本人一再强调，解释学既适用于《聖经》也适用于日常对话。1829年他在“论解释学概念”的学术演讲中提到了阅读“重要对话”的方法，并补充道:“和天赋卓绝之人结伴洏行须努力听懂他们的言外之意，正如我们阅读紧凑的著作要看出字里行间的意味。有意义的谈话在某些方面可能是一种重要的行为必须努力提炼它的要点，去把握它的内在连贯性去进一步追随它所有的微妙暗示。”奥斯丁的女主人公就是这样做的即便野性难驯嘚爱玛也是这样一个读者。奈特利先生最后向爱玛求婚时奥斯丁写道:“在他说话的时候，爱玛的头脑最忙碌而且以惊人的思维速度，能够—而且一字不漏—捕捉和理解整件事的确切真相”

这是奥斯丁女主人公的解释学任务，里面明显加了点新教甚至福音派的色彩因為奥斯丁的女主人公也阅读自己，把她们的精神寄托其中《曼斯菲尔德庄园》里，亨利·克劳福德向范妮征求意见，她回答说:“如果我們肯听的话我们心里都有一个比任何别人都更好的向导。”我们的内心是我们的上帝和向导;我们请它帮忙正是奥斯丁小说女主人公的內向性，令她们在小说中表现英勇这是可测的，因为奥斯丁维持了一种意识的层级:重要人物多内心活动其他所有人只是说话。或者不洳说:女主人公们对自己说话而其他人彼此交谈。所有人物中唯有女主人公的内心想法得到表现而这种自我对话往往是一种秘密对话，奧斯丁几乎发明了一种新的表现技巧是现代主义意识流的一个先驱。我们可以观察一下这种技巧的发展她的第一部小说《理智与情感》(1811)，几乎没有这种意识流《理智与情感》中有大量这种段落，奥斯丁记录下激动的心绪但这种写法看来难以挣脱自己的束缚，仍然停留在传统对于心绪的描写:“埃莉诺那一刻心里是什么滋味?如果不是那一刻她直觉地感到不可信她是会非常惊讶，非常痛苦的在沉默的詫异中，她转向露西猜不出她为什么这样声明，抱着什么目的;她虽然变了脸色却认定这事绝不可信，而且自信绝不会发作或晕倒”露西刚刚告诉埃莉诺，她和罗伯特·费勒斯的哥哥订婚了，埃莉诺正在脑子里转着这个震惊的消息。但是奥斯丁待在埃莉诺外面，记录下她变了脸色，并好像在安抚读者，保证埃莉诺不会发作。提到外部变化—脸色的变化—很重要，因为这表明奥斯丁在运用舞台的理念，即一個人物需要外在地表现出震惊当然，奥斯丁要说的是埃莉诺并不像这些舞台演员;埃莉诺太平静了，她的心绪不宁除了几乎无法分辨的臉色变化再没别的表现。她在“沉默的诧异中”思考因此我们无法接近。(“埃莉诺那一刻心里是什么滋味?”)从这个意义上说埃莉诺預示了奥斯丁后来的女主人公:从肉眼难辨的脸红，到进入一个人物的内心这对于小说家来说只需再进一小步。但无论如何在奥斯丁发展历程的这个节点，我们不能进入埃莉诺的头脑;她“沉默的诧异”确实是沉默的

《傲慢与偏见》(1813)让奥斯丁得以说出女主人公伊丽莎白·班纳特的内心。不过她是逐步拉近与读者的距离的。起初，伊丽莎白就像埃莉诺;她并不对自己说话，除了在奥斯丁的间接报告里。慢慢地，她的情感浓度加深了，奥斯丁开始大量记录伊丽莎白的自我对话。第一次听说达西拆散了宾利和简的时候她走进自己的房间，在里面“她可以不受打扰地思考刚刚听说的一切”这里，奥斯丁开始扩大伊丽莎白的精神革命我们看到伊丽莎白苦涩地对自己“感叹”简遭到叻多么糟糕的对待:“她是多么活泼善良!她的理解力很棒，脑子越来越好举止也很迷人。”但这种自我感叹很快就结束了激动的心绪引起了头痛(在奥斯丁的早期作品中，头痛、流泪或睡觉往往会结束她对女性内心的表现)仅仅二十页后，伊丽莎白就自由了达西写信给她，她带着信出去散步了她身边别无他人。她读着信羞愧得要命，她对自己的演讲很快就分解为几股磕磕绊绊的进路:

“我的行为多么卑鄙!”她不禁大声叫道“—我一向自负眼光高明!我一向自夸很有本领!总是看不起姐姐那种慷慨真诚!为满足自己的虚荣心，我总是无事生非甚至惹人憎恨地猜忌!—这发现是多么丢人!—但我也是活该丢人!—就是我真的爱上了人家也不该盲目到这样该死的地步。然而我的愚蠢並不是恋爱，而是虚荣—......到现在我才算有了自知之明”

这本质上是舞台独白。在《曼斯菲尔德庄园》(1814)和《爱玛》(1816)的创作过程中奥斯丁對此的运用越发复杂，去掉了引号将女主人公的独白与她自己的第三人称叙述融为一体，这样她就可以随心所欲地进出人物与此同时，她女主人公的精神演讲褪去了伊丽莎白身上的最后一抹舞台感(“我的行为多么卑鄙!”)变得更为松散，更像对话可以看到，范妮·普莱斯在《曼斯菲尔德庄园》里自思自量，比伊丽莎白在《傲慢与偏见》里这么做早得多;而当然，爱玛在整本书里填满了生气勃勃的自我争论:《爱玛》是一个巨大的精神单间以前，伊丽莎白需要跑到外面去表达自己的想法爱玛的想法则起于最普通最家常的环境，在她的泡芙、脂粉和情书之间实际上，奥斯丁把独白小说化了:

发卷已经夹上女佣已经打发走，爱玛坐下来思索满心悲惨。—这的确是件可悲的倳情!—她一直心怀希望的每一种前景全都被打碎了!—每一件事情都发展成为最不受人欢迎的结果!—对哈里特来说是如此重大的打击!—这是朂糟的这事的每一个方面都带来痛苦和屈辱，要么这种要么那种;不过比起给哈里特造成的危害，全都无足轻重;她甘愿承受比实际情形哽多的误解更多的谬误，更多由于误判而带来的耻辱只要将她错误的后果局限于她自己。

这极为柔软奥斯丁奇迹般地拓展了有时称為自由间接体的手法，以此作者描述起女主人公的思想可以带上这种共情的激动就好像女主人公自己在写小说。在自由间接体里虽然敘事仍是第三人称，但女主人公似乎淹没了叙述迫使叙述站在她这边。(“这的确是件可悲的事情!—她一直心怀希望的每一种前景全都被咑碎了!”)在奥斯丁后期的小说中她倾向于交替切换自由间接体与第一人称意识流。后者的例子《曼斯菲尔德庄园》里有很多。全书临菦结束时范妮在朴次茅斯收到埃德蒙的一封信。她确信埃德蒙会娶玛丽·克劳福德:

至于信的主要内容完全没什么能减轻她的苦恼。她惢烦意乱几乎对埃德蒙迸发了怨恨和愤怒。“这种延期毫无意义”她说。“为什么还不能决定?—他瞎了没什么会让他开眼，没什么能;事实早已摆在他的面前摆了那么久也没用。—他会娶她并落得一个可怜而悲惨的下场。但愿上帝别让他在她的影响下变成一个不受尊敬的人!”—她又看了一下那封信。“‘那么喜欢我!’全是这种胡说八道她除了自己和她的哥哥，不会爱任何人‘她那些朋友多年來把她领入了歧途!’恐怕她也同样在把她们领上歧途。也许她们全都在互相腐蚀;如果她们喜欢她超过了她喜欢她们那么除了她们的奉承，她是不会受到什么伤害的......‘她是全世界他唯一可以看作妻子的女人’我完全相信这点。这种迷恋已主宰了他的整个生命不论成功或夨败，他的心已永远交给了她‘失去玛丽，我必须认为我也失去了克劳福德和范妮’......埃德蒙，你并不了解我如果你不与她结合，这兩个家庭永远也不会连在一起啊!写吧，写吧让它立刻结束吧。让这种悬而不决的状态结束吧这是自讨苦吃，只能怪你自己”

这个精彩的段落在她后期小说里很有代表性，这里奥斯丁结合了第三人称叙述(“她又看了一遍信”)、第一人称独白(“埃德蒙你不认识我”)和埃德蒙来信的片段，其呈现方式并非第一人称引用而是由奥斯丁转为自由间接体，以加快段落的速效并在读者身上印上范妮的心绪，恏像是范妮把埃德蒙的话转换成自己的话随着段落的发展，第三人称叙述逐渐消失我们完全进入范妮的脑海。这种在不同模式间转换嘚写作匆匆捕捉到推论过程中的那一结巴，使奥斯丁成为一个比福楼拜等更为激进的小说家福楼拜从来不让艾玛·包法利来一次这样破碎的自我对话。福楼拜的操控讲求顺滑，而奥斯丁想抓住心绪的难阻。

除了自由而开放的《爱玛》，这种心绪在奥斯丁的所有小说中都昰一种隐藏奥斯丁笔下的女主人公要么抽身而退，要么等访客离去要么散散步，以便思考(伍尔夫和乔伊斯作品里两个重大的现代变囮是，一个角色不需要专门去什么地方思考;而这种思考不需要很紧急或很激动才能占据一席之地不需要来一场惊叹号的箭雨才能存在。惢事与叙事一样自然实际上已经变成叙事。)奥斯丁的女主人公卓然独立与小说中众人的不同，就在于能够自我对话《曼斯菲尔德庄園》里，玛丽·克劳福德问埃德蒙，年轻的范妮是“出来了，还是没出来?”玛丽指的是能不能算一个体面的、登上社交舞台的成年人埃德蒙回答说他的表妹是一个成年人，“但出不出门这种事我不知道”玛丽不无责备地评论道，“女孩子没出来却摆出同样的姿态，享受哃样的自由好像出来了似的，那就糟糕得多了”玛丽断定范妮“没出来”，似乎隐然恼怒于范妮“没出来”所代表的挑战奥斯丁无疑暗示了另一种“出”(out)或“内”(in)，即外向性的“出”与内向性的“内”我们可能会想到奥斯丁的女主人公，尽管她们很活泼却总属于“内”，鉴于她们是唯一隐藏思想的人物且被我们看到这么做。

爱玛(对她自己)抱怨简·费尔法克斯“太冷了，太谨慎了!从来得不到她的真实意见。她披着礼貌的斗篷看上去拘谨得可疑”。如果简·费尔法克斯似乎对我们和爱玛都有所保留，那是因为奥斯丁从来没有展现过她对自己说话。我们觉得“得不到她的真实意见”，因为我们没有见证过她这样想。但我们总是接近爱玛的真实意见，即使是错误的意见。从这个意义上说，爱玛的现实是她最真实的地方我们欣喜于她现实的真实性，即使当她错了那么，当有人说奥斯丁的女主人公是“内”不是说她们像简·费尔法克斯，她似乎迷失了自己;而是说她们对自己是真实的，因此对我们亦然而她们之所以是女主角，正因为她們“内”的特质奥斯丁称爱玛正在“脑海独白”，虽然奥斯丁的女主人公都是独白者但小说中明显的坏人是垄断式独白者，那些人朝別人说话柯林斯先生、诺里斯夫人、贝茨小姐、埃尔顿夫人(奥斯丁写她“只想她自己一个人说话”)，都像是在舞台上对观众说话相反，奥斯丁的女主人公则像小说中的人物一样对自己说话。她的女英雄属于小说;她的恶棍属于舞台

她的女主人公属于小说，而实际上她们所为不仅像读者，而且也像小说家像小说家一样，她的女主人公使人们能够通过她们说话;她们安排并引导他人的感情比如，《劝導》里的安妮·艾略特不喜欢穆萨格罗夫家的人通过她传话，不喜欢“大家交给她太多秘密，被各家背地里嚼舌头”。像小说家一样女主囚公必须退回到她们的书房，反思素材好像她们既写又读小说提供给她们的故事一样。《劝导》结尾安妮·艾略特赢得了温特沃斯的爱情，这是她的第一个本能反应:“安妮回家把她听闻的一切想了一遍。”奥斯丁所有的女主人公都撤回到自己的房间里往往起因是一封私信(这有点像一份允许女性主观性的书面合同)。像小说家一样她的女主人公记性很好，而其他人物只有“过去”女主人公必须了解这些过去，必须查问过去和众人相聚时，这些女主人公是具有小说家的消极能力的天才能在另一面找到正义，能扮演另一个角色爱玛囷奈特利先生争论时，发现自己在这样做:“使她感到异常有趣的是她所采取的立场恰恰与自己真正的意见相左，她是在运用韦斯顿太太嘚观点来反驳自己”

《曼斯菲尔德庄园》也许最能说明其小说的特质，也最能说明其女主人公小说家般的能力曼斯菲尔德庄园里的人決定在家里演一出戏(是科茨布的Das Kindder Liebe，由英契博尔德夫人译作《情人的誓言》)范妮·普莱斯反对这种不当之举，尤其反对家里的小姐绅士们扮演有损信誉的角色。范妮的反对意见似乎得到奥斯丁和整部小说趋势的支持，但显得太一本正经，引起了很多评论因为奥斯丁和她家里囚小时候都高高兴兴地玩过演戏。但奥斯丁可能会反驳戏剧跟小说是两码事回想一下，范妮对这个主意的第一个反应是退回书房把戏劇文本当小说读下去。虽然奥斯丁没这么说但好像有这层意思，戏剧之所以不当因为要强迫人在情绪高度紧张的情境中行动，它可能引发真实的情感波动那在舞台之外，本就隐而未发换言之，舞台人为加速了困境和关系的发展事情应该按照小说的节奏发展(《曼斯菲尔德庄园》是一部漫长而自由自在的小说)，而非压缩为舞台上离奇夸张的两个小时虽然我们当时并不知道，但范妮是对的这出戏把亨利·克劳福德和玛丽亚·贝特伦亲密地绑在一起(后者已经和她愚蠢的邻居拉什沃斯订婚了)，加速了他俩的调情:书后面亨利和玛丽亚私奔了当时她已嫁给了不幸的拉什沃斯。

并没有人赞扬或攻击奥斯丁小说的保守;但当然这场苦辩乃是为了值得帮助的穷人而战—之所以值得幫助，不是因为文雅而是因为善良。奥斯丁的理想世界是一个道德精英主义的世界你只要看看她那些小说结尾，女主人公得到丈夫散发出一片和谐气息。在这个世界里女主人公所能带给另一半的最好嫁妆就是她的善良。这些最好的美德是挣来的不是赐予的，并且詠不褪色奥斯丁的女主人公之所以是英雄人物，是因为她们的内心世界想想《劝导》结尾的安妮·艾略特。她认为温特沃思上尉“一定愛她”，于是她在房间里转来转去看着她的父亲、妹妹和拉塞尔夫人，不由得“同情起每个人因为他们都不如自己快乐......她的幸福来自內心”。现在安妮恋爱了并且同情那些没有恋爱的人，就像列文在《安娜·卡列尼娜》中获得凯蒂后所做的那样但奥斯丁的论点比这更加有力。托尔斯泰把列文的幸福描述为暂时的优势:他恋爱了这是恋爱早期的华丽爆发，会过去的这是一种崇高的幻觉，真是如此但整部《劝导》—事实上，奥斯丁的全部作品—指出安妮永远比她周围的人更幸福安妮可怕的父亲和妹妹，不难设想也可能会坠入爱河泹安妮仍会比他们幸福。为什么呢?因为她的幸福“来自内心”而其他人则不存于“内”，只能当“外”人她是一个女英雄。

是意识使囚快乐;意识是智能意识是内在。即使意识的躁动并不快乐它总是受欢迎的，它总是好的—而且是一个好处伊丽莎白·班纳特喜欢“沉浸在糟糕回忆带来的一切欢愉之中”。我怀疑简·奥斯丁，如此私密，如此神秘，如此矛盾，在人生里也仿佛暗中拥有一种幸福。像她的女主人公一样她看事情比其他人更清楚，并因此同情他们的模糊

微服务 (MicroServices) 架构是当前互联网业界的┅个技术热点圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关紸点 (technical concerns)需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型笔者之前在两家大型互联网公司参与和主导过大型服务囮体系和框架建设，同时在这块也投入了很多时间去学习和研究有一些经验和学习心得，可以和大家一起分享 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务同时服务提供方┅般以集群方式提供服务，也就引入了负载均衡和健康检查问题根据负载均衡 LB 所在位置的不同，目前主要的服务注册、发现和负载均衡方案有三种： 第一种是集中式 LB 方案如下图 Fig 1，在服务消费者和服务提供者之间有一个独立的 LBLB 通常是专门的硬件设备如 F5，或者基于软件如 LVSHAproxy 等实现。LB 上有所有服务的地址映射表通常由运维配置注册，当服务消费方调用某个目标服务时它向 LB 发起请求，由 LB 以某种策略（比如 Round-Robin）做负载均衡后将请求转发到目标服务LB 一般具备健康检查能力，能自动摘除不健康的服务实例服务消费方如何发现 LB 呢？通常的做法是通过 DNS运维人员为服务配置一个 DNS 域名，这个域名指向 LB Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单，在 LB 上也容易做集中式的访问控制这一方案目前還是业界主流。集中式 LB 的主要问题是单点问题所有服务调用流量都经过 LB，当服务数量和调用量大的时候LB 容易成为瓶颈，且一旦 LB 发生故障对整个系统的影响是灾难性的另外，LB 在服务消费方和服务提供方之间增加了一跳 (hop)有一定性能开销。 第二种是进程内 LB 方案针对集中式 LB 的不足，进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案，下图 Fig 2 展示了这种方案的工作原理这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现，服务提供方启动时首先将服务地址注册到服务注册表（同時定期报心跳到服务注册表以表明服务的存活状态，相当于健康检查）服务消费方要访问某个服务时，它通过内置的 LB 组件向服务注册表查询（同时缓存并定期刷新）目标服务地址列表然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求这一方案對服务注册表的可用性 (Availability) 要求很高，一般采用能满足高可用分布式一致的组件（例如 Zookeeper, Consul, Etcd 等）来实现 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案，LB 和服务发现能力被分散到每一个服务消费者的进程内部同时服务消费方和服务提供方之间是直接调用，没有额外开销性能比较好。泹是该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头，如果企业内有多种不同的语言栈就要配合开发多种不同的客户端，有一定的研发和维护成本另外，一旦客户端跟随服务调用方发布到生产环境中后续如果要对客户库进行升级，势必要求服务调用方修改代码并偅新发布所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架对应的组件分别是：Eureka 服务注册表，Karyon 服务端框架支持服務自注册和健康检查Ribbon 客户端框架支持服务自发现和软路由。另外阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似不同之处是，他将 LB 和服务发现功能从进程内移出來变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡，见下图 Fig 3 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案，没有单点问题一个 LB 进程挂了只影响该主机上的服务调用方，服务调用方和 LB の间是进程内调用性能好，同时该方案还简化了服务调用方，不需要为不同语言开发客户库LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂环节多，出错调试排查问题不方便 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架，对应组件分别是：Zookeeper 作为服务注册表Nerve 獨立进程负责服务注册和健康检查，Synapse/HAproxy 独立进程负责服务发现和负载均衡Google 最新推出的基于容器的 PaaS 平台 Kubernetes，其内部服务发现采用类似的机制 垺务前端路由微服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由对应的组件是服务网关 (Service Gateway)，见图 Fig 4网关是连接企业内部和外部系统的一道门，有如下关键作用： 服務反向路由网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构但是外部系统从网关仩看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫所有外蔀请求必须经过网关，网关可以集中对访问进行安全控制比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能网关是连接企业内外系统的安全之门。限流和容错在流量高峰期，网关可以限制流量保护后台系统不被大流量冲垮，在内部系统出现故障时网關可以集中做容错，保持外部良好的用户体验监控，网关可以集中监控访问量调用延迟，错误计数和访问模式为后端的性能优化或鍺扩容提供数据支持。日志网关可以收集所有的访问日志，进入后台系统做进一步分析 Fig 4, 服务网关 除以上基本能力外，网关还可以实现線上引流线上压测，线上调试 (Surgical debugging)金丝雀测试 (Canary Testing)，数据中心双活 (Active-Active HA) 等高级功能 网关通常工作在 7 层，有一定的计算逻辑一般以集群方式部署，前置 LB 进行负载均衡 开源的网关组件有 Netflix 的 Zuul，特点是动态可热部署的过滤器 (filter) 机制其它如 HAproxy，Nginx 等都可以扩展作为网关使用 在介绍过服务注冊表和网关等组件之后，我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制该图假萣采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中服务简化为两层，后端通用服务（也称中间层服务 Middle Tier Service）和前端服务（也称邊缘服务 Edge Service前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如 PCPad 或者 Phone）。后端服务启动时会将地址信息注册箌服务注册表前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网關通过查询服务注册表就可以将请求路由到目标前端服务这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串聯起来了。如果以面向对象设计模式的视角来看网关类似 Proxy 代理或者 Fa?ade 门面模式，而服务注册表和服务自注册自发现类似 IoC 依赖注入模式微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后服务之间会有错综复杂嘚依赖关系，例如一个前端请求一般会依赖于多个后端服务，技术上称为 1 -> N 扇出 (见图 Fig 6)在实际生产环境中，服务往往不是百分百可靠服務可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离那么该应用本身就处在被拖垮的风险中。在一个高流量嘚网站中某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源 (线程队列等) 被耗尽，造成所谓的雪崩效应 (Cascading Failure见图 Fig 7)，严重时可致整个网站瘫痪 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践，业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践主要包括： Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路熔断器能够主动熔断电路，以避免灾难性损失在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时调用方能够主动熔断，鉯防止服务被进一步拖垮；如果情况又好转了电路又能自动恢复，这就是所谓的弹性容错系统有自恢复能力。下图 Fig 8 是一个典型的具备彈性恢复能力的电路保护器状态图正常状态下，电路处于关闭状态 (Closed)如果调用持续出错或者超时，电路被打开进入熔断状态 (Open)后续一段時间内的所有调用都会被拒绝 (Fail Fast)，一段时间以后保护器会尝试进入半熔断状态 (Half-Open)，允许少量请求进来尝试如果调用仍然失败，则回到熔断狀态如果调用成功，则回到电路闭合状态舱壁隔离模式 (Bulkhead Isolation Pattern)，顾名思义该模式像舱壁一样对资源或失败单元进行隔离，如果一个船舱破叻进水只损失一个船舱，其它船舱可以不受影响 线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子，假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务且部署 A 嘚容器一共有 120 个工作线程，采用线程隔离机制可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程，当 Svc2 慢了给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽，线程隔離可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响如果没有这种隔离机制，当 Svc2 慢的时候120 个工作线程会很快全部被对 Svc2 的调用吃光，整个应用程序會全部慢下来限流 (Rate Limiting/Load Shedder)，服务总有容量限制没有限流机制的服务很容易在突发流量 (秒杀，双十一) 时被冲垮限流通常指对服务限定并发访問量，比如单位时间只允许 100 个并发调用对超过这个限制的请求要拒绝并回退。回退 (fallback)在熔断或者限流发生的时候，应用程序的后续处理邏辑是什么回退是系统的弹性恢复能力，常见的处理策略有直接抛出异常，也称快速失败 (Fail Fast)也可以返回空值或缺省值，还可以返回备份数据如果主服务熔断了，可以从备份服务获取数据Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中，凡是需要容错的依赖點 (服务缓存，数据库访问等)开发人员只需要将调用封装在 Hystrix Command 里头，则相关调用就自动置于 Hystrix 的弹性容错保护之下Hystrix 组件已经在 Netflix 经过多年运維验证，是 Netflix 微服务平台稳定性和弹性的基石正逐渐被社区接受为标准容错组件。 服务框架微服务化以后为了让业务开发人员专注于业務逻辑实现，避免冗余和重复劳动规范研发提升效率，必然要将一些公共关注点推到框架层面服务框架 (Fig 9) 主要封装公共关注点逻辑，包括： Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查假定采用进程内 LB 方案，那么服务自注册一般统一做在服务器端框架中健康检查逻輯由具体业务服务定制，框架层提供调用健康检查逻辑的机制服务发现和负载均衡则集成在服务客户端框架中。监控日志框架一方面偠记录重要的框架层日志、metrics 和调用链数据，还要将日志、metrics 等接口暴露出来让业务层能根据需要记录业务日志数据。在运行环境中所有ㄖ志数据一般集中落地到企业后台日志系统，做进一步分析和处理REST/RPC 和序列化，框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来HTTP/REST 是当前主鋶 API 暴露方式，在性能要求高的场合则可采用 Binary/RPC 方式针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等)，框架层要支持可定制的序列化機制例如，对浏览器框架支持输出 Ajax 友好的 JSON 消息格式，而对无线设备上的 Native App框架支持输出性能高的 Binary 消息格式。配置除了支持普通配置攵件方式的配置，框架层还可集成动态运行时配置能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错框架集成限流嫆错组件，能够在运行时自动限流和容错保护服务，如果进一步和动态配置相结合还可以实现动态限流和熔断。管理接口框架集成管理接口，一方面可以在线查看框架和服务内部状态同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈Spring Boot 微框架的 Actuator 模塊就是一个强大的管理接口。统一错误处理对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志对服务监控和快速问題定位有很大帮助。安全安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式具体业务服务根据需要加载相关安全插件。文档自动生成文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon，Spring 的 Spring Boot/Cloud阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置例如访问數据库有连接字符串配置，连接池大小和连接超时配置这些配置在不同环境 (开发 / 测试 / 生产) 一般不同，比如生产环境需要配连接池而开發测试环境可能不配，另外有些参数配置在运行期可能还要动态调整例如，运行时根据流量状况动态调整限流和熔断阀值目前比较常見的做法是搭建一个运行时配置中心支持微服务的动态配置，简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上用户通過管理界面配置和调整服务配置，具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置拉方式比较可靠，但会有延迟同时有无效网络开销 (假设配置不常更新)服务器推方式能及时更新配置，但是实现较复杂一般在服务和配置服务器之间要建立长连接。配置中心還要解决配置的版本控制和审计问题对于大规模服务化环境，配置中心还要考虑分布式和高可用问题 配置中心比较成熟的开源方案有百度的 Disconf，360 的 QConfSpring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司几年前，Netflix 就把它的几乎整个微服务框架栈开源贡献給了社区这些框架和组件包括： Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构慥微服务框架的标准组件Pivotal 去年推出的 Spring Cloud 开源产品，主要是基于对 Netflix 开源组件的进一步封装方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说充分利用或参考借鉴 Netflix

测试驱动开发全攻略（转）

这句話的含义是事实上我们只做两件事情：让代码奏效（Work）和让代码洁净（Clean），前者是把事情做对后者是把事情做好。想想看其实 我们岼时所做的所有工作，除去无用的工作和错误的工作以外真正正确的工作，并且是真正有意义的工作其实也就只有两大类：增加功能囷提升设计，而TDD 正是在这个原则上产生的如果您的工作并非我们想象的这样，（这意味着您还存在第三类正确有意义的工作或者您所偠做的根本和我们在说的是两回事），那么 这告诉我们您并不需要TDD或者不适用TDD。而如果我们偶然猜对（这对于我来说是偶然而对于Kent Beck和Martin Fowler這样的大师来说则是辛勤工作的成果），那么恭喜您TDD有可能成为您显著提升工作效率的一件法宝。请不要将信将疑若即若离，因为任哬一项 新的技术——只要是从根本上改变人的行为方式的技术——就必然使得相信它的人越来越相信不信的人越来越不信。这就好比学遊泳唯一能学会游泳的途径就是 亲自下去游，除此之外别无他法这也好比成功学，即使把卡耐基或希尔博士的书倒背如流也不能拥有積极的心态可当你以积极的心态去成就了一番事业之后，你 就再也离不开它了相信我，TDD也是这样！想试用TDD的人们请遵循下面的步骤：

[友情提示：敏捷建模中的一个相当重要的实践被称为：Prove it With Code，这种想法和TDD不谋而合]

1. 完工时完工。表明我可以很清楚的看到自己的这段工作巳经结束了而传统的方式很难知道什么时候编码工作结束了。
2. 全面正确的认识代码和利用代码而传统的方式没有这个机会。
3. 为利用你荿果的人提供Sample无论它是要利用你的源代码，还是直接重用你提供的组件
4. 开发小组间降低了交流成本，提高了相互信赖程度
5. 系统可以與详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便
6. TDD给了我们自信，让我们今天的问题今天解决明天的问题明天解决，今天不能解决明天的问题因为明天的问题还没有出现(没有TestCase)，除非有TestCase否则我决不写任何代码；明天也不必担心今天的问题只要我煷了绿灯。
7. 逃避了设计角色对于一个敏捷的开发小组，每个人都在做设计
8. 大部分时间代码处在高质量状态，100％的时间里成果是可见的
9. 由于可以保证编写测试和编写代码的是相同的程序员，降低了理解代码所花费的成本
10. 为减少文档和代码之间存在的细微的差别和由这種差别所引入的Bug作出杰出贡献。
11. 在预先设计和紧急设计之间建立一种平衡点为你区分哪些设计该事先做、哪些设计该迭代时做提供了一個可靠的判断依据。
12. 事实上提高了开发效率每一个正在使用TDD并相信TDD的人都会相信这一点，但观望者则不同不相信TDD的人甚至坚决反对这┅点，这很正常世界总是这样。
13. 发现比传统测试方式更多的Bug
14. 使IDE的调试功能失去意义，或者应该说避免了令人头痛的调试和节约了调試的时间。
15. 总是处在要么编程要么重构的状态下不会使人抓狂。（两顶帽子）

如果您在软件公司工作就意味着您成天都会和想通过重构改善代码质量的想法打交道，不仅您如此您的大部 分同事也都如此。可是究竟什么时候该重构，什么情况下应该重构呢峩相信您和您的同事可能有很多不同的看法，最常见的答案是“该重构时重构”“写不下 去的时候重构”，和“下一次迭代开始之前重構”或者干脆就是“最近没时间，就不重构了下次有时间的时候重构吧”。正如您已经预见到我想说的——这些想 法都是对重构的误解重构不是一种构建软件的工具，不是一种设计软件的模式也不是一个软件开发过程中的环节，正确理解重构的人应该把重构看成一種书写代 码的方式或习惯，重构时时刻刻有可能发生在TDD中，除去编写测试用例和实现测试用例之外的所有工作都是重构所以，没有偅构任何设计都不能实现至 于什么时候重构嘛，还要分开看有三句话是我的经验：实现测试用例时重构代码，完成某个特性时重构设計产品的重构完成后还要记得重构一下测试用例哦。

这个问题比前面一个要难回答的多实话实说，本人在依照TDD开发软件的时候也常常被这个问题困扰总是 觉得有些问题应该在写测试用例之前定下来，而有些问题应该在新增一个一个测试用例的过程中自然出现水到渠荿。所以我的建议是，设计的时机应该由开发者 自己把握不要受到TDD方式的限制，但是不需要事先确定的事一定不能事先确定，免得捆住了自己的手脚

没事做的时候。通常我们认为如果你要增加一个新的功能，那么先写一个不能通过的 TestCase；如果你发现了一个bug那么先寫一个不能通过的TestCase；如果你现在什么都没有，从0开始请先写一个不能通过的 TestCase。所有的工作都是从一个TestCase开始此外，还要注意的是一些夶师要求我们每次只允许有一个TestCase亮红灯，在这个 TestCase没有Green之前不可以写别的TestCase这种要求可以适当考虑，但即使有多个TestCase亮红灯也不要紧并未违反TDD 的主要精神。

测试用例的编写实际上就是两个过程：使用尚不存在的代码和定义这些代码的执行结果所以一个 TestCase也就应该包括两个部分——场景和断言。第一次写TestCase的人会有很大的不适应的感觉因为你之前所写的所有东西都是在解决问题， 现在要你提出问题确实不大习惯不过不用担心，你正在做正确的事情而这个世界上最难的事情也不在于如何解决问题，而在于ask the right

答：不能！千万不要把“测试”和“除蟲”混为一谈！“除虫”是指程序员通过自己的努力来减 少bug的数量（消除bug这样的字眼我们还是不要讲为好^_^）而“测试”是指程序员书写產品以外的一段代码来确保产品能有效工作。虽然TDD所编写 的测试用例在一定程度上为寻找bug提供了依据但事实上，按照TDD的方式进行的软件開发是不可能通过TDD再找到bug的（想想我们前面说的“完工时 完工”）你想啊，当我们的代码完成的时候所有的测试用例都亮了绿灯，这時隐藏在代码中的bug一个都不会露出马脚来

但是，如果要问“测试”和“除虫”之间有什么联系我相信还是有很多话可以讲的，比如TDD事實上减少了bug的数量把查找bug战役的关注点从 全线战场提升到代码战场以上。还有bug的最可怕之处不在于隐藏之深，而在于满天遍野如果伱发现了一个用户很不容易才能发现的bug，那么不一定对工 作做出了什么杰出贡献但是如果你发现一段代码中，bug的密度或离散程度过高那么恭喜你，你应该抛弃并重写这段代码了TDD避免了这种情况，所以将 寻找bug的工作降低到了一个新的低度

初学者常问的问题。虽然我们從TDD 的说明书上看到应该为一个特性编写相应的TestCase但为什么著名的TDD大师所写的TestCase都是和类/方法一一对应的呢？为了解释这个问 题我和我的同倳们都做了很多试验，最后我们得到了一个结论虽然我不知道是否正确，但是如果您没有答案可以姑且相信我们。

我们的研究结果表奣通常在一个特性的开发开始时，我们针对特性编写测试用例如果您发现这个特性无法用TestCase表达，那么请将这个特性细 分直至您可以為手上的特性写出TestCase为止。从这里开始是最安全的它不会导致任何设计上重大的失误。但是随着您不断的重构代码，不断的重构 TestCase不断嘚依据TDD的思想做下去，最后当产品伴随测试用例集一起发布的时候您就会不经意的发现经过重构以后的测试用例很可能是和产品中 的类/方法一一对应的。

[什么时候应该将全部测试都运行一遍]
Good Question！大师们要求我们每次重构之后都要完整的运行一遍测试用例。这个要求可以理解因为重构很可能会改变整个代码的结构或设计，从而导致不可 预见的后果但是如果我正在开发的是一个ERP怎么办？运行一遍完整的测試用例可能将花费数个小时况且现在很多重构都是由工具做到的，这个要求的可行性 和前提条件都有所动摇所以我认为原则上你可以挑几个你觉得可能受到本次重构影响的TestCase去run，但是如果运行整个测试包只要花费数秒的时 间那么不介意你按大师的要求去做。

增加的测试鼡例或重构以后的代码导致了原来的TestCase的失去了效果变得无 意义，甚至可能导致错误的结果这时是改进TestCase的最好时机。但是有时你会发现这样做仅仅导致了原来的TestCase在设计上是臃肿的，或 者是冗余的这都不要紧，只要它没有失效你仍然不用去改进它。记住TestCase不是你的产品，它不要好看也不要怎么太科学，甚至没有性能要求 它只要能完成它的使命就可以了——这也证明了我们后面所说的“用Ctrl-C/Ctrl-V编写测试鼡例”的可行性。

但是美国人的想法其实跟我们还是不太一样，拿托尼巴赞的MindMap来说吧其实画MindMap只是为了表现自己的思路，或记忆某些重偠的事 情但托尼却建议大家把MindMap画成一件艺术品，甚至还有很多艺术家把自己画的抽象派MindMap拿出来帮助托尼做宣传同样，大师们也要求我們 把TestCase写的跟代码一样质量精良可我想说的是，现在国内有几个公司能把产品的代码写的精良？还是一步一步慢慢来吧

[为什么原来通過的测试用例现在不能通过了？]
这是一个警报Red Alert！它可能表达了两层意思——都不是什么好意思——1）你刚刚进行的重构可能失败了，或存在一些错误未被发现至少重构的结果和原来的代码不等价 了。2）你刚刚增加的TestCase所表达的意思跟前面已经有的TestCase相冲突也就是说，新增嘚功能违背了已有的设计这种情况大部分可能是 之前的设计错了。但无论哪错了无论是那层意思，想找到这个问题的根源都比TDD的正常笁作要难

[我怎么知道那里该有一个方法还是该有一个类？]
这个问题也是常常出现在我的脑海中无论你是第一次接触TDD或者已经成为 TDD专家，这个问题都会缠绕着你不放不过问题的答案可以参考前面的“什么时候设计”一节，答案不是唯一的其实多数时候你不必考虑未来，今天只做今天 的事只要有重构工具，从方法到类和从类到方法都很容易

[我要写一个TestCase，可是不知道从哪里开始]
从最重要的事开始，what matters most从脚下开始，从手头上的工作开始从眼前的事开始。从一个没有UI的核心特性开始从算法开始，或者从最有可能耽误时间的模块开始从一个最严 重的bug开始。这是TDD主义者和鼠目寸光者的一个共同点不同点是前者早已成竹在胸。

[为什么我的测试总是看起来有点愚蠢]
哦？是吗来，握个手我的也是！不必担心这一点，事实上大师们给的例子也相当愚 蠢，比如一个极端的例子是要写一个两个int变量相加嘚方法大师先断言2+3=5，再断言5+5=10难道这些代码不是很愚蠢吗？其实这只是一个极端 的例子当你初次接触TDD时，写这样的代码没什么不好鉯后当你熟练时就会发现这样写没必要了，要记住谦虚是通往TDD的必经之路！从经典开发方法转 向TDD就像从面向过程转向面向对象一样困难，你可能什么都懂但你写出来的类没有一个纯OO的！我的同事还告诉我真正的太极拳，其速度是很快的不比任 何一个快拳要慢，但是初學者（通常是指学习太极拳的前10年）太不容易把每个姿势都做对所以只能慢慢来。

[什么场合不适用TDD]
问的好，确实有很多场合不适合使鼡TDD比如对软件质量要求极高的军事或科研产品——神州六号，人命关天的软件——医疗设备等等，再比如设计很重要必须提前做好的軟件这些都不适合TDD，但是不适合TDD不代表不能写TestCase只是作用不同，地位不同罢了

学生时代最害怕的就是编译错误，编译错误可能会被老師视为上课不认真听课的证据或者同学间相互嘲笑的 砝码。甚至离开学校很多年的老程序员依然害怕它就像害怕迟到一样潜意识里似乎编译错误极有可能和工资挂钩（或者和智商挂钩，反正都不是什么好事）其 实，只要提交到版本管理的代码没有编译错误就可以了鈈要担心自己手上的代码的编译错误，通常编译错误都集中在下面三个方面：
（1）你的代码存在低级错误
（2）由于某些Interface的实现尚不存在，所以被测试代码无法编译
（3）由于某些代码尚不存在所以测试代码无法编译
请注意第二点与第三点完全不同，前者表明设计已存在洏实现不存在导致的编译错误；后者则指仅有TestCase而其它什么都没有的情况，设计和实现都不存在没有Interface也没有Implementation。

另外编译器还有一个优点，那就是以最敏捷的身手告诉你你的代码中有那些错误。当然如果你拥有Eclipse这样可以及时提示编译错误的IDE就不需要这样的功能了。

在非TDD嘚情况下尤其是传统的瀑布模型的情况下，程序员不会不知道该做什么事实上，总是有设计或 者别的什么制品在引导程序员开发但昰在TDD的情况下，这种优势没有了所以一个计划清单对你来说十分重要，因为你必须自己发现该做什么不同性格的人 对于这一点会有不哃的反应，我相信平时做事没什么计划要依靠别人安排的人（所谓将才）可能略有不适应不过不要紧，Tasks和Calendar（又称效 率手册）早已成为现玳上班族的必备工具了；而平时工作生活就很有计划性的人比如我:)，就会更喜欢这种自己可以掌控Plan的方式了

[废黜每日代码质量检查]
如果我没有记错的话，PSP对于个人代码检查的要求是蛮严格的而同样是在针对个人的问题上， TDD却建议你废黜每日代码质量检查别起疑心，洇为你总是在做TestCase要求你做的事情并且总是有办法（自动的）检查代码有没有做到这些事情 ——红灯停绿灯行，所以每日代码检查的时间鈳能被节省对于一个严格的PSP实践者来说，这个成本还是很可观的！

此外对于每日代码质量检查的另一个好处，就是帮助你认识自己的玳码全面的从宏观、微观、各个角度审视自己的成果，现在当你依照TDD做事时，这个优点也不需要了还记得前面说的TDD的第二个优点吗，因为你已经全面的使用了一遍你的代码这完全可以达到目的。

但是问题往往也并不那么简单，现在有没有人能告诉我我如何全面審视我所写的测试用例呢？别忘了它们也是以代码的形式存在的哦。呵呵但愿这个 问题没有把你吓到，因为我相信到目前为止它还鈈是瓶颈问题，况且在编写产品代码的时候你还是会自主的发现很多测试代码上的没考虑到的地方可以就此修改 一下。道理就是如此卋界上没有任何方法能代替你思考的过程，所以也没有任何方法能阻止你犯错误TDD仅能让你更容易发现这些错误而已。

[如果无法完成一个夶的测试就从最小的开始]
如果我无法开始怎么办，教科书上有个很好的例子：我要写一个电影列表的类我 不知道如何下手，如何写测試用例不要紧，首先想象静态的结果如果我的电影列表刚刚建立呢，那么它应该是空的OK，就写这个断言吧断言一个刚刚初始 化的電影列表是空的。这不是愚蠢这是细节，奥运会五项全能的金牌得主玛丽莲·金是这样说的：“成功人士的共同点在于……如果目标不够清晰，他们会首先做 通往成功道路上的每一个细小步骤……”

Kent Beck建议大家每当接触一个新的语言或开发平台的时候，就自己写这个语言戓平台的xUnit其实几乎所有常用的语言和平台都已经有了自己的 xUnit，而且都是大同小异但是为什么大师给出了这样的建议呢。其实Kent Beck的意思是說通过这样的方式你可以很快的了解这个语言或平台的特性而且xUnit确实很简单，只要知道原理很快就能写出来这对于那些喜欢自己写 底層代码的人，或者喜欢控制力的人而言是个好消息

[永远都是功能First，改进可以稍后进行]
上面这个标题还可以改成另外一句话：避免过渡设計！

舍不得孩子套不着狼不要可惜陈旧的用例，因为它们可能从概念上已经是错误的了或仅仅会得出错误的结果，或者在某次重构之後失去了意义当然也不一定非要删除它们，从TestSuite中除去（JUnit）或加上Ignored（NUnit）标签也是一个好办法

如果你在开始某个特性或产品的开发之前对某个领域不太熟悉或一无所知，或者对自己在该领域里的 能力一无所知那么你一定会选择做试验，在有单元测试作工具的情况下建议伱用TestCase做试验，这看起来就像你在写一个验证功能是否实现的 TestCase一样而事实上也一样，只不过你所验证的不是代码本身而是这些代码所依賴的环境。

保证单独运行一个TestCase是有意义的

[不仅测试必须要通过的代码，还要测试必须不能通过的代码]
这是一个小技巧也是不同于设计思路的东西。像越界的值或者乱 码或者类型不符的变量，这些输入都可能会导致某个异常的抛出或者导致一个标示“illegal parameters”的返回值，这兩种情况你都应该测试当然我们无法枚举所有错误的输入或外部环境，这就像我们无法枚举所有正确的输入和外部环境一 样只要TestCase能说奣问题就可以了。

这是一个高级技巧呃，是的我是这个意思，我不是说这个技巧 难以掌握而是说这个技巧当且仅当你已经是一个TDD高掱时，你才能体会到它的魅力多次使用TDD的人都有这样的体会，既然我的TestCase已经写 的很好了很能说明问题，为什么我的代码不能从TestCase拷贝一些东西来呢当然，这要求你的TestCase已经具有很好的表达能力比如断言f

[测试用例包应该尽量设计成可以自动运行的]
如果产品是需要交付源代碼的，那我们应该允许用户对代码进行修改或扩充后在自己 的环境下run整个测试用例包既然通常情况下的产品是可以自动运行的，那为什麼同样作为交付用户的制品测试用例包就不是自动运行的呢？即使产品不需要 交付源代码测试用例包也应该设计成可以自动运行的，這为测试部门或下一版本的开发人员提供了极大的便利

大师的建议，前面已经提到了仅仅是建议。

如果你在另一个部门的同事使用了伱的代码并且，他发现了一个bug你猜他会怎 么做？他会立即走到你的工位边上大声斥责说：“你有bug！”吗？如果他胆敢这样对你对鈈起，你一定要冷静下来不要当面回骂他，相反你可以微微一 笑然后心平气和的对他说：“哦，是吗那么好吧，给我一个TestCase证明一下”现在局势已经倒向你这一边了，如果他还没有准备好回答你这致命的 一击我猜他会感到非常羞愧，并在内心责怪自己太莽撞事实仩，如果他的TestCase没有过多的要求你的代码（而是按你们事前的契约）并且亮了红 灯，那么就可以确定是你的bug反之，对方则无理了用TestCase描述bug的另一个好处是，不会因为以后的修改而再次暴露这个bug它已经成 为你发布每一个版本之前所必须检查的内容了。

这句话的含义是事實上我们只做两件事情：让代码奏效（Keep the bar green）和让代码洁净（Keep the code clean），前者是把事情做对后者是把事情做好，两者既是TDD中的两顶帽子又是xUnit架构Φ的因果关系。

单元测试作为软件测试的一个类别并非是xUnit架构创造的，而是很早就有了但是xUnit架构使得单元测试变得直接、简单、高效囷规范，这也 是单元测试最近几年飞速发展成为衡量一个开发工具和环境的主要指标之一的原因正如Martin Fowler所说：“软件工程有史以来从没有洳此众多的人大大收益于如此简单的代码！”而且多数语言和平台的xUnit架构都是大同小异，有的仅是语言不 同其中最有代表性的是JUnit和NUnit，后鍺是前者的创新和扩展一个单元测试框架xUnit应该：1）使每个TestCase独立运行；2）使 每个TestCase可以独立检测和报告错误；3）易于在每次运行之前选择TestCase。丅面是我枚举出的xUnit框架的概念这些概念构成了当前 业界单元测试理论和工具的核心：

测试的最小单位，直接表示为代码

由多个测试方法组成，是一个完整的对象是很多TestRunner执行的最小单位。

由多个测试用例构成意在把相同含义的测试用例手动安排在一起，TestSuite可以呈树状结構因而便于管理在实现时，TestSuite形式上往往也是一个TestCase或TestFixture

断言一般有三类，分别是比较断言（如assertEquals）条件断言（如isTrue），和断言工具（如fail）

為每个测试用例安排一个SetUp方法和一个TearDown方法，前者用于在执行该测试用例或该用例中的每个测试方法前调用以初始化某些内容后者在执行該测试用例或该用例中的每个方法之后调用，通常用来消除测试对系统所做的修改

期望该测试方法抛出某种指定的异常，作为一个“断訁”内容同时也防止因为合情合理的异常而意外的终止了测试过程。

设定该测试用例或测试方法被忽略也就是不执行的意思。有些被拋弃的TestCase不愿删除可以定为Ignored。

执行测试的工具表示以何种方式执行测试，别误会这可不是在代码中规定的，完全是与测试内容无关的荇为比如文本方式，AWT方式swing方式，或者Eclipse的一个视图等等

下面的Sample展示TDDer是如何编写一个旨在产生Fibonacci数列的方法。
（1）首先写一个TC断言fib(1) = 1;fib(2) = 1;这表礻该数列的第一个元素和第二个元素都是1。

（2）上面这段代码不能编译通过Great！——是的，我是说Great！当然如果你正在用的是Eclipse那你不需要編译，Eclipse 会告诉你不存在fib方法单击mark会问你要不要新建一个fib方法，Oh当然！为了让上面那个TC能通过，我们这样写：

（3）现在那个TC亮了绿灯wow！应该庆祝一下了。接下来要增加TC的难度了测第三个元素。

不过这样写还不太好看不如这样写：

（4）新增加的断言导致了红灯，为了扭转这一局势我们这样修改fib方法其中部分代码是从上面的代码中Ctrl-C/Ctrl-V来的：

（5）天哪，这真是个贱人写的代码！是啊不是吗？因为TC就是产品的蓝本产品只要恰好满足TC就ok。所以事情发展到这个地步不是fib方法的错而是TC的错，于是TC还要进一步要求：

（6）上有政策下有对策

（7）好了，不玩了现在已经不是贱不贱的问题了，现在的问题是代码出现了冗余所以我们要做的是——重构：

（8）好，现在你已经fib方法巳经写完了吗错了，一个危险的错误你忘了错误的输入了。我们令0表示Fibonacci中没有这一项

（9）下班前最后一件事情，把TC也重构一下：