再见ThoughtWorks！

已经很长时间没有写blog了。最近的几个月时间里我的工作和生活都发生了较大的变化：因为家庭原因，我离开了生活了六年之久的北京，来到了上海和妻子团聚;同时，我也因此而离开了 ThoughtWorks ，加入了设计软件公司 Autodesk 。

回首过去的几年时间，我能很清晰地感觉到自己对软件开发的认识不断地发生着有趣的变化：

六年前

• 眼中只有C#/.NET/Windows，“外面"的世界？连想都没有想过
• 对版本控制工具几乎毫不了解，顶多也只是在朋友的推荐下用用VSS。依靠文件拷贝来备份，不知丢过几次源代码
• 长长的方法 :P
• if-else/switch case
• 在面向对象的幌子下写着并不纯粹的面向过程代码，自己却浑然不知
• 界面和业务逻辑代码混在一起
• 项目完成==软件功能开发完成
• 对微软崇尚备至，做梦都想加入微软

三年前

• C#/.NET/Windows，但已经开始不满现状，希望具备多平台、多语言的开发能力（如果你手里只有锤子，那么你会希望所有的问题都是钉子）
• 面向对象很简单，不就是为主要的业务对象建几个模吗？
• 所有的项目里都会大量地写Helper/Manager
• 真正的业务对象仅仅是一些没有实质行为的纯数据载体
• 很在乎自己用什么设计模式，最常用的却是Singleton和Factory
• （几乎）没有封装
• 以能够做出复杂的软件设计为荣
• 带了好几个项目，但所有的项目都解释不了一个问题──为什么软件的质量永远无法保证？
  • 开始思考为什么软件写到一定程度以后就会很难维护
  • 开始思考为什么软件的质量只能通过大规模反复测试和加班改bug来解决
  • 开始思考为什么单元测试看似无法应用到实际的项目中
  • “这个建议很好，但是我们的项目进度很紧，所以……”
  • “测试会增加开发人员的工作量……”
  • 开始疯狂地寻找解决办法，开始疯狂地自学TDD、单元测试、持续集成这些敏捷软件的实践
  • 结果发现仅靠自学是永远不可能真正领悟到敏捷的实践
  • 决定去ThoughtWorks取经
• 版本控制==Subversion
• 软件完成==开发完成+通过测试及客户验收+团队成长

现在

• 面向对象很难
  • 封装！封装！
  • 在多个项目上或好或坏地实践了面向对象设计，但到现在还感觉自己仍是面向对象的门外汉
  • 一切皆是模式，一切皆非模式
  • 对Singleton有一种疯狂地抵制，两年半里从来没写过一个Singleton，而且预计将来也很难
  • 面向对象不是唯一的解决方案，在一些特定领域里（比发并发处理）其它的设计思想（比如函数式编程）更具竞争力
• 以能够做出简单而有效的软件设计为荣
• 经历了多个成功的敏捷开发项目的实战，亲身体验了什么叫做有秩序、高质量、低成本的软件开发
  • 充足的测试、良好的封装、有效的沟通是提高软件可维护性的有效手段（全世界都知道，但只有少数团队真正用心在做，sigh……）
  • 近三年之内的加班次数超不过十次
  • 软件发布阶段团队却无事可做，只好提前开发下一版本
  • 项目进展的从容不迫使我有了大量的业余时间投入到开源世界
  • “这个建议很好，我们来试一下，这样就能进一步减缓项目进度的压力”
  • 有效的测试会帮助开发人员提供软件质量的反馈，帮助整个团队提升软件质量
• 写代码前不写测试就会极度不安
• 离开IntelliJ就不会写Java，离开Resharper就不会写C#
• 开发、办公、日常操作平台从Windows转到了Linux和Mac，开发平台从.NET转到了JVM
• 习惯于和同事们以微软为反例来相互取笑 ;)
• 自动化！自动化！甚至连发布blog都是如此
• 对版本控制和持续集成有一种宗教般的热情
• 版本控制==Git、Mercurial
• 软件完成==开发完成+通过测试及客户验收+团队成长+产品维护+分享（写文章、blog，总结出通用框架、工具，演讲……）

多年以后

我不知道三年、五年、十年以后这份清单会变成什么样子，但是有一点是可以肯定的：在ThoughtWorks的这段经历使我更关注问题本质、更注重解决方案的实效性，并且不轻易屈服于事物的表面现象而努力寻找并尝试改变。ThoughtWorks教会了我用敏锐的眼光去观察身边日复一日的软件开发活动，在平淡之中追寻软件开发的乐趣，在惯性思维的种种借口之下取得突破。

再见，ThoughtWorks！