五天之内，三步读懂一个行业
May 16th, 2013
作为职业咨询师，在很短时间内熟悉一个行业，是我经常要面对的工作内容，我也很愿意分享自己的心得。根据我的经验，对于掌握了基本商业知识的咨询师而言，一个星期之内熟悉一个之前陌生的行业并非难事。当然一个星期不会让一个新鲜人成为行业专家，但是足以让一名咨询师在这个行业里顺利开展工作。
这有限的五个工作日，必须高效地利用。我的建议是分三步走：首先，确保自己不会乱开黄腔；其次，让自己进入这个行业的对话；第三，争取提出令人眼前一亮的观点。
第一步：首先不要开黄腔
进入一个新的行业，首先应该了解这个行业里的领导企业——很可能正是你马上需要去服务的企业。了解一个领导企业最直接的方式，就是读它的财务报表。上市企业的财务报表都是公开的，并且通常会附上很有用的董事长致投资者函。阅读一份财报，就可以了解很多基本的信息：这家企业的所有权性质、主要业务、主要客户、收入结构、成本结构、员工规模、人才结构、战略方向、主要风险……即便你真正想了解的企业是非上市企业（比如华为），它也必定与其最主要的竞争对手（比如中兴）有很多相似之处。所以阅读财报可以让你对这个行业里的主要玩家有一个基本的了解，不至于提一些太离谱的问题或者建议。
花一天时间读完一两家企业的财报之后，接着就得下点死工夫，读一本这个行业的综述性书籍，例如对于保险行业我推荐《风险管理与保险》。读这样一本书的目的，第一是更深入地理解这个行业的商业模式和惯例，比如你得知道财产险和寿险存在一些根本性的差异所以它们的经营也会很不同；第二是掌握一些行业里的“黑话”，比如当你听到“承保”、“核保”时你得知道这都是指什么。我个人而言，读这本书是用业余时间，加起来用了8小时左右。
第二步：进入行业对话
做到了不开黄腔也还不足以跟行业里的CxO们展开对话，因为大家平时不会谈论那些最基本的东西。要进入一个行业的对话，你得了解这个行业当下的趋势。有些人会推荐跟行业里的朋友去聊天。但作为一个时间紧迫的内向型人，我个人更愿意以研究材料为主，与朋友聊天为辅。
行业趋势的最佳来源是麦肯锡之类管理咨询公司做的行业分析。我个人尤其推荐麦肯锡季刊（ McKinsey Quarterly ）发布的研究报告，以及经济学人（ The Economis ）的行业分析。从这两个网站搜出最近五年所有与你关注的行业相关的文章，花一到两天时间全部通读一遍，你应该就能把握住这个行业的脉搏。
在中国市场上工作，我们会担心来自麦肯锡和经济学人的分析不够“中国特色”。我的经验是，一方面可以适当补充一些本土内容；另一方面，中国各行各业的发展基本上与世界先进水平保持3~5年的差距，也就是说欧美发达国家在三五年前发生过的应该就是中国当前正在发生的，欧美发达国家一两年前发生过的应该会在一两年后在中国发生。比起“中国特色”，很多时候简单的市场规律和时间差更有效。
与此同时，在这整个一周时间里，你要让自己浸泡到这个行业的上下文中。办法很简单：订阅一堆与这个行业、与你想要针对的目标企业直接相关的新闻RSS，把其他的RSS频道都暂时屏蔽，在地铁上、咖啡馆里、床头上、马桶上……所有的空闲时间都用来看这个行业、这家企业最近发生了什么。比如我在关注澳洲保险行业的阶段，就订阅了Google News的“australia insurance”关键字和我客户公司的名字，客户公司出什么重大理赔案或是高层人事变动，我能比客户的大多数员工还先知道消息，于是就有了很多可以谈论的话题。
第三步：以我为主，提出观点
开始这个连载的时候彭萦讲了一个故事，说某咨询公司的创始人要应聘者一周内给出一份行业报告，但回头他发现这些名校毕业生做的报告都没有一个亮点。且不论这个故事是真是假，在我看来，“没有亮点”的症结恐怕就在于应聘者是“毕业生”：虽然是研究另一个行业，其实“亮点”的关键不在对那个行业研究得多好，而在研究者自身的专业技能。所谓“功夫在诗外”，就是这个道理。
举个例子来说。如果你看麦肯锡去年所做的中国寿险行业分析，首先你会发现它遵循了前面说的两步：数据详实，术语准确，而且把握住了行业脉搏。但它的亮点在于它指出了中国寿险行业的几大痛点，并且从战略和管理的角度提出了对应的解决方案。归根到底这才是行业里的CxO们期望你作为一个专业人士拿出来的东西，也是你之所以要去快速了解这个行业的根本目的：快速了解一个行业不是为了显示自己的学习能力，而是为了使自己的专业技能在这个行业中得到运用。
所以，在做了前两步功课之后，你至少应该给自己留出一整天的时间来回答这样三个问题：
- 这个行业所面临的痛点有哪些？
- 哪些痛点对于业内人士是最紧迫的？
- 如何把自己的专业技能与这些痛点结合起来？
其中前两个问题的答案应该是相对客观的。也就是说，你大可以把麦肯锡的寿险行业分析打印出来，扔掉最后的“解决方案”部分，然后结合自己的专业领域，来尝试给它所列举的几大痛点寻找解决方案。如何用IT手段改善寿险销售？寿险行业需要何种人力资源战略？甚至何种MBTI人格更适合从事高水平的寿险服务？凡此种种不一而足。提出观点这部分，就是专业人士站在自己专业领域的命题作文，能不能讲出亮点，第一靠快速理解目标行业的小聪明，最重要的还是看在自己专业领域里的造诣。
（本文是应 彭萦 之邀，为“改变自己”这个微信公众账号所写的。这个励志的微信账号致力于帮助读者“每天改变自己一点点”。感兴趣的话可以搜索微信公众账号“wechanger”，或扫描下面的二维码。）
十年前的Java企业应用开发世界
May 14th, 2013
在2003年用Java编程比现在要更痛苦一些。比如说，J2SE 1.5还没有发布，也就是说一些现在大家认为理所当然的特性，比如泛型容器、static import、Annotation，都是不存在的；Integer和int是不能自动转换的；枚举只是整数换了个写法没有任何类型安全机制……我还在2003年第6期《程序员》杂志发表了一篇文章，介绍J2SE 1.5的新特性。而在项目里，不管是浙江省财政厅的项目，还是杭州市工商局的项目，我们用的都还是J2SE 1.3。
更大的挑战——或者说，乐趣——是框架乃至编程思想的不统一。几年以后，当Java企业应用开发彻底成熟，所有人都知道SSH（Spring+Struts+Hibernate，后来Struts终于被SpringMVC取代），连培训学校也拿这几样东西来作为就业敲门砖。可是在2003年，Martin Fowler那篇“Dependency Injection”还没发表，关于“什么是好的容器框架”还远远没有定论。且不提Apache Avalon这样的容器——照现在的眼光来看，Avalon根本算不上一个合格的容器，但你必须意识到它是Java 1.3之前的作品，这样才能理解为什么它会存在并进入这个讨论——Spring之外还有Paul Hammant和Jon Tirsen的PicoContainer在与之竞争成为事实标准。而当时还在0.x版本的Spring（当年10月Spring才发布1.0版本），其功能也并不比单纯专注对象容器的Pico丰富。
Web框架的情况更加混乱。Struts被使用最多同时也被诟病最多；Rickard Oberg刚做出了WebWork，大家还没充分意识到它的好处。更麻烦的是，其时整个J2EE社区并未——像今天这样——达成一个共识说“MVC是好的”，于是其他种种构造Web应用的方式以及相应的框架层出不穷：有人相信Web开发也应该走“组件化”道路，于是有了面向组件的Web框架（例如Tapestry ）；有人认为Portal才是未来Web的发展方向，于是有了形形色色的Portlet容器（例如JetSpeed ）；甚至还有人尝试用“XML文档+XSLT转换”的方式来实现Web应用。当年最火的全功能Web框架还是Turbine ，到如今它给我们留下的也就只剩Velocity 了——恰恰Velocity所代表的“view template engine”在当时还没有被广泛接受，更多人仍然习惯于在JSP里直接写上一大堆Java代码。当时有人笑称，每周都会有一个新的Web框架在TSS上发布——其时最具影响力的J2EE网上社区TheServerSide.com被简称“TSS”，由此可见那时的企业软件世界是有多爱三字母缩写词。InfoQ的创始人Floyd Marinescu当时还在TSS做内容主管呢。
持久化框架的情况也好不到哪儿去。Hibernate倒是已经发布了2.0版本，不论功能还是性能都已接近成熟；可是Hibernate与ADO之间的争论正在如火如荼地展开着，究竟应该选一个刚开始热门的开源框架还是选一个“标准”也颇让人头疼；同时也别忘了另一边，很多程序员更愿意用简单的SQL来操作数据库，而不是在对象与关系数据的映射中绞尽脑汁；再加上2003年普遍的“XML热病”，真的有很多人相信可以把企业应用中的数据持久化成XML从而抛弃关系型数据库——你也可以说这是NoSQL的早期萌芽，总之当时这些思想只是让事情变得更复杂而已。
当你谈论2003年的J2EE世界时，千万别忘了这里还有EJB。实际上，EJB 2才是当时J2EE的正统——再提醒一下读者们，Spring还在0.x的阶段，Rod Johnson那本旗帜般的“without EJB”还没写出来呢。曾经有IBM的咨询师来跟我们讨论应用架构，听说我们完全没用EJB时都连连摇头。如果不是石一楹坚持不用EJB，也许我会走上一条相当不同的技术路线。后来我一直对EJB不怎么上手（虽然还翻译过一本与EJB关系不少的书），倒是轻量级J2EE架构接受起来驾轻就熟，不得不说是种运气。
仿佛是嫌事情还不够复杂，那时很多企业对开源软件抱持一种不信任的态度，所有框架都愿意自己开发，似乎只要“not invented here”的东西就不可靠——这样的企业现在也有，毕竟数量少多了。这里固然有心态的原因，同时技术上的原因也不应该忽视。J2SE 1.3引入了动态代理（dynamic proxy）技术，以Rickard Oberg为代表的一帮天才开发者们立即敏锐地意识到：这是一件框架开发的利器——在与JBoss Group决裂之前，Oberg是JBoss的首席架构师，可以说是他一手创造了JBoss；同时他也是AOP和Interception的狂热爱好者，因为他早早地看到了这些元编程技巧在框架开发中的重要意义，而动态代理则正是让Java不依赖于外部的、非标准的代码生成技术（例如AspectJ、CGLib等）实现动态元编程的基础设施。其结果是，从Java 1.3开始，很多新的框架显著地变得更优雅、更少侵入性——Java 1.3之前的“老”框架，例如Avalon、Turbine，与这些后来者比起来就显得相形见绌。然而这种优雅同时也意味着更难理解其内部运作机制，有时对着一个漂亮的框架就仿佛在看一场精彩的魔术，愉悦之余也难免有些心里犯嘀咕。正处在这场转变之中的企业和团队，希望自己动手开发框架从而获得更多安全感，也是情有可原。
不过这种复杂、混乱与缺乏信心对于程序员来说倒未尝不是好事。短短的几个月时间里，我的项目主管带着我把J2EE Web应用的全套框架——对象容器、持久化、Web MVC——都实现了一遍。这个过程不仅让我的技术水平突飞猛涨，而且还让我交了不少朋友：因为我比较喜欢显摆，做出点东西就在网上谈论，一来二去就结识了一些与我有着同样困惑的同行。在这些“以技术会友”的新朋友之中，最有趣的是一个叫DreamHead的家伙。这人每每写邮件长篇大论洋洋千言，博客也是一副正襟危坐的范儿。我们讨论的主要就是这些基础框架与架构，没想到类似的话题我竟然与他一直讨论了十年。
当我谈扁平组织时，我谈些什么
April 24th, 2013
CSDN最近给徐昊做了 一个采访 。作为ThoughtWorks中国区的CTO，徐昊说他自己“非常不想成为技术管理者”。在我看来这个调调非常有代表性，它集中体现了一个扁平组织的诸多特征。
ThoughtWorks是一个真正意义上的扁平组织。行政管理的层级在这里只有三级：CEO（我领导最近 刚升了这个职位 ），地区管理董事（比如“中国区老大”），然后就是所有人。所有人的直接汇报和负责对象是地区管理董事。以成都公司为例，所有咨询师的直接汇报和负责对象是新任的pair中国区老大 胡凯 和张松，其他任何人都不是你的行政管理者。
这就引出了第一个问题：别的那些头衔（比如徐昊的“CTO”，我的“成都公司负责人”，郑晔 的“校长”，等等）算怎么回事呢？新同事（尤其是有工作经验的新同事）往往会困惑：不是据说扁平组织没有管理者吗？怎么还有那么多有头衔的人在那儿呢？
这是扁平组织的一个重要特征。扁平组织不是乌合之众。在一个扁平组织里，仍然会有各种各样的分工、各种各样的人需要对各种各样的事情负责，因此会有各种各样的领导者。领导者不是管理者，领导者所负责的是功能而不是组织机构（例如“部门”），他带领一群人一起完成一件事，而不是管理这群人的所有巨细。所以，在一个扁平组织里，你会只有很少的管理者，却会有很多的领导者。比如你工作的项目会有项目经理，你们共同达成项目交付；你参加的学习活动会有校长，你们共同组织学习；你对iOS开发感兴趣，会有移动实验室负责人来组织研究和市场开拓；你所在的办公室还会有办公室负责人，你们共同创造一个牛逼的工作环境。人的能力、见识有所不同，要组成一个团队达成一个目标，必定就会有人要做最终的决定、要对结果负责，这些人就是领导者。成为领导者不需要“晋升”，从一个领导者角色走出来也不是“左迁”。
下一个问题跟着来了：既然不是管理者，既然是扁平组织，这些领导者可以/应该强迫我做什么事吗？扁平组织不就应该让我“follow my heart”，做我想做的事（并且不做我不想做的事）吗？
很遗憾，答案可能跟你想象的不一样。这是扁平组织的另一个（并且经常被误解的）重要特征。扁平组织不是乌托邦。正如前面所说，领导者要带领一群人一起达成一个共同的目标。然而人是有局限性的。每个人了解的信息不同，对信息的理解程度不同，能力水平不同，自律程度不同。就像那句老话说的，“一懒二拖三不读书”，这是人人都有的毛病。因为有这些毛病，我们才需要与别人构成一个团队，以期达成自己无法达成的目标，并从这个过程中获得自我的提升。为了获得这些，我们就得放弃一定程度的自我中心。领导者就是会不时地强迫我们做自己不想做的事、不做自己想做的事，而接受这种强迫就是进入这样一个群体必须做出的承诺。
很可能出乎意料地，在一个扁平组织中，这种承诺有时会很重，比层级结构的组织中更重。在一个以命令、汇报和制度驱动的组织中，你只要弄明白制度规定了什么，然后做制度规定的事、不做制度禁止的事，就够了，（理论上）谁也不能挑你的毛病。而在一个扁平组织中，你需要理解自己所加入的每个团队，接受每个团队的承诺和强迫。比如一个学习函数式编程的小组会要求你每周拿出两天下班后的业余时间，你要加入这个组就不能“follow my heart”说我每天晚上都得去健身干不了别的。不去理解、不去遵守规章制度之外的承诺，在一个层级结构的组织中也许关系不大，但在一个扁平组织中就是极具破坏性的行为。
第三个问题是如何激励人。这里没有升迁机会，没有掌权的机会，也 没有赚大钱的机会 ，那么人们到底为什么来到这里，为什么被激励？说实话，这是一个无法解决的问题。只要看看连徐昊都在说“非常不想成为技术管理者”，你就可以知道：这个扁平的组织真的没什么办法激励人选择他们不想选择的方向、跟随他们不想跟随的领导者。所以我们唯一能做的就是：如果有那么一个人没什么自己想做的、没有钱和权的激励就不会往前走，那么我们就不跟他做同事，我们不让他进入这个圈。因为我们知道，我们真的给不了他想要的。
现在小结一下：像ThoughtWorks这样的扁平组织，不是乌托邦，不是想干什么就干什么，可能会有更多的领导者，可能会强迫你做更多的事，而且掌不了权发不了财。所以，如果你跟我们一样，认为追求软件卓越和社会公正是那么一件有意义的事，欢迎来加入；如果你发现我们给不了你想要的，我们也并不为此感到抱歉。
为什么程序员应该写作
March 29th, 2013
能写技术文章的，十有八九都是在一线打拼的程序员，写作对他们而言不是主业，很多（也许应该说“绝大部分”）优秀的程序员根本就没想过自己也可以写文章发表。然而，越是优秀的程序员，写文章发表越是对自己有价值，原因有二：
第一，写作有助于自我成长。刚入行时，困扰大家的问题都是书上写过、Google上现成能搜索到的，只要花心思去找就能找到；随着程序员的水平提高，他思考的问题就开始变得更有深度、规模更大、更抽象、更复杂，更需要以写作的方式来整理成型。从我认识这么多人来看，这个阶段写文章和不写文章，会对一个人知识体系的构建有重大的影响。很多人也有多年经验积累，也有不少想法，但是没有形成一个完善的体系，随着年纪增大，生活压力越来越重，记忆力越来越差，渐渐就说不出到底从这么多年经验中学到了什么。我觉得这是件很可惜的事。
第二，写作有助于扩展见识。程序员从业有些年头以后，如果是喜欢技术的人，总会想与别人做些更深入、更高层次的交流，但毕竟水平越高，能进行这种交流的人就会越少、越分散。写作、演讲、著书立说，这都是让自己进入一个更高水平的交流圈的方式。进入了这个对话环境，你才发现：原来还有那么多可学、可发展的方向。很多人到了三十岁上下就开始惰怠、看不到发展方向，在我看来一个重要的原因就是眼界不开，没有进入一个更高水平的交流生态。
新书推荐：敏捷软件度量
March 27th, 2013
软件项目、软件组织和软件专业人士的度量是一个由来已久的难题。
当ISO、CMM等“重量级”管理方法占据言论主导地位时，我们看到管理者们拿出条目繁多的度量方法和KPI，试图量化员工的工作绩效；与此同时员工们却一边抱怨冗杂的报告和数据表，一边行之有效地找到了敷衍“上头”使他们不再干扰自己正常工作的妙策，顺便——借由呆伯特漫画——嘲笑高高在上不知民间疾苦的管理者们。
而当SCRUM、看板之类“敏捷”方法甚嚣尘上，被一句“人和交互重于流程和工具”激励起来的程序员们高声喊出“我们不要文档/度量/KPI，我们交付可工作的软件”；而——绝非邪恶的——软件组织领导者们则郁结于如何在更大范围、更长周期了解员工和团队的状态和能力水平。毕竟，如果连“全局”究竟是什么样子都无法看到，“全局优化”就只能是一句空话。
我无意在此引发又一轮软件方法学之争，只想提醒读者的注意：对于度量这件事，我们这个行业存在着如此明显的张力，使得任何一位严肃的领导者乃至从业者都无法也不该忽视其中的挑战。一方面，所有人都赞同：“好的”度量对组织以及个人都将大有裨益；另一方面，真正找到“好的”度量方法者寥寥。这个问题的解决，需要丰富的软件、工程、管理乃至商业理论与实践经验的深度结合，并且需要在实际的运用中不断改善精炼。
在所有探索有效软件度量方法的尝试中，这本《精益软件度量》是一本开创性的佳作。从精益软件开发入手，作者首先建立了一个适用于现代软件组织的度量体系。基于这个体系，作者介绍了如何对软件的价值、速度、质量等每个软件组织都高度重视的核心要素进行有效度量。
如果前面这些还是其他著作也有所提及的内容，接下来的部分就是极具开创性——而且极具价值——的思考与经验了。除了软件交付的“业务”本身，作者专章论述了如何对软件组织及从业者个人的能力进行度量，并给出了建设学习型组织、持续提升组织和个人能力的指导。最后，作者还以可观的篇幅讲述如何在一个“传统”的软件组织中引入这些精益度量方法，以度量的植入来拉动软件组织的精益转型。这种饱经思辨又与实践紧密结合的“落地指南”，是我在论述同类主题的其他著作中从未见过的。
整本《精益软件度量》读完，除了丰富的思想与实践，字里行间还渗出一种浓浓的人文关怀。作者在第一章就明确指出：“在理念上，我们希望把度量的重心从‘控制’转向‘改进’。”面对加速变化的世界，只有充分发挥员工的主观能动性、帮助员工提升自身能力，企业才能具备长久的竞争力。而管理者或领导者更多地需要扮演“导师”和“服务员”的角色：引导、帮助员工成长去达成他们自己向往的目标，而非以度量指标来控制员工的行为。这种管理思路的转变，意欲为自己的组织引入度量体系的领导者不可不察。
有幸作为张松的同事，与他在最近几年紧密合作，使我清楚地知道：讲述这样一个主题，松哥正是最理想的作者。在加入ThoughtWorks之前，松哥就有着MBA背景及在大型IT企业中工作的经验；在ThoughtWorks的6年中，他在大规模离岸交付项目中艰苦奋战过，也在国内超大型IT组织的敏捷转型中舌战群儒过；作为交付总监和咨询总监他体会过同时关注十余个项目时的惶恐无力，作为人力资源总监他清楚打造一支持续学习、持续改进的团队对于整个企业而言是何其重要。而且在ThoughtWorks中国区管理团队中，松哥一向扮演着“智库”角色：虽然说话不多、嗓门不大，却总是字字珠玑，每每使我们其他成员受益良多。现在松哥的思想与实践得以付梓，使更多读者得以分享他从若干焦油坑中淬炼的菁华，实在是幸事一件。
更多的阅读乐趣，还是留给读者自己在翻开书之后慢慢体会吧。作为在国内帮助IT组织进行精益转型的实践者之一，我希望这本《精益软件度量》能帮助它的读者在他们的组织中建立一套行之有效的度量体系，并最终帮助这些组织的员工切实地提升自己的能力。如此，善莫大焉。
都是为了半夜能提交（二）
March 9th, 2013
项目里会集成外部的web services，怎么测试？当然最不费脑子的做法就是假装它没什么特别，该怎么写测试还怎么写测试。但这么做的结果就是一大堆测试都会真的去调用web services，并且至少造成这么几个问题：
- 测试慢。带着web services跑测试，测试的速度会降低好几个数量级。
- 测试不稳定。一旦有个service挂掉，你自己的build就会跟着挂掉。
- 测试不易重复。比如有个service是用来创建用户的，你怎么办？每次跑build创建一个新用户？还是创建完马上删掉？如果删除出错怎么办？
所以这是不行的。
我们先站在集成点外来看其他程序怎么使用集成点。显然最终我们会把一个web service包装成一个Java方法。比如“创建用户”这个service最终会体现成这样：
public interface IdentityService {
void createUser(Customer customer);
...
那么使用这个service的所有代码都应该通过 依赖注入 得到实现IdentityService接口的一个对象，因此这些地方的测试可以很简单地注入一个mock的IdentityService对象，不需要依赖真正的web service。主要需要看的，还是集成点内部的测试。
集成点内（也就是IdentityService.createUser的实现）实际上有以下几部分逻辑：
- 确定服务地址。不同的服务方法通常位于不同的URL、接受不同的HTTP方法（GET、POST或PUT）。
- 参数转换。把方法参数转换成service需要的参数，可能是（但不限于）XML文档或URL参数。
- 执行网络访问。朝向步骤（1）确定的服务地址，发送步骤（2）得到的参数，拿回一个HTTP应答。
- 解析HTTP应答。HTTP应答通常包含两部分：HTTP状态码（例如“200 SUCCESS”或者“404 NOT FOUND”），以及应答正文（不一定有），有时还会在HTTP头或者Cookie中携带信息。要把这些信息转换成服务方法调用的结果（函数返回值、给参数传入的对象填充值、或者抛出异常）。
可以看到，真正与外部web services打交道的其实只有步骤（3）而已。并且步骤（3）所需的程序基本上可以简化地描述为：
public class EndPoint {
public Response get(String url);
public Response post(String url, String requestBody);
public Response put(String url, String requestBody);
}
如此而已。其中Response类包含以下信息：
class Response {
private int statusCode;
private String body;
请注意：从EndPoint的方法签名可以看到，这里的方法与真实的web services的请求/应答格式是毫无关系的。它所做的就是朝一个URL发送一个请求、拿回应答。至于请求正文是什么格式、应答正文是什么格式、是XML还是JSON，它完全不关心。换句话说，对唯一的这个产生网络访问的类的测试，第一不需要访问真正的web services，第二不需要考虑真正web services的请求/应答协议格式。这个发现对于我们的测试策略非常有价值。
（今天讲了集成点的结构，并着重考察了需要执行网络访问的EndPoint类。下一篇就开始讲测试策略。）
都是为了半夜能提交（一）
March 7th, 2013
这是一个典型的JavaEE项目：SpringMVC，Maven；需要集成三个外部系统。除了我之外，就是两个嫩得不行的小孩。从一开始我就知道，我必须把规矩定好，不然再简单的东西新手们也能把自己玩死。大部分规矩还是老规矩，比如 测试覆盖率100% ，当然CheckStyle啦什么的就不用说了。
但是这个项目有个特别的trick：要集成的三个外部系统，有两个一到晚上（澳洲的晚上，北京时间也就6点来钟）就歇菜了。问了客户的人，人家说是他们依赖的某系统固定歇菜周期，具体是怎样还得花工夫去找。总之这个造成的结果就是，过了北京时间6点来钟就不能提交代码了，因为一提交build就会红，因为跟那两个系统集成的测试都会挂。
虽然说我们build的时间一直就不长（没有超过三分钟），但是我每次看见跑一堆跟依赖系统连接的集成测试就觉得心里不爽；再加上晚上不能提交代码，这就更加不爽了。我白天乱七八糟的破事太多，写会儿代码就会被打断，经常得到了晚上才有大块时间集中干点事，这一家伙晚上不让提交代码，还不把我憋死啊。
所以我的目标是：我要半夜也能提交代码！
我是有具体办法的。跟依赖系统连接的集成测试，其实只要每天跑一次就行了，毕竟那些外部系统接口很稳定不会怎么变。把集成测试拿掉之后，所有我自己程序里的逻辑应该不再依赖项目之外的任何东西。这样的测试跑起来又快，又不会因为外部依赖而变得不稳定，那我就可以半夜写代码了~
接下来我要讲的内容：
- 集成点的测试策略
- 没有外部依赖的开发环境
- 如何达到100%测试覆盖率
- 重构你的代码（和测试代码）
