再见ThoughtWorks!

标签: 再见 thoughtworks | 发表时间:2009-12-01 16:00 | 作者:(author unknown) lnsoso
出处:http://feeds.feedburner.com/dyang

已经很长时间没有写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!

相关 [再见 thoughtworks] 推荐:

再见ThoughtWorks!

- lnsoso - Happy Hacking
最近的几个月时间里我的工作和生活都发生了较大的变化:因为家庭原因,我离开了生活了六年之久的北京,来到了上海和妻子团聚;同时,我也因此而离开了 ThoughtWorks ,加入了设计软件公司 Autodesk. 回首过去的几年时间,我能很清晰地感觉到自己对软件开发的认识不断地发生着有趣的变化:. 眼中只有C#/.NET/Windows,“外面"的世界.

聊聊ThoughtWorks面试

- - 梦想风暴
最近有几篇关于科技公司面试的新闻,这篇格外受瞩目,因为竟然有公司力压Google,成了面试最难的公司,而这个公司居然是ThoughtWorks. 这个结果真的让我有些惊讶,作为一个面试过许多人的ThoughtWorker,我之前还真没想过我们的面试到底有多难. 既然有人关心ThoughtWorks面试,我就不妨在此分享一下我的“面经”.

ThoughtWorks读书雷达-编码实践篇

- - 简单文本
期望通过四分之一的读书雷达图就能将与编码实践有关的优秀书籍一网打尽,自然是不现实的打算. 因此,我们希望就我们的侧重点来推荐书籍. 对于编码实践而言,我们共同认为培养良好的编码习惯,编写整洁简单而又合理的代码,是一名好程序员的基本要求. 因此,这里我们更强调与程序员基本编码技能相关的知识. 我们并没有给出与算法直接有关的书籍,虽然我们认为算法知识同样属于编码实践的范畴,虽然我们认为诸如《计算机程序设计的艺术》、《编程珠玑》、《算法导论》之类的书籍同样很重要很优秀;然而,我们取舍再三,仍然将它们划出了读书雷达的范围.

如何快速读Paper – ThoughtWorks洞见

- -
去哪里找paper之后,大家问我的问题就常常变成了:. 如何快速阅读一篇paper并准确的提取其中有用的信息. 在本文中,我将试图为大家简要解答这个问题,争取告诉大家如何在短时间内通过阅读文献的方式了解一个新的领域. 阅读一篇paper通常见的目的有四种:. 面对一个新的领域,我要快速把握这个领域的研究方向和state-of-the-art方法,来给自己或者团队设计一个大致的技术方案.

再谈敏捷和ThoughtWorks中国咨询师

- lishali - 酷壳 - CoolShell.cn
之所以用了“再”,是因为之前的两篇文章——. 我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法(虽然我心底觉得有时候有时候更像传销),当然,批评是没有意义的,所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议.

2013年的技术趋势 — ThoughtWorks技术雷达阅读笔记

- - I am Hu Kai
边界正在变的更加模糊,传统上办公室是工作发生的地方,我们需要内部网络来登陆邮件系统,访问公司的知识库,利用电话会议系统和处于世界各地的同事交流. 随着移动设备的普及,网络速度的提升以及越来越多的内部系统被迁移到同时提供外部访问的云平台上,工作正在从办公室扩展到生活的每一处,在出租车上,我们用手机阅读和回复邮件;在机场,我们使用Goto Meeting来和各地的同事举行电话会议;在客户现场,我们用手机访问Jive.

ThoughtWorks读书雷达方法学篇-张逸

- - 人月神话的BLOG
原文: http://agiledon.github.io/blog/2013/08/06/methodologies-of-reading-radar/. 方法学(Methodology)看似与开发技能无关,常为程序员忽略. 忽略意味着未曾察觉,却不等于它的无关紧要. 我们每时每刻呼吸的空气同样会被我们忽略,但空气不重要么.

Serverless实战:打造个人阅读追踪系统 – ThoughtWorks洞见

- -
阅读习惯和个人知识管理体系. 进入互联网时代,知识的获取成本变得前所未有的低廉,但是无论再好的知识,若是没有对个人产生价值的话,那也只不过是一种信息噪音而已. 我在《个人知识管理:知识的三种形态》这篇文章中使用“材料 -> 资料 -> 知识”这样的路径来诠释信息的流通,如何方便快捷并且有效地收集材料,再将其整理转化为有价值的个人知识体系结构,在这个信息极度碎片化的时代变得尤为重要.

微服务分布式一致性模式 – ThoughtWorks洞见

- -
微服务拆分后遇到的一个麻烦是分布后的一致性问题. 单体架构的业务处理和数据都在一个进程里面,一致性保障很成熟,开发人员基本上不用关心. 当把业务系统拆分到不同进程时,就遇到了技术性一致性问题. 这带来了纠结,我们希望有一颗银弹,一把解决问题. 但由于分布式一致性在(CAP)理论上没有完美的解决方案,我们所能选择的方案是在特定业务场景下的选择.

用DDD指导微服务拆分 - ThoughtWorks洞见

- -
对于服务拆分的逻辑来说,是先设计高内聚低耦合的领域模型,再实现相应的分布式系统. 服务的划分有一些基本的方法和原则,通过这些方法能让微服务划分更有操作性. 最终在微服务落地实施时也能按图索骥,无论是对遗留系统改造还是全新系统的架构都能游刃有余. 开发者在刚开始尝试实现自己的微服务架构时,往往会产生一系列问题 :.