模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。
作者 Mike Bria 译者 金毅 发布于 2009年9月26日 上午2时5分
最近几年,结对编程仍旧是最具争议的实践之一。支持者们不吝赞美之词,但是即使不少支持者都不得不承认他们自己公司真正结对编程都困难重重。为什么?Obie Fernandez给出了10个可能的原因。
Obie所在公司Hashrocket的两名员工Desi McAdam和Jim Remsik在《纽约时报》发表了一篇文章,大谈结对编程好处的,为此Obie回应了一篇令人深思的博文,概括了很多公司不能成功实施结对编程的10大原因。他首先澄清并解释他是非常认同结对带来的好处的,他认为”结对编程是Hashrocket里面最重要的竞争优势之一。”
接着他阐述道:“结对编程,尤其是完全100%地实施结对,他不得不逐步提醒大多数敏捷理想主义者:那条路对他们来说可能走不通”,他也解释了为什么。
Obie的列表(我在这里做了精简概括,但在你得出判断前,请完整地阅读一下他的文章),并不武断,引发来很多讨论,大部分都在他博文的那个长长的评论列表中。
Brian Guthrie花了点时间做了一份他自己的列表用来反驳Obie的观点。他这么说道:
Obie和他的公司Hashrockets提供了适宜的结对环境,但是很多初次尝试这一实践的人并不会有那种工作环境,而且你也不必都需要有那些。
他在列表里面罗列了他认为Obie遗漏或者不尽然的5项:
请花点时间完整地读读Obie和Brain的这两篇博文。很可能你自己的经验和想法与这些观点不谋而合。
查看英文原文:Opinion: Pair Programming Is Not For The Masses公司总会招些实习生或是经验不足的应届生,这时可以采用结对的方法,帮助新员工更快的胜任工作。另外,有些公司实行了导师制度,让导师和徒弟结对,也会有很积极地影响。
这种以老带新的结对,确实是不少项目采用的,也是有一定效果的。
不过结对讲究的是地位对等和思路互补,相互促进,这样才能1+1>>2。
新老结对这种组合,1+1可能=1.5或者更低,不过这属于培养新员工的必须投资的过程。
文章中说到的,比较切中要好,项目中可能缺少这种有激情、追求卓越、和睦相处、技能优秀的人才。
看了一下自己上面写的,这种人确实不是很好找啊:)
以前在学校ACM竞赛的团队,使用这种结对方式的,效果很好。
结对编程需要两个人都有非常好的素质,能够谦虚客观的看待别人的观点。新老员工的场景中,新员工——特别是应届毕业生——一般都比较好学,谦虚,容易接受别人的经验之谈,所以容易成功。但是如果水平接近然后结对的两个人有一方是那种很自大的人,在情绪上不容易接受别人对自己代码意见的话,那结对肯定效果不理想。我感觉中国在这方面的环境还不是特别适合这类的结对编程。
而且,完成同一个功能的代码可能不同人实现的方式是不一样的,假设他们写出来的都是很优质的代码。这个时候就需要结对双方都能够意识到并承认这一点。结对的本质是用两个人的大脑拼接出最优质的代码,如果代码已经是最优了,那就无需对这段代码妄加评论了。
但是大多数程序员都有强迫症(我自己也有一些),这表现在看不惯别人的代码上,总觉得自己的代码才是最好的。所以看到不符合自己风格的代码总是想强迫别人按照自己的方式来写。这是非常糟糕的。
都是老带新吧
支持地位对等和思路互补,结对目的是为了更好的代码质量和实现,需要的思维火花的碰撞;如果是老带新的话那是导师制度,更多的是传授。
“投资结对意味着投资工艺”,YES,工艺!
所以,最好公司的所有程序员都对什么是好的代码有一个统一的认识。这样结对才更有效
我也有强迫症
怎么办???
我喜欢在一个单独的办公室里面写代码,没人来烦我。
严重同意8,7,5,2。
1.我不喜欢在工作的时候身后/或旁边 有人盯着,有一种被监视的感觉
2.我不喜欢在我思考代码的时候,不时有人在旁指指点点,思路经常被打断也是很恼火的事情。
3.编码以为这要进行独立思考,而独立思考过程是一个私人的问题,有问题我们可以在专门的会议上讨论,但当你在分析处理具体问题时候总有人在旁边啰里八嗦的时候不知道你是否感到愉快。
4.总之,结对编程不符合人类思维习惯即行为习惯。
不知道有没有结对驾驶
结对下象棋
结对拧螺丝
结对写小说之类的
所谓观棋不语真君子大概就是这个道理
结对编程并不是一天8个小时都坐在一起。有些东西必须一个人静静独立思考,或者一些Research的工作,就没必要两人做在一起了。结对跟独立思考是不矛盾的。
至于有被监视的感觉,那就很奇怪了,也许是你个性问题,不够Open。
结对逛街购物不知道有没有结对驾驶
结对下象棋
结对拧螺丝
结对写小说之类的
所谓观棋不语真君子大概就是这个道理
只要结对的人不走神,两个人一起写出来的代码一般都会比一个人写出来的质量高、bug少,而且考虑的比较全面,这样就省去了后续一些代码检视、频繁修改代码结构、过多bug返工带来的工作量
改变习惯要有个过程,但是一旦新习惯形成,其效果不可同日而语。
此外我觉得老带新并不是结对的最佳实践形式。
改变习惯要有个过程,但是一旦新习惯形成,其效果不可同日而语。
此外我觉得老带新并不是结对的最佳实践形式。
总是老带新的话,老人就没提高没兴趣了
除非... 男女搭配,干活不累...
中国的基础教育善于培养独行侠,几乎没什么培养团队精神的内容。
拉力赛都是结对驾驶。。。不过有明确分工,中间没有时间交换位置嘛
1.我不喜欢在工作的时候身后/或旁边 有人盯着,有一种被监视的感觉
结队的人是你的同伴,不是你的老板。
2.我不喜欢在我思考代码的时候,不时有人在旁指指点点,思路经常被打断也是很恼火的事情
结对是两个人共同思考,讨论,两人的思维要同步或者互补。。你为什么非要考虑别人不一样的事情,并打断(被打断)别人的思路呢?
3.编码以为这要进行独立思考,而独立思考过程是一个私人的问题,有问题我们可以在专门的会议上讨论,但当你在分析处理具体问题时候总有人在旁边啰里八嗦的时候不知道你是否感到愉快。
结对是为了解决独立思考是,比较容易产生的欠缺和逻辑错误等这类问题,而不是要剥夺你独立思考的权利和机会。
4.总之,结对编程不符合人类思维习惯即行为习惯。
请学习行为认知等相关学科知识,你会发现,完全的独立思考,才是 不符合人类思维习惯即行为习惯 的事情。
结对驾驶啊。。这个比喻不恰当,毕竟司机的位置和活动空间那么小,行驶中换人是很麻烦且很危险的事情,即使停下来,换人也是很高成本的。。在这种场景里,一人驾驶,一人辅助(比如看地图,决策行驶路线),恰恰是结队编程里最精髓思想的体现。
通常情况下,结对的时候,两种情形:一种是我描述我的想法,你来写代码,另外一种是我写我的代码实现我的想法。。。通常只要两种方式适时的交替出现,结对的效果就能达到最大话。
至于结对下象棋,那是游戏规则的问题。。。
拧螺丝?这么简单的事情没必要,结对编程是要解决软件开发中,日益复杂的过程和质量控管的问题。。毕竟软件开发,是个复杂的脑力劳动过程。否则也不会被人们研究了3,4十年的软件工程,仍然没有很大的改善软件开发过程中出现的问题。。当然我的意思不是说,结对就是银弹,但是,如果你没有理解其中的思想原理,并切实实践一下,就不会发现其中的好处。。当你切实实践一下,你才能真正发现其中的利弊,然后再做出正确的取舍。
结对写小说之类。。。。恩,你怎么就知道所有小说都是一个人脑力劳动的结果?就没有编辑或者其他人提供的思路和改进建议?
越野车赛都要有个driver,有个navigator,
正好对应新员工和老远工的位置
结对说相声也是可以的
不是结对不符合人性,而是结对同样考验能力
同样是球类双打运动员,有配合好的总有配合差的
脑力活动和身体活动都同理
本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。
项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。
在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。
Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。
Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。
24 条回复
关注此讨论 回复