梦想风暴

谁是最受程序员欢迎的雇主？

一篇关于最佳雇主的帖子，很高兴在里面看到了ThoughtWorks的名字。

很快，成为ThoughtWorker就要满一年了，这一年时间里，我一直享受着在ThoughtWorks工作的乐趣。确实，它和我之前工作的环境差别很大：开放的工作环境、没大没小的工作关系、不利于保持身材的零食、需要排队的游戏机等等。这段时间一直在考虑一个问题，对我而言，ThoughtWorks到底好在哪里。思来想去，我的答案是人文环境。

依然记得当年，我在当时的部门里发邮件尝试与大家讨论技术，应者寥寥；
依然记得当年，有人劝我放弃所谓新鲜想法，老老实实走在原来的道路上；
依然记得当年，有人对我说，只有做管理才有更大的价值，怎么你对管理一点兴趣都没有；
依然记得当年，我们把“以人为本”作为笑话来听；
……

我也依然记得，当年选择软件开发作为职业是因为热爱；
我也依然记得，当初遇到Darwin点燃了我对技术的热情；
我也依然记得，在本应完成一个功能的时间里完成整个系统重写的快感；
我也依然记得，修改别人留下的bug缠身的程序直至深夜；
……

用了自己职业发展的最初几年，我逐渐清晰了自己在职业发展路上的追求。我会努力走在自己预期的路上，如果环境不能再给予我所需要的，我会寻觅其它的环境。

在这里，我得以继续走在技术的路上；
在这里，身边有一群有想法的人，让讨论可以深入下去；
在这里，总有人能在不同的角度给你一些新鲜的东西，让我不得不偷偷去补各种各样的新知；
在这里，可以和有很多年的工作经验的人一起工作，学习他们解决问题的思路；
在这里，完成功能绝对不是开发的终点，大家总是竭尽所能让程序看上去更清晰；
在这里，关注用户价值会成为程序员也要思考的问题；
在这里，我有机会体验不同的角色；
在这里，我终于弄清楚了leadship和management不是一回事；
……

幸运的是，我坚持了自己的选择；幸运的是，我成为了ThoughtWorker。

是的，我在学习Rails。

我所了解到的，大多数人是因为Rails而学习Ruby，像我这种了解Ruby却对Rails一窍不通似乎是异类。道理上来说，传统的途径应该是先学语言，再去了解相关的开发框架，像Rails这样喧宾夺主的情况，也算是异类了。当然，也正是因为Rails的喧宾夺主，才让人们有了更多的机会认识Ruby，了解Ruby的优雅。

趁着我还不那么了解Rails，把Rails留给我的初印象记录在这里，算是一个初学的记录。

Convention over Configuration（CoC），这是Rails广告给我留下的最深印象。这是一种改变业界对软件开发认知的思想。如同Spring让我们认识了Dependency Injection（DI），进而改变了我们的设计方法。Rails让我们认识到，原来有时候程序设计并不需要那么灵活。一片惊呼之后，效仿者蜂拥而至，人们纷纷尝试把这个想法带到自己熟悉的平台，其场面与Spring当年带来的DI容器热如出一辙。

如果Spring只有DI，它并不会带来真正的变革，同样，Rails也不是只有CoC。在我看来，CoC之外，Rails还集成了Web开发的实践。

Web开发实践有哪些？首当其冲的自然是MVC的架构，所以，在Rails中，明明白白的在目录结构上就把MVC分得清清楚楚。不过，我们还是抛开MVC这种路人皆知的答案，看一些具体的东西吧！

用Java写Web方面的应用时，我最担心的问题是如果一不小心上了某个框架的贼船，比如Servlet，结果就是为了看到自己程序能够正确运行，不得不把应用部署到服务器上。一旦出现了问题，解决问题就变成了一个非常低效的过程，因为我们不得不一次又一次的进行部署，大好的年华便随风而逝了。所以，对我而言，做Java应用的设计时，一个指导性原则就是尽量不依赖于任何框架，这样，就可以把真正的逻辑剥离出来进行测试了。初涉Rails，我也有类似的疑问。但我发现，原来Rails框架本身已经替你考虑好这个问题，它把测试的考虑也内建到框架之中，这样便可以很容易的针对每个Controller编写测试，而又不必理会部署的消耗。

Rails在测试方面有很多的考虑，它清楚的分出为Model而写单元的测试，为Controller而写的功能测试和跨越Controller的集成测试，而Fixture这个概念的存在，让我们很好解决测试数据的问题。这一切实际上都是一些优秀的软件开发实践。实际上，像这样的实践，Rails开发框架中还有很多，比如，如何处理页面布局、如何使用Ajax、如何管理数据库的迁移、如何让自己的应用Restful等等。使用Rails，不经意间，我们便可以走上一条正确的路。同许多开发实践一样，单独来看，这些做法本身并看不出多大的价值，但放到整个软件开发过程之中，便可以极大的提高开发生产率，尤其是在后期维护阶段。

不同于之前用过的一些框架，需要在实践中摸索正确的用法，Rails是第一个让我强烈的感受到开发实践内建其中的框架。只要走在Rails的道路（Rails Way）上，那么无论如何都不会偏离正确的方向太远。正确的道路何在？不得不提起《Agile Web Develpment with Rails》（中文版《Web敏捷开发之道》）。技术，常常是养在深闺无人识。其实，这个世界上一点都不缺好的想法，好的做法。我们经常会看到一些新东西让我们感慨，原来还可以这么做，但是，大多数时候，我们并不知道这些东西的存在。这本书的出现，恰到好处的向人们展示了Rails的优秀，比如前面提到的那些实践。不同于很多板着面孔教育人的计算机书，这本书轻松愉快的把一个完整的开发过程展现在人们面前。大多数人几乎是同时认识这本书和Rails框架的，所以，几乎一开始，Rails一族便走在正确的道路上。

不过，Rails还很年轻。年轻的结果就是不稳定。《Agile Web Develpment with Rails》第一版和第二版之间号称有70%的变动，而Rails 2.0又让第二版中的程序遭遇起步停车，一开始便会有差异。有些时候，这会打击初学者的积极性，也会让希望采用Rails的企业望而却步。

这便是我对Rails的初印象。

我的程序人生是从微软的技术起步的。虽然那时已经是Windows的年代，但是目光的局限，让我依然还是在DOS上下了一些功夫。也是因为从DOS出发，后来顺理成章的进入了Windows开发的行列。那时候的我是很努力的，不断的探索着各种各样的技术实现，不断的阅读着各种各样的书刊杂志，也着实记住了一些所谓的技术。不过，有个问题一直困扰着我，我觉得自己记住的只是一些形，而非神，这些形的东西是很容易忘记的，所以，我一直觉得自己并没有真正的理解编程，我甚至一度怀疑适不适合做开发。

真正让我开始觉得心里踏实是以程序员为职业之后。我的职业之路起步于Java，做的是服务器端的开发。跨平台的Java让我的目光不在局限于微软的平台，而服务器端的开发，让我有机会更加关注软件设计本身，而并非花哨的表现形式。随着开发越做越多，我逐渐开始摸索到了一些共性的东西，对自己的程序人生充满了信心。

走不同的路，得到的结果差异会很大。从上面提到的我个人的经历反映出在不同的技术社区内的不同倾向。记得有人说过，微软社区更倾向于探究底层实现，而Java社区更关注设计架构。其实，差别并不只这些，比如，微软的技术社区倾向于追踪新技术，因为几乎差不多每隔几年，微软就要把自己的东西推翻了重来，从DOS到Windows，再到.NET的变化，而Java社区的人则是在一个稳定的基础上不断的发展。微软是为了商业上的发展，所以，它要不断推陈出新，而Java也有变化，比如EJB到without EJB，但决定因素多半是技术上的，而非商业上的。

如我前面所说，微软社区有很多人关注的是一些细节上的实现，所以，造成的结果是他们不得不在茂密的技术丛林中不断摸索，而无暇顾及其它。我们公司内部，有一个技能列表，上面记录着哪些人会哪些东西，比如Java、.NET、Ruby等等，这样方便做项目时进行资源调配。其中有一个有趣的现象，只拥有一项技能的开发人员大多都属于.NET阵营。而Java阵营的人，经过最初的探索，会发现原来自己学到的东西是可以用在很多其它的地方，于是他们的触角开始伸向其它地方，比如JavaEye这个以Java命名的网站上会有很多关于Ruby的讨论、关于函数式编程的讨论、关于Erlang的讨论，这些东西少有会对Java开发本身产生直接的帮助。

如果已经从最初的阶段突围而出，或许，这些差异并不重要，因为我们做事靠的是自己的方法和一些共性的东西。但对于刚开始成为程序员的人来说，并不知道这些差别的存在，一个人的见识有限时，他会认为自己见到的就是整个的世界，就像我刚开始编程那会儿。

其实，我觉得最适合编程起步的应该是Unix开发。这些年里，很多出自贝尔实验室的书，比如《Unix编程环境》、《程序设计实践》、《C程序设计语言》等等都是在探索软件开发本质的书，而Unix的诞生地正是贝尔实验室。Eric Raymond写过一本《Unix编程艺术》，品味之下，便不难发现，许多随着Unix而生的是做事的方法，而这些方法并不是把人限制在Unix这个具体的平台之上，而更多的是一种通用的软件开发理念，拥有了这些理念，即便进入了一个陌生的领域，只要稍加学习，从前的感觉便会回到身边。

起步固然重要，不过，即便起步并非一帆风顺，如果抱有一个开放的心和一个思考的大脑，最终，都会走上同样的开发之路。

休完了春节长假，回来上班了，整个人懒洋洋的，长假结束之后的正常反应。我给自己定下假期基调就是，尽可能让自己的脑子不去想太技术的东西，也算给大脑放一个假，所以，恢复到正常的工作状态，还需要调整一下，呵呵。

假期里，看了《疯狂的程序员》。以前，很爱看这种程序员的故事，尤其刚刚开始学习编程的时候，特别想了解一下别人是怎么一步一步提高的，因为那时候，我并没有体会到真正做个程序员是怎样的感觉，于是，总是希望可以从那些故事里面得到一些值得借鉴的地方。可以说，这种故事中体现的那种激情是鼓励着我不断前进的动力。如今，我做程序员已经开始奔向第六个年头，逐渐有了一个相对清晰的发展方向，做一个程序员的酸甜苦辣也品尝了不少。如今，再看这种程序员拼搏的故事，更多的是为了怀念一下自己的青涩年代。

虽然，彼此的故事不同，但初学编程时那种努力、那种奋进是相同的。还记得刚开始工作的时候，我硬生生的照着协议写出一个SMTP的实现，所有的代码都放到一个文件里面。现在，依稀记得成功把一封邮件发送出去的时候，自己那种激动的心情，用我现在的说法形容，那时候的我，生猛。随着工作经验增多，做事更多的是在找最短路径，如果现在再让我去实现一个SMTP，我笃定是找一个已有的实现。青涩的自己，虽然很笨，却是最有干劲的，也是那时候培养出对程序的激情和热爱，让我可以在程序设计这条路上不断走下去。

刚刚回来，看到一个Da Vince Machine的项目，简而言之，为JVM增加更多的功能，主要是为了支持动态语言的特性。虽然并非这个项目的所有内容都会最终进入JVM，但它确实是一个有益的尝试。

其实，这个项目算不上新项目，关注这个项目领导者John Rose有一段时间了，因为他为在JVM上增加动态语言特性做了很多工作。之所以注意到这个项目，是因为InfoQ的一篇报道。这篇报道中，不仅仅提到了JVM，还提到DLR。

从文章的叙述来看，DLR是建立在CLR之上的。这种做法给我的感觉是，它类似于XRuby的做法，在JVM上自己建立运行时。虽然不是不可以，但这种做法的性能肯定不如直接修改虚拟机，毕竟还差着一个层次。这是一种半调子解决方案，如果是站在平台之外来看，这种方法还不错，但是，作为平台开发者的微软，这么解决问题，就显得有些不靠谱了。也许它只是为了尽快的推向市场，赚些噱头吧！毕竟这种做法可以在尽可能小的影响现有系统的情况下实现。从长远来看，如果DLR能够在未来取得一定进展，如果它还想好的话，它会转向修改虚拟机这条路的。

又是一年，开始工作了！

PreferDesignSkills
InfoQ评论英文版：Prefer Broad Design Skills over Platform Knowledge
InfoQ评论中文般：丰富的设计技能胜过特定于平台的知识

我对程序设计语言有着偏好，所以，我喜欢不断接触各种新语言，喜欢研究语言背后的实现。

最近一段时间，我做的项目用到的几乎都是对我而言的新语言：C#、ActionScript、PHP……，这等价于我要不停的学习自己新语言。

我很享受学习新语言的过程，因为它们会带给我一些不同的体验。每一种语言都有自己不同的适用范围，这一点在学习像ActionScript和PHP这种有很强领域色彩的语言时，体现得尤为明显。运用这些语言写程序的过程中，很容易体会到语言作者在设计时的侧重。

学习新语言，某些情况下也有一些让人难受的地方。经常是，程序出现了语法错误，却瞪眼看不出来，突然意识到错误所在，原来自己用的是熟识语言的语法，不禁莞尔。有时，语言或程序库与自己熟悉的习惯不相一致，经常会被绊住一段时间。

好吧！回到开头，Martin说，设计技能更重要。我想说，设计技能只是很重要的一方面，更多的还是自己做事的方法和习惯。跨越语言时，对此体会会更加深刻。

最近是在写一些PHP代码，我完成一个功能的过程大致如此；弄清楚自己要做的是什么，想一下大概应该如何实现，用PHPUnit编写测试，然后完成功能，运行所有测试，确保这个实现正确以及没有破坏任何已有的东西。把PHP换成其它语言，相信过程是类似的。

如果你有机会像我一样在语言之间穿梭，在度过最初的痛苦期之后，你会发现一切会回到自己熟悉的轨道上。设计、编码、查文档、测试，没有什么不同，所做的一切，都是把自己的想法落实成代码，只不过，由于语言的差别，落实成具体的代码，形式上略有差别而已。

当然，我们不是教条主义者，不只是简单粗暴的知识映射。语言和语言之间是有差别的，所以，学习语言时，我们会注意到语言为我们提供的便利，比如，动态语言的特性，比如，函数的抽象等等，这样我们可以更好更优雅的完成我们的工作。