Pair小记3——争论

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

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

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

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

Share
 

Pair小记2

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

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

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

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

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

还是需要一种Open的态度。

Share
 

Pair小记

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

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

Share