OO训练营第一课

今天下班前,开始第三届OO训练营的第一课。

本来觉得应该没什么,结果课堂上大家窘态尽出,会写代码不代表面向对象代码写的好,事先不写测试,直接上实现,情何以堪呐。

一些重点:

  • 代码是写给人看的,不是给机器的。代码是用来表达和传递知识的。
  • 对于可度量的对象,有几个属性(比如相等性和可描述性),可以作为分解任务的依据,并据此编写测试。比如长度(Lenght)的Equality,如何判定是同一个长度对象,如何比较不同的长度对象。
  • 测试优先开发,划分出可测的任务是关键,即所谓Testability Driven Tasking。
  • 模块化最重要的是封装实现的细节,对类细节的访问要封装在类上下文中,这是最最容易忽视的bad smell。

TWI is Over

Today, we finished 3-day TWI(ThoughtWorks Immension) in ThoughtWorks China, which is also the sixth TWI here.

4 people from Xi’an office also came with us, and we spent a good time together. I have now a deep impression on the company culture, Agile Methodology, and a more closer observation on the story things and xp practices. All of what we saw and heard differentiate a lot from what we did before in a more traditional way. This introduced too much dicussion and questions, which even blocked the progress of courses.

Good to see this happened, when TW China grows up and attract more and more experienced people, it has to embrace and absorb those who are willing to join after survived from bad software engineering career, with its own special culture. I believe these people are here not wishing to get satisfying salary or anything, but to see how and why software engineering works here and people are happy at the same time.

I am shocked totally when teacher told ThoughtWorks company is actually a social experiment by Roy Singham, founder of company. I believe I will be shocked time and time when I understand more about company.

I am very pleasure to be the witness for this experiment is ongoing, and hopefully it will be successful.

Pair小记3——争论

Team的人员组成各不相同,有可能是经验丰富的团队,也有可能有将近半数的新人。这样对于有交付压力的项目来说,采用怎样的技术栈会有不同的观点。有保守起见,不愿意引入复杂框架的观点,也有要努力利用成熟框架学习新技能的想法,何去何从?

Well,这是一个team,自组织的团队,区别在于这样的争论可以让整个team的人来加入来选择,来承担可能好可能坏的结果。

更有帮助的是,可以咨询具备丰富实践经验的来自团队外的专家。然后还是由团队自己来决定。

自组织的团队让我很消受,Who is Boss? Who care!

吉祥三宝TW版

吉祥三宝TW版—

小女孩问:“爸爸,你的code写好了吗”
爸爸回答:“没有。”
小女孩问:“你的pair去哪里了?”
爸爸回答:“在天上。”
小女孩问:“你们发疯coding为了什么?”
爸爸回答:“拯救苍生。”
女儿爸爸合:“济济苍生以软件,担担道义为世范呀。”
小女孩问:“妈妈,爹当码农为了神马?”
妈妈回答:“基业永续。”
小女孩问:“他跟别人怎么不一样呀?”
妈妈回答:“止于至善。”
小女孩问:“别人会尊敬他吗?”
妈妈回答:“等到春天。”
爸爸妈妈女儿合:“不以利回不以义疚就是我们的信仰。”
爸爸妈妈问女儿:“宝贝,你也学你老爸搞软件吧?”
女儿回答:“那妈妈呢?”
爸爸妈妈回答:“妈妈正在面试骚窝的路上。”
女儿回答:“那我呢?”
爸爸妈妈回答:“你像种子一样正在发芽。”
女儿回答:“掻迪斯嘎。”
爸爸妈妈女儿合:“我们三个就是贵司幸福的一家。”

不得不景仰了。。。

Pair小记2

今天Pair遇到的问题是,我跟我的Pair在某一个问题上纠结太久,没能找到解决的方案。这是一个很典型的问题。

浏览器兼容的问题,历来让前端开发头疼。再加上是遗留系统,页面上引入了太多了三方和自己的js导致IE下页面无法显示。

看得出,我的Pair对前端开发经验不多,而我又不能一下子指出问题所在(可恶的IE),Pair自信心比较高,会很坚持用自己的方式来解决,他试图修改一些JS的内容来减少业务逻辑的涉入,以测试能否在IE下显示完整。而根据我的经验,这种IE特有的问题多半是某些JS语法的(不兼容)问题,但办法只有从上到下一个一个JS的排除,直到找到问题JS。Pair的做法引入了业务逻辑变化的不确定性,背离问题本身,反而容易引入更复杂的变化。

可惜我对Pair时所应有的态度和精神体会不深,尝试过说服Pair,但见他坚持,不忍冲突,结果是时间白白浪费。

回家路上跟彦辉君聊到此事,他的建议是:
1. 寻求技术帮助
2. 正义提出自己的想法
3. 如果2不可行,寻找更具说服力的力量

还是需要一种Open的态度。

小步前进

敏捷、Scrum和XP实践里面,到处体现着小步前进。

比如代码重构,这在Martin Fowler的书里面处处谈到,在没有IDE的refactoring功能的帮助下,唯有手头的小步前进,才能保持信心。

持续集成,每次checkin触发一次集成过程,快速的反馈和修复,同样保持信心。

每个Sprint给客户showcase,让实现和需求不偏离太远,才会进入下个迭代,这仍然是个增进信心的过程。

真是欢乐啊!

Pair小记

今天跟凡哥pair,遭遇CXF的蹂躏。客户遗留系统糅杂了JAXB,CXF诸多Java EE和web service“高端”特性,调试很难,好不容易找到负责(反)序列化的XmlAdapter实现,才看到遗留系统工程师编写的奇怪正则表达式,过滤了本不该过滤的字符串,导致web service接收端接收数据不完整。

一边pair,一边感叹,Java的企业应用现在如此复杂,Java技术发展已经背离了最初解决问题的初衷。Java出路在哪里呢?

采访:Maven贡献者、《Maven实战》作者许晓斌

1. 首先,请您介绍你自己,从什么时候开始你从事Maven的推广工作,以及你现在在做些有什么有趣的事情呢?

我从07年开始接触Maven,慢慢学习并在实际项目中推广使用,然后慢慢喜欢上了这个技术。1年之后我开始编写Maven中文博客并翻译《Maven权威指南》,并且维护了一个Google Group,我想这些事情对于Maven在国内的推广起到了一定的作用。也正是由于这些工作的关系,我有机会熟悉Maven的方方面面,并加入了Sonatype —— Maven之父Jason Van Zyl创建的公司。

目前我主要做两方面的工作,其一是维护Maven中央库Sonatype OSS仓库托管服务,该服务为开源项目提供免费的Maven仓库并帮助他们同步自己的构件至中央仓库。目前有超过600个项目在使用该服务,包括知名的JUnit、TestNG、Ehcache等等。除此之外我也参与Nexus的开发,开源的、商业的都有。

 

2. Maven 3刚刚推出不久,据说这个新版本在性能上有很大的提高。相比较以前的版本,你觉得最大的变化、最重要的新特性是哪些呢?

Maven 3发布的第一时间我就写了篇博客进行介绍,其实从性能上来说,抛开并行构建不谈,用户不会感受到很明显的提高,这是因为Maven本质上是将构建工作给其他工具来做的,例如编译用javac,测试用JUnit,因此给Maven的改进余地不多。使用Guice代替Plexus从一定程度上能改进性能,但不是很明显。我个人认为Maven 3最重要的改进是清理,包括代码清理和不良特性的清理,例如在Maven 3中,你使用插件不声明版本不会引入快照,而Maven 2就因为快照插件的问题被很多人诟病。此外,Maven 3的并行构建特性也让人眼前一亮,只要模块组织合理,多个模块能够得以同时构建,充分利用多核资源。

 

3. 在今年2月份,InfoQ有篇新闻是关于Maven 3即将采用Guice来作为新的DI层,请问这在Maven 3里面实现的如何?这对那些采用Maven的开发者来说,有着什么样的好处呢?

采用Guice作为DI容器最大好处在于标准化,Maven之前使用的Plexus历史也很久,但发展得很差,文档也很缺乏,转到Guice后,由于大家更熟悉,就可以吸引更多的贡献者。Maven团队也不再需要花时间去维护,有了问题,可以得到Guice社区的帮助。

Maven 3在采用Guice的同时还必须支持Plexus风格DI标注或XML配置,以兼容现有的数以百计的Maven插件。为此Maven团队基于Guice 2.0所支持的自定义注入器,开发了一个中间层模块,该模块包含一个匹配器来识别你的标注配置是Plexus风格还是Guice支持的JSR300风格,如果是Plexus风格则再应用额外的集成逻辑。实现的细节在这两篇博客中有介绍:The Guice/Plexus Bridge and Custom Bean InjectionCreate a Guice Bean Extension Layer

 

4. 在InfoQ的这篇关于Maven 3的新闻里,出现了很多开发者对于Maven的评价,可谓毁誉参半。作为Maven的推广者,你怎么来评价这样争论的存在呢?

关于Maven的争论从来没有休止过,类似的争论还可以找到很多。但有目共睹的是,越来越多的开源项目在使用Maven作为他们的构建工具。我想那些人反对Maven主要是以下三个个因素:

  1. Maven提倡约定优于配置,例如目录结构的约定,很多习惯高度自定义的用户受不了,于是当然就排斥。其实约定有很多好处,例如当你从一个项目转到另外一个项目的时候,你不需要学习另外一套结构。
  2. Maven的学习曲线陡峭,一些人花了时间去学习,但没体验到快乐就学不下去了,因此完善的文档很重要。
  3. 与IDE的集成,这方面m2eclipse的质量确实比不过其他集成如Ant,问题也有一些,但这些都在改善。IDEA对Maven的集成就相当不错。

争论还会继续,只要反对者能提出合理的需求,那就是Maven改进的空间。

 

5. 谈一谈你编写的即将出版的那本新书吧,名字叫《Maven实战》?为什么我需要这样一本新的Maven书呢?

由于种种原因,我翻译的《Maven权威指南》没有能够在国内出版,这是一个遗憾,很多人告诉我他们自己打印了那本书看,这让我很感动。我很希望国内能有一本印刷上市的关于Maven的书,这是我写《Maven实战》的最原始动机,后来我发现借助这个机会,我能将书写得更接近国人,包括语言的组织,以及内容的安排。例如在《Maven实战》一书中,我介绍了使用Maven进行自动化部署,以及结合Hudson进行持续集成等内容,这些内容都是我实际体会到大家迫切需要的。前面说过,Maven的学习曲线比较陡峭,这是他的天生问题,弥补的办法就是提供完善的文档,对于初学者来说,这样一本书无疑能帮他们少走弯路,节省时间。

 

6. 请您给那些不甚熟悉Maven的开发者们一点建议,怎样才能又快又好的掌握Maven呢?

首先不要排斥它,很多人因为Maven有很多约定而受不了,其实Maven这样做能帮助你更规范的管理项目。其次,如果不要太依赖于IDE,IDE能做很多事,但在自动化构建以及持续集成这些方面他不擅长,试着多用用命令行,熟悉Maven命令的同时,也能更深刻地体会一些Maven的概念。还有要耐下心来读读文档,你买我的书看当然最好,想省点可以看《Maven权威指南》。最后就是实践啦,可以看看开源项目怎么用Maven的,然后在实际的项目中尝试,并使用Nexus建立自己的Maven私服。

利用tortoiseSVN在两个版本库间merge code

需求总是奇怪的,但好在有这么一个还算顺手的工具。

我有一份code base的两个不同版本库,这两个版本库所在的server是不一样的,然后对应本地有两个不同的Working Copy。我需要把一个版本库里面做的部分变化,merge到另外一个版本库。一开始想过用SVN命令行diff,但似乎那是服务于同一个版本库的不同branch的,也就是要host在一个server上的。

幸好在小乌龟里面发现了Merge revisions to…这个功能,具体做法是:

  1. show log版本库A
  2. 选择需要提取出change的revisions,可以多选
  3. 然后右键,选择merge revisions to…
  4. 选择版本库B所在的WC
  5. 小乌龟开始替你干活,能自动Merge的会自动Merge,不能的会提示conflict

小乌龟干活有两个问题:

  1. 提示你有conflict时,你可以看到变化的对比,但有时并不真有conflict,这时可以选择使用全部覆盖或者忽略覆盖。
  2. 如果真的有conflict,注意了,即使在edit conflict时resolve conflict,目标文件也还是有问题,并未真的把conflict resolve掉,一试便知。这应该是小乌龟的bug,我用的是1.6.10。这时正确的做法是,发现的确有红色的conflict,选择resolve later,待这一轮Merge之后,逐个选择文件把conflict resolve掉。