加入前我有过惶恐，担心自己不能适应，这过去的三个季度，我开始慢慢淡定。我越发觉得，TW真是卧虎藏龙的地方，我需要更加不断地审视自己，发觉自己需要提高的地方，这样我才不会太过懈怠，不然落后只是时间的问题。我又觉得遗憾，又觉得欣慰，这是我第三份工作，方才让我有自省的惊醒，工作七年后才有这样的际遇，但七年对于我这样愚钝的人也不算太晚吧。

2011年我在豆瓣上记录自己读过的书，和看过的影视。记录表明，我看了30本书，数量说得过去，但种类芜杂，经典太少，随性跟风阅读居多。我的阅读品味是个问题了，需要纠正。好在我们现在有ThoughtWorker导读了，我可以借助聪明的大脑。跟阅读比起来，娱乐就显得大方许多，我看了40部影片。

2011年，我在ThoughtWorks做完了一个项目（惊异地发现这似乎是我工作以来完整做完的第一个软件项目，由此可见软件行业乃至国内这个环境下，我们的程序员接触的都是什么系统呢？）。我策划发布了ThoughtWorks文集的2012版，也是第三辑。我还和同事贾永娜合译了《Individual and Interaction: An Agile Guide》，今年上半年会出版。在年末的几天，我开发了一个公司内部用来请假的移动小应用，基于jQuery Mobile，简单直接，快速开发。我很喜欢这样规模的应用，我也相信WebApp会在2012年大放异彩。

目标只有可衡量，回顾起来才会有成就感。的确。

从加入ThoughtWorks开始，工作的压力骤增，让我不得不在坚持了几个月后，请辞了InfoQ中文站的原创主编，从琐碎细致的例行任务中解脱开来。作为从InfoQ中文站建站开始就参与的贡献者之一，我对她有深厚的感情。2011年我投入不足，在2012年我会继续投入。已经确认，在2012年春QCon北京我会担任组委会成员之一，负责组织和审核讲师及分享的主题。我还会是“分布式协作”Track的主持人。

在2012年，我会继续策划ThoughtWorks文集的第四辑，我需要的只是邀请合适人来写写文章，这里的人让我很放心，你不知道他们是一群多么乐于分享的工程师们！

我会继续POSA第二卷的翻译，和我的同事们。在2010年，加入ThoughtWorks的兴奋让我贸然接下了两本书的翻译，后来证明我的精力根本不够，所幸的是第一本小册子（上面提到的那本）已经提交出版社编辑。今年只需要关注在POSA这卷经典上了。

2012年，我期望能向九强学习一下摄影，为无聊的自己增添一些生活情趣。我还希望自己能掌握一些Excel的技能技巧，年底跟同事策划内部的Vacation System时才发现，很多事情我们作为程序员都想当然地考虑复杂了，我们即使自己没拿着锤子，也把所有问题都看成钉子了。演讲技能，是任何时候都需要磨练和提高的，幸运的是，现在有擅长此物的同事可以请教，而且知道哪来的天才和10000小时的理论后，所需要的就是不断的练。

如果只是上面这些，对于现在的我不能有一点满足。前几天中午跟Sponsor吃饭，回来进电梯前，他问我：“你觉得你目前最急需解决问题是什么？”我一时语塞。我后来说是Client Facing的能力，毕竟这是我目前收到Feedback谈到最大的问题。我觉得Sponsor和我自己对这个着急的答案都不置可否。

加入ThoughtWorks以来，我越发觉察，我需要的是一次对自己思维和能力的全面革新。

1. 独立思考的能力。不能说现在没有这样的能力，也不能说看问题不够全面，就是觉得不那么到位。长期遭受信息过载的困扰，不能自拔，而懒惰又拖住自己躺在舒适区，不愿做立下的改变，进而失去培养独立思考和解决问题的能力基础。长期困扰于此，解决办法会是什么？我想是注重阅读和与人沟通学习。心智成长和思维并重。
2. 计划性和冷热病。我做事情一般缺乏计划性，有了粗略的计划却很难执行好，客观原因是计划的不好，但主观是缺少对计划调优的热情。事情有时计划了，却搁在一边独自娱乐去了。对于目标，没有足够的坚持和热情，很容易开头雷声大，后头雨点小，而且呈周期性，最后连自己都气馁了。这里一个突出的原因就是，我的context的频繁切换导致新鲜劲儿很快过去，计划自然成空了。所以2012年，控制自己context切换是一个重要的目标，远离微博，聚焦注意力。
3. 承担责任。从我收到的Feedback看，我很容易抓不住一些显而易见的承担责任的机会。这个比较tricky，同事认为是机会是责任，我自己却意识不到，或者意识到了也做不出来，或者不愿意去承担。看来还是嘴皮上动动容易得多，行动起来却不是容易做到的。
4. 知识体系。ThoughtWorks奉行的是一整套的理论和实践体系，而且这本身还在不停地发展。如果通过实践和学习，将它们沉淀为自己的知识体系，是每个咨询师都要面对的问题。

在ThoughtWorks有一种被“夹持”成长的氛围，enjoy吧！

嗯，2012年，我还要勤奋地Blogging。

厌恶大公司繁文缛节的人
厌恶低效无谓加班的人
厌恶没有进步空间的人
厌恶盛气凌人的老板的人

想用上最新版MacBook Pro甚至Air的人
想每天吃到新鲜水果喝可乐的人
想每天可以打PS3和街机的人
想每天都有session听的人

不想把薪水放在第一位的人
不一心追求升职的人
不沽名钓誉的人
不畏惧变化的人

devops is an emerging set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals. It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization’s goal of rapidly producing software products and services.

– from Wikipedia, http://en.wikipedia.org/wiki/Devops

简单的说，DevOps是一组原则、方法和实践的集合，用来改善软件研发和IT运维之间的沟通、协作和集成，从而让软件产品和服务以更快的速度发布。

这里的快不是真正的目的，真的目的在于终端用户不会察觉到快速交付带来的不爽（质量、性能、安全性变差），而是享受到版本变化带来的更优质服务，这样才能让软件企业立于不败之地。至于为什么要快，我不说，你懂的。

一边要快，一边要稳定。说到稳定，就没法把运维避开不谈了。所以DevOps就是试图消除软件研发和运维之间的壁垒，让二者结合为更高效的软件交付团队。

DevOps涉及到什么？

DevOps是基于Agile的理念，并试图用Agile去影响其他部门、团队和实践。这里涉及到Agile和Lean中各式各样试图提高效率、消除浪费而采取的过程式、理念式、工具式的实践。可以包含但不限于以下内容：

• 让开发人员和运维人员交叉参加部门会议
• 让开发环境与运维环境保持一致
• 自动化任何运维过程可以自动化的过程

如果有人或者公司说，用了我们的blabla产品，就是DevOps了，这只会引来明白人的窃笑。这个效果，基本和说我们每天都Stand Up所以我们就是敏捷也可以跳舞一样可笑。

在我看来，实施DevOps最后要面临和解决的依然是组织和人的问题，这是文化和价值观信奉的差别，与具体的产品和项目无关。我甚至预见，DevOps因为会涉及到不同业务部门，而不像敏捷只会局限在研发单一部门内，反而更难实行。所以，可以想象，在怎样的情形甚至逼迫下，会有怎样类型的企业会去追求真正意义上的DevOps。

扩展阅读：

• http://www.infoq.com/cn/devops/
• http://www.infoq.com/presentations/DevOps-for-Business
• http://gigix.thoughtworkers.org/tags/DevOps

经常被用来区分软件架构和软件设计开发的关键几点包括 伸缩性和抽象程度的增加以及作出正确设计决策意义的增强。软件架构是通过一个全局的观点，宏观的视角来理解软件系统作为一个整体如何工作。

要成为一个软件架构师并不是一夜之间或者一个职位的提升就能简单达到的。 这是个职责，而不是头衔。这是个进化的过程，你将会逐步得到担当这个职责所需的经验和信心。

当你寻找架构师时，需要考虑各方面的素质，他们过去的经验往往是他们有能力担当这个职责很好的判断。由于软件架构师的职责是多种多样的，所以你需要再深入了解他们在不同领域的参与度，影响力，领导力和责任感。一般来说，在大多数项目中软件架构可分为两个阶段，架构的定义，然后是它的交付。