梦想风暴

作为程序员，你是不是有很多问题看不顺眼：代码写得太乱；进度压力太大；其他人不能按照我的理解来做……

如果你觉得项目有很多问题，请放心，你不是一个人在战斗，项目组里的其他人保证也有类似的想法，唯一的差异是，不同的人因为角度不同，看到的问题是不同的，但有一点是可以肯定的，项目出问题了。

对项目最初的兴奋伴随着种种问题在时间中消磨，剩下越来越多的是无奈。表面上欣欣向荣的团队，弥漫着怨气，士气开始下降。长此以往，没有会再关心这些问题，只能在不断加大的压力闭上双眼埋头前行。即便偶尔有加入的新鲜血液，看到同样的问题，多半会视之为理所当然。

我想问一下，发现问题之后，你把问题提出来了吗？

面对这样的问题，得到的答案可能是，这些问题会牵扯到很多方面，不是一己之力可以解决的，所以，没提。

程序员擅长于与代码打交道，但开发过程中，你看到的很多问题却不是代码问题。即便诸如代码写得太乱之类的问题，背后还会有更深层次的问题，比如进度压力太大，没有人有精力顾及代码美感，比如，团队成员缺乏沟通，彼此不了解对方的代码，面对那段让人不满的代码，却不知如何下手修改。

这些问题真的复杂到无法解决吗？不尽然。

仅以上面乱代码为例。如果在早期团队养成经常性code review的习惯，或是能够通过一些技术session分享知识，便不会存在彼此不了解代码的情况。如果发现代码太乱，立下一些编码的规矩，让大家都去遵循，至少在一定程度上可以控制代码变坏的趋势。

这些问题之所以成了问题，很大成都上源自程序员的沉默。面对非技术问题，程序员们因为不擅长，常常会选择回避，顶多是发一些牢骚。这些问题同软件开发一样，越早期暴露，解决的成本越小，越晚发现，变异成让人无法控制的可能性就越大。在一次又一次的回避中，问题由原本的小问题，变成一个团队无法控制的庞然大物。

其实，要求很简单，觉得不爽了，喊一声，让大家意识到这是个问题。不要怕问题解决不了，我们是一个团队，这不是你一个人的职责，我们一起来想办法。

不要再做一个默默忍受的程序员了！

最近几个月改行做了“教育”。

实施敏捷，关键点还在于能力提升上，而重中之重是开发人员的能力。客户的开发人员在软件开发上大多只能看到眼皮底下的一亩三分地，所以，为了开拓这些开发人员的视野，我们决定把业界一些常见的编程理念介绍给他们，让他们知道，原来编程不仅仅是堆积代码。

交流的第一要务就是了解自己交流的目标，《程序员修炼之道》里的那首WISDOM离合诗就是为此准备的。这是一群只有C经验的人，大多数工作经验只有两三年，有不少人甚至是工作后才开始学习编程的。如果上来就讲面向对象的知识，讲软件架构，很少有人能够接受，虽然不会当面骂我，但他们会觉得内容很虚，况且他们每个人都很忙，所以，提供的内容应该是让他们认为值得花些时间了解的。

这是一个有趣的尝试。我需要把自己脑子关于编程的那些理念拆解开，看哪些部分适合他们的程度，然后，结合他们工作的具体内容，组织介绍材料。开始的时候，我不知道按照这样的要求有多少内容介绍。幸好频度只是每周一次，两个月下来，我介绍了诸如代码坏味道之长函数、头文件、基本的函数、开发者测试等内容。从反馈上来看，这些内容确实让他们看到了一些不一样的东西，而且大家感觉很实用。开发团队也以这些内容为基础，制订了一些新的编码规范。

这次活动基本上是在探索“从只知道完成功能的代码到能写出Clean Code that Works“的路该怎么走。事实上，这也是很多程序员欠缺的。我从一个毕业生到能写出自己相对满意的代码探索了三年，而真正成为一个自己觉得相对比较职业的程序员，却是进了ThoughtWorks之后的事了，补齐了自己在测试和工作习惯方面的一些缺失。经过这次的分解，我逐渐了解了这条路应该怎样走过来。现在想想，如果当初有人告诉我这些内容，或许在开发方面可以成长得稍微快一些。

随着这次分解，我对分解又有了多一些的思考。比如，如果一个人要想真正的TDD，绝不仅仅是按照红——绿——重构节奏就够了。TDD需要开发人员有测试的思维，养成先写测试的习惯，了解软件设计，对代码有灵敏的嗅觉，可以嗅到坏味道，并进行重构。对于一些与遗留代码打交道的人，还需要了解，如何在遗留代码上进行开发。

分解动作，给了我一个思考成长过程的机会。

再见Thoughtorks！

这是Derek，一个离开ThoughtWorks同事写的一篇blog。

我俩同一天加入ThoughtWorks，我记得很清楚，那天是2007年5月8日，当时，办公室还在西安。正是因为同一天加入，我们最初有许多机会在一起交流：一起吃了到西安的第一顿晚餐，一起接受公司的入司教育，一起参加英语考试，一起找房子，一起打游戏，一起在ThoughtWorks成长。

米高给他的评价是公司的程序员里最具诗人气质的一个。

他给人的感觉永远是一副宠辱不惊的样子，他的文字如他的人一样。品味着他告别的文字，看着他自己总结在ThoughtWorks的成长，我不禁会回想自己一路走来的经历。我们之间有着一些相似的心路历程。最初的无知无畏，到随着经验增多而产生的诸多困惑。进入ThoughtWorks之前，累积了许多年的工作经验，在软件开发上有了属于自己的思考，总觉得软件不是那样做的，但应该是怎样做的呢？

ThoughtWorks两年多的工作时间，我们逐渐走出了对做软件的困惑。在ThoughtWorks的收获，Derek的总结非常好：在ThoughtWorks的这段经历使我更关注问题本质、更注重解决方案的实效性，并且不轻易屈服于事物的表面现象而努力寻找并尝试改变。

铁打的营盘，流水的兵，来来往往很多，只有获得真正的收获，才不枉走一遭。

不知不觉，写blog六年了。趁着写这个第六年纪念篇的机会，我把之前的纪念篇全都翻了出来，回首一下六年走过的路。

开始“信口开河”了
一年百博
梦想二年级
三年blog
300和4
五年，在blogbus

有了历史的东西很有趣，可以让人回顾，而回顾就会发现很多有趣的事情。

开篇、第一年和第二年写在沈阳，第三年和第四年写在北京，第五年写在上海，而第六年，也就是现在，我则在西安。地点上的变化也多多少少反映了我最近几年的一个生活状态。之前，我很稳定，从三年开始了四处的漂泊，虽然第三年和第四年，我都在北京，却是在两个不同的公司，而第五年和第六年都是我出差在外的日子了。

从一开始，我就不大相信自己可以坚持写下来，当一年一年走过来，我逐渐相信，blog已然成为生活的一部分。无他，习惯而已。我是个懒惰的人，一旦习惯，就会沿着这条路走下去。blog带给我很多：文字表达、朋友，机会、思考的习惯等等，因为这些好习惯，我“被成长”了许多。当然，也是因为懒惰，并不是所有有想法的东西，最终都成为了blog。

偶尔回顾一下自己写的blog是件很有趣的事，看看曾经的思考，回味着当年的经历，虽然有时会觉得当年的自己很浅薄，但那毕竟是自己走过的路。也许再过几年，回头看今天的文字，也会有相同的感觉。

做咨询，我知道了，不要轻易的对一件事说不可能。六年的blog经历告诉我，只要坚持就可以。坚持六年，我做到了我曾以为不可能的事情。继续！

故事一：
我与一个人讨论SVN分支合并管理策略。

我：SVN分支合并是每个开发人员都应该掌握的技能。
对方：我担心，让每个开发人员操作太危险。
我：那就找个人来专门做。
对方：我担心，这个人成为瓶颈，效率太低。
我：那你说怎么办？
对方：……，我也不知道。

故事二：
同样是SVN分支。一个负责产品版本管理的人与我讨论版本合并的问题。

我：这个问题可以用SVN的分支解决。
对方：但是，SVN分支有问题。
我：有什么问题？
对方：我们公司负责SVN支持的人说有问题。
我：有什么问题？
对方去打听了一下，得到回答是，70%是人为操作失误。
我给他演示了一下版本合并的功能，没有任何问题。
对方：听说你们同事也在那边，你可以问一下。

我给同事打电话。
我：听说你们那边SVN分支有问题。
同事：你听谁说的。
我：我们这边的人，说70%是人为操作失误。
同事：我告诉你吧！不是70%，是100%。他们把两个不同源的东西往一块合，不出错才鬼了呢！

在我的全程陪护下，他们完成了第一次版本合并，没有任何问题。

故事三：
JavaEye上有个帖子：我总觉得XP带着一种不太切合实际的浪漫主义

发贴人长篇大论了一番，然后抛出一个“惊人”的结论。gigix问了一个问题，你做过没有？得到答复是没有。

小结
很多问题不是靠想就能解决的。没能力解决问题不是你的错，出来吓唬自己和别人就不对了。