梦想风暴

几个月前，一个同事跟我说，这个bug改不动了，我问为什么，他的答案是，那块的代码太乱了，改一丝会动全身。

昨天，一个同事跟我说，这块太乱了，做不动了。

两次，我做了相同的选择：重构。

重构和开发新功能在很多PM眼里一直是一对很难调和的矛盾。对于PM来说，来自客户的压力让他更关注项目的进展，而重构往往代表项目的原地踏步，只有开发新功能才是“正道”。放弃“正道”，选择看不见进展的重构，站在PM的角度上，这是难以接受的。

“破窗户”理论告诉我们，一旦置破烂于不理，其结果通常是烂得更多更快。

一个同事和我聊天时，提到了他正在做的一个系统，他们在开发的过程中发现了很多问题，很多bug改起来都非常困难。他们想重构，但是强势的PM坚持要开发新功能，于是，这些问题有幸在代码中继续生存下去。随着项目的进行，这些问题暴露得越来越明显，以致于有些问题已经成为项目继续开发新功能的障碍。当问题到了不得不进行修改时，发布的日期也逐渐临近了。

当我做出重构的选择时，我知道，我会失去对当前进度的控制。但我期望得到的是一个合理的设计，以此，后续的一些开发工作会得到大幅度加快，前面失去的进度后面在一定程度可以得到弥补。

几个月前，那段时间，项目进度如预期的慢了下来，但随着重构的进行，我对代码质量也逐渐的越来越有信心了。事实证明，项目后期出现了进度井喷的现象，原本耽误的进度到最后居然出现了提前完成。

这次，当我和那个同事讨论了新版设计之后，我从那个曾经失望的眼里看到了光芒。今天开始工作之前，项目组的所有开发人员又在一起重新讨论了这个新的设计，并进行了一些完善。于是，一个Pair开始采用这个新的设计方案进行编码。事实出乎意料的顺利，原本预计耽误很多的进度，在他们生花妙手的努力下，在今天下班之前，就将大部分赶了回来，让我着实惊讶于他们的开发速度。

从这几个项目的经验来看，重构，短期上在阻碍开发的进度，但是站在长期的角度，却可以大幅度提升软件开发速度，也提高了软件本身的质量，更重要的是，通过重构，解决掉一些原有实现中固有的缺点，可以将程序员从痛苦中解救出来。编程本应该是快乐的，不是吗？

忍无可忍，无须再忍，重构吧！

在关于CodeJAM的那篇blog中，我写道，希望将来有机会把这个面扩大一些，让其他公司的人来和我们一起来做。

周末没有休息，和几个同事参与了一个类似于CodeJam的活动，两天做一个小系统，开发工具还是ROR。不同的是，这次是和客户的开发人员一起工作。

客户的开发人员之前没有接触过ROR开发，所以，这次活动开发的需求，可以说是小得不能再小了。与其说这个活动是为了开发这个系统，倒不如说是给他们进行一个展示，一方面，展示我们的工作方式，另一方面，展示ROR开发的威力。

最初，我并不了解和我们一起工作的这些开发人员的水平，所以，我以为主要的精力要放在开发上。等我真正开始工作，写上几行代码的时候，我才发现，对于这些从来没有了解过Ruby和Rails的人来说，就是简简单单的几行代码，也需要我用大量的口舌去解释。这时，我突然意识到，对这个项目而言，写多少代码其实已经变得不那么重要了，同他们的沟通，远要比写几行代码重要得多。

虽然和我们一起开发的这些人都有一些开发经验，但他们之前的工作经验并没有给他们提供像我们这样开发的机会，所以，需要解释的，不只是ROR的技术，更多的是一种工作方式。比如，第一天下午的时候，我几乎大多数时间是在和人解释测试，不是如何TDD，而是讨论为什么要做测试，以及测试和业务代码的关系。他们会问，我写完一个功能，刷一下页面，看看结果不就可以了，为什么要写测试，他们会问，测试代码在运行时起到怎样的作用，他们会问，如果测试不影响业务代码，我为什么要写它，等等。这个时候，我不得不把思路拉回到我刚刚接触这些概念的时候，给他们提供一个合理的解释。

总结的时候，这些开发人员普遍的感觉是大开眼界，这时，有一种自豪感在心底升起，正如gigix所说，这种一出手就能给人带来震动的感觉，很好。

这是一个非常好学的团队，在开发过程中，他们会不断提出各种各样的问题，因为我们所做的几乎一切都与他们原有的工作方式有着巨大的差异。两天时间，不仅仅是我，所有参与这次活动的ThoughtWorker都解释了大量的东西，以致于每天结束时，都会有一种口干舌燥的感觉。

不过，他们也有一些担心，如果我们离开，失去了我们的支持，他们该如何走下去。这是一个非常好，而且也非常现实的话题。这种开发方式在ThoughtWorks是一种理所当然，而在他们的开发团队，因为原有开发习惯在作祟，会让他们遇到很多问题。我们能够给出的，只是一部分建议，可能要他们更多的探索和坚持，以及也许日后与我们的进一步合作。

对于他们而言，这是改变的开始。

上周末，Agile China，因为家里有些事，我没有参加。

作为一个ThoughtWorker，错过这次活动的遗憾并不是像之前以为的那么大。首先，这次活动所涉及到的内容，大多是内部讨论或是讲座涉及到的东西，再有，这次活动做得比较好的地方是很快就放出了活动的讲演稿和视频，所以，可以随后弥补一下错过现场的遗憾。

真正值得遗憾的是，错过了一次与人交流的机会。

有时，我会想，公司为什么要举办Agile China这样的活动。在ThoughtWorks的工作这段时间，敏捷已经成为了一种工作习惯，我甚至不觉得它有任何特别的，对我而言，它只不过是一种恰当的工作方法而已。与很多书上介绍的敏捷方法，几乎没有太大的差别。

最近，一个朋友给我写了一封邮件，给我介绍了一些他心目中应该如何做持续集成，这是他读了一些东西加上了一些自己思考的结果。不过，在我看来，所有这些内容和我日常工作中使用的持续集成差别几乎没有。显然，当这些内容还停留在他思考中的时候，我们已经在实践了。显然，他对这方面的了解还是有些不足的。事实上，这位朋友也很愿意提高自己，只是周遭的环境能够给他的帮助太有限了。

和Darwin聊过，ThoughtWorks带给我们的并不是直接技术上的进步，而是为我们打开了一扇窗。与不同的人交流，会让我们拥有更开阔的视野，总有很多新鲜东西在等待我们了解。

还是那句话，敏捷不过是一种恰当的工作方式而已。对比于所谓的传统开发方式，敏捷给人的感觉是很不同，但如果真正在工作中使用它，消除了它的神秘面纱，也不过如此。但真正有多少人能在工作中使用。它这是一个问题。只读几本书，照着几个实践去做，就“敏捷”了吗？未必。看到很多人在抱怨敏捷，不过，很多说法都是想象或是教条的结果。

公司举办的Agile China实际上是一种经验分享，告诉大家，我们在做什么。正如我前面所说，这些东西其实并不是什么新鲜东西，但对于不了解它的人来说，它就是新鲜东西。

闭塞，是阻碍人不断进步的绊脚石。

bug这种东西，只要存在，早晚会暴露出来，即便是深藏25年。不过，我们了解到的bug大多不具备很深的资历。有些不幸的bug会被QA们扼杀在摇篮之中，稍微强壮一点的也许可以生存到系统发布之后。

拜IE6所赐，我们的系统刚刚上线，便有一个bug浮出水面。经过验证，这是IE6处理直接打开附件（如PDF、PPT等）的错误。不过，好在这是一个广泛遇到的问题，使得这个bug连午饭时间都没有坚持到，便被消灭了。

按照对客户的承诺，我和另外一个同事要在办公室支持到晚上10点。上午的时候，我们的QA和客户努力了三个小时，并没有发现其它问题，于是，我们想当然的认为我们可以按“点”下班。就在我们俩准备收拾东西回家睡觉之前，从睡梦中醒来的客户终于发现了bug。于是，我们只好在深夜来临之际，开始了bug征服之旅。

有bug不是什么坏事，发现总是比不发现好。

在客户和PM压力之下修改代码并不是什么愉快的经历，好在bug们都是一些友好的家伙，很容易就定位到。不过，因为客户在线，所以，必须强迫自己把事情做得尽可能按部就班：本机测试、提交到主干、提交到分支、部署到测试环境……

感谢之前大家辛勤努力编写的测试，让我们很容易就知道自己的修改在系统内会造成怎样的影响。通过所有测试的那一刻，心头如释重负。在这个原本很是紧张的时候，多了一份自信。我喜欢这种感觉，虽然忙碌，但依然从容，一切尽在掌握之中。

这个无眠的夜里，身边还有自己的Pair，有专程赶来帮助我们进行验证的项目组的老大哥，当然，还有一直都很辛苦的PM，一个敬业的团队。

一起想一下，程序发布之前的情形。

印象中，这应该是一个手忙脚乱的阶段，一大群人奔前跑后，忙着处理各种各样的问题，尤其是bug。许多人回忆自己经历的时候，往往会很有成就感的说，在某某程序发布之前，忙了一整夜，终于在程序发布之后，回到家里，一觉睡了N个小时，俨然一副历经沧桑的样子。自己经过的，既有有过连续十几天工作十几个小时，为了赶上发布日的经历，也有连续几个熬到后半夜改bug的痛苦。虽然这些都是不错的日后谈资，但当时，那是透支的感觉。

现在，我在等待发布。

是的，等待！

Story的开发工作早就已经完成，bug修改也到了尾声。代码已经冻结，Mingle上可供开发的卡已无踪影，有一种闲暇无聊的感觉。

这已经不是第一次体验发布前的闲暇了。记忆中，最近做过的几个项目，到了最后的几天，都会出现无卡可做的情况。最极端的是有一次，在PM的陪伴之下，打了多半天的游戏。

对比之前的经历，这样的经历显得很特别。原本在我的印象中，越是临近发布，应该越是忙碌，而这种一下子闲下来的感觉，真的是让人有些不适应。

这个时候，PM就成了给大家找事的人。比如，他会组织大家进行一些讨论，看看之前那些做得好，做得不好，以便在后续的工作中进行改进。比如，他会把一些属于下一个阶段的任务拿过来，让大家分析一下，提前热热身，有些手快的家伙，甚至会顺便把一些任务做完。

这样难得的清闲，多半要归功于合理的计划和控制。其实，想想之前的经历，最终期限并不是合理规划出来的。事实上，大多数情况下，对于要做什么，以及这些工作的工作量究竟有多大，并没有很好的估计，所以，往往就是指定一个发布的日期，剩下的就是靠人了，其结果就是为了赶上发布日期，拼命的加班加点，那种透支需要很长一段时间才能恢复过来。

而现在做项目，所要做的一切都是经过大家一起估计出来，包括客户和开发团队，大家对于软件开发的实质认识得比较清楚，所以，不会做一些杀鸡取卵的事情，于是，所有的一切，都会按照预期一步步进行：开发团队也不会为了追赶进度，而损失了软件的内在质量；客户会重新认识他需求的价值所在，做好优先级排序，而不会不明就里的要求全部完成。这是一个合理的开发过程，一种软件开发应有的状态。

准备发布了！