结对编程其实可以变变?

简介:
想必大家对敏捷开发中的结对编程都有所了解,可在公司试用推广时却很容易遭到大多数同事的反对,反对理由如下:
1.长期的习惯导致在有个人在旁边监督你编写代码时很别扭;
2.敏捷的结对编程要求两个程序员最好能力水平相当?这个不好界定吧,另外每个人都有每个人的编码习惯,大家也知道,做为程序员的我们往往比较固执,也比较爱布道,所以很容易产生各种实时冲突,影响开发效率;
3.也许两个人会聊其他话题哦,比如这款智能机怎样,那游戏怎么样,哈哈,这种情况应该比较少吧。
    其实我认为可以引入一种结对编程的变种,并不是严格按照敏捷概念的那种结对。而是对大范围的一个结对,比如说一个产品(在我们公司常常就有一个人开发一个产品的情况),一个子系统,一个核心功能的结对,不是针对编码的结对,恰恰,编码要分开!我觉得这种结对的精髓就是,对核心功能的设计两个人都去参与研究和设计,然后综合二人的方案提交给部门一个评审方案,因为一个人研究一个核心功能难免会有思维局限,要么就是陷入误区后无法很快找到熟悉此功能的人一起探讨。而结对编程在某种程度上规避了此种风险的发生,子系统的设计开发和产品的设计开发同理。注意,有一点,编码上一定要严格分开,两人不能有功能和代码上的交叉重叠。代码完成后,代码评审也在两人间进行。
     我觉得采用以上结对编程,相比传统的敏捷结对编程有以下几个好处:
1.没人监视编程了,很舒服,自主;
2.水平不相当也没关系,把简单功能分给水平稍低的;
3.功能的分解由两个人同时写代码完成肯定比只有一个人写代码快;
4.质量?没关系,有代码评审呢;
5.冲突,至少实时的冲突没有了,两个人可以在代码评审时互相学习,集中解决冲突。
本文转自永远的朋友博客51CTO博客,原文链接http://blog.51cto.com/yaocoder/773045如需转载请自行联系原作者

yaocoder
相关文章
|
3月前
|
设计模式 安全 C语言
软件工程师,全面思考问题很重要
软件工程师,全面思考问题很重要
51 9
|
5月前
|
算法 搜索推荐 开发者
代码的诗意:软件开发中的审美与实用主义
【7月更文挑战第17天】在数字世界的编织过程中,开发者往往沉浸于逻辑的严谨与功能的实现,却忽略了代码本身的艺术性。本文将探讨如何在追求软件实用性的同时,不丢失编程过程中的审美体验,通过案例分析展现优雅代码的力量,并讨论如何培养对技术之美的感知能力,最终达到技术与艺术的和谐统一。
|
网络安全 开发工具 数据安全/隐私保护
代码质量提升小妙招
本场景将带您借助云效Codeup的特色推送评审模式+自动化代码检测卡点的能力,在降低分支管理成本的同时,有效提升代码质量。
|
人工智能 安全 Java
【最重要的代码规范】做人做事必须坚守这些原则!
最近某应用上新闻了,时不时也有应用翻车,我们不多猜测,让子弹继续飞一会。
172 0
【最重要的代码规范】做人做事必须坚守这些原则!
|
Java 测试技术