Open AlexiaChen opened 4 years ago
title: 一次结对编程的亲身体验 date: 2017-10-14 10:30:46 tags:
思绪来得也快去得也快。 -- 云风
结对编程是敏捷软件开发中提出的一种实践和概念，意思就是两个程序员坐在一台电脑前一起编写代码，其中一个主要编写代码，另一个主要负责代码的review，提出自己的疑问和自己的见解。
在故事开始之前需要说点必要的题外话，项目组增加了人手，除了我以外增加了2个同事。客户端的GUI框架选择了Qt，新来的两个同事虽然已工作多年，比较有经验，但是他们两个目前暂时都对这个Qt框架没我熟悉和有经验。
昨天是周五，面临着项目又一次功能的迭代，一周的目标的收尾结束。所以我自己也比较忙，花了一早上把分配给自己的任务给搞定了。 由于我们项目的客户端新的选择的是Qt来开发的GUI界面，Qt带来一定的复杂性在对此不熟悉的同事直接上手介入项目的开发带来了一定困难，这个功能模块的任务原本是分配给一个刚学习Qt几天的同事来做的，但是由于项目进度的推进关系，必须又要在这周五有个收尾和结果，所以为了不影响进度又因为任务最开始是分配给他的，所以我提出了让那个同事一起过来跟我坐一个工位上一起实践结对编程。
就这样，主要由我来编写GUI界面和功能逻辑的代码，而他坐在旁边根据自己的思路提出疑问和见解，任务的目标功能很快就完成了，期间只用了2个多小时，比我预想得要快，而且代码的质量也比预想的要高，如果这个功能我自己一个人做的话，虽然也花不了多少时间，顶多3小时，但是这次的经历使我对结对编程产生了新的看法，两个人一起工作的效率竟然不低，反而可能经过多次这样的实践工作效率大大提高，代码质量也提高了。以前我对于结对编程的了解也仅仅限于各类软件开发的书本，比如《代码大全》。但这次却是让我真正感受到了效率。以下我就详细说说带来了哪方面的效率。
有利于知识经验的分享和传递，特别适合于帮助主要负责Review的同事快速熟悉自己所不熟悉的领域(框架，库，业务逻辑等)。
有效控制代码质量和风险，经过互相讨论的代码实现往往比自己独自决定的考虑更加全面。在一个人的注视下，反而不好意思写烂代码了，因为要边写代码边讲解自己的实现思路，同时负责Review的同事也会积极反馈你的代码逻辑，在这样的情况下，更容易编写可读性高的代码。
在一个负责Review的同事的注视下的工作可以提高工作效率，分心的概率减小。因为一个人的注视下，专心编写代码的注意力会高度集中，Review代码逻辑的人也会由于积极的互相讨论注意力高度集中。
以上三点提到的效率，在完成任务目标后，都得到我们两个同事的一致肯定，互相都有收获。
因为结对编程只是敏捷开发中的一个方法论，所以它也不是能绝对带来效率上的提升的，没有银弹。它需要有一个前提，这个前提是在完成体验了一次结对编程之后，我总结出来的，这个前提也反应了结对编程可能出现的缺点。
由于双方注意力的高度集中，几个小时实践下来，会很累，需要耗费很大的精力来实践。以至于很少有团队能长期这样坚持。
双方的技术水平和编程品味差距不能太大，不然不利于交流。试想一个场景，Review代码的人看不惯编写代码的人的风格和实现算法，直接鄙视编码的同事，老子有更厉害的算法，老子更牛逼。 所以，这样是万万不行的。
双方最好是熟悉项目不同模块的开发人员，比如我熟悉模块A，你熟悉模块B。这样一旦结对编程，互相收获会更大，经常这样，我也可以熟悉模块B，你也可以熟悉模块A了，有利于团队建设，分散节点风险，控制风险。比如，项目的某模块A使用了一个复杂性较高的算法，但是这个A模块是小明编写的，没其他人熟悉模块A，但是恰恰在项目的关键时期，小明请了婚假之类较长的假期，项目由于新功能的发布，需要结合业务修改模块A的算法，但是由于该算法有一定的复杂性，项目组内没有其他成员敢碰模块A，在有限的时间内，其他组员也可能完成模块A的修改，这样会导致项目只能拖延，公司可能流失客户。
一些公司可能是看工作量，成果算KPI的。SVN，Git中都是编写代码的同事的commit更多，Review代码同事的commit更少。如果结对编程，那么Review代码的人岂不是活也没干？ 怎么算员工绩效？ 从一般的公司管理层的思维角度会认为，产出比太低，耗费公司资源。
归而结网，软件工程中提出的各种方法论目的无非就是尽量在更短的时间内快速交付并发布高质量的软件。这些各种方法论都不是万能的，都需要根据团队的特点适当选择，找出适合自己团队的最佳实践，应该靠不断分析、试错、调整，而不是照本宣科。
title: 一次结对编程的亲身体验 date: 2017-10-14 10:30:46 tags:
职业生涯
前言
结对编程是敏捷软件开发中提出的一种实践和概念，意思就是两个程序员坐在一台电脑前一起编写代码，其中一个主要编写代码，另一个主要负责代码的review，提出自己的疑问和自己的见解。
一次亲身体验
在故事开始之前需要说点必要的题外话，项目组增加了人手，除了我以外增加了2个同事。客户端的GUI框架选择了Qt，新来的两个同事虽然已工作多年，比较有经验，但是他们两个目前暂时都对这个Qt框架没我熟悉和有经验。
昨天是周五，面临着项目又一次功能的迭代，一周的目标的收尾结束。所以我自己也比较忙，花了一早上把分配给自己的任务给搞定了。 由于我们项目的客户端新的选择的是Qt来开发的GUI界面，Qt带来一定的复杂性在对此不熟悉的同事直接上手介入项目的开发带来了一定困难，这个功能模块的任务原本是分配给一个刚学习Qt几天的同事来做的，但是由于项目进度的推进关系，必须又要在这周五有个收尾和结果，所以为了不影响进度又因为任务最开始是分配给他的，所以我提出了让那个同事一起过来跟我坐一个工位上一起实践结对编程。
就这样，主要由我来编写GUI界面和功能逻辑的代码，而他坐在旁边根据自己的思路提出疑问和见解，任务的目标功能很快就完成了，期间只用了2个多小时，比我预想得要快，而且代码的质量也比预想的要高，如果这个功能我自己一个人做的话，虽然也花不了多少时间，顶多3小时，但是这次的经历使我对结对编程产生了新的看法，两个人一起工作的效率竟然不低，反而可能经过多次这样的实践工作效率大大提高，代码质量也提高了。以前我对于结对编程的了解也仅仅限于各类软件开发的书本，比如《代码大全》。但这次却是让我真正感受到了效率。以下我就详细说说带来了哪方面的效率。
有利于知识经验的分享和传递，特别适合于帮助主要负责Review的同事快速熟悉自己所不熟悉的领域(框架，库，业务逻辑等)。
有效控制代码质量和风险，经过互相讨论的代码实现往往比自己独自决定的考虑更加全面。在一个人的注视下，反而不好意思写烂代码了，因为要边写代码边讲解自己的实现思路，同时负责Review的同事也会积极反馈你的代码逻辑，在这样的情况下，更容易编写可读性高的代码。
在一个负责Review的同事的注视下的工作可以提高工作效率，分心的概率减小。因为一个人的注视下，专心编写代码的注意力会高度集中，Review代码逻辑的人也会由于积极的互相讨论注意力高度集中。
以上三点提到的效率，在完成任务目标后，都得到我们两个同事的一致肯定，互相都有收获。
结对编程不是银弹
因为结对编程只是敏捷开发中的一个方法论，所以它也不是能绝对带来效率上的提升的，没有银弹。它需要有一个前提，这个前提是在完成体验了一次结对编程之后，我总结出来的，这个前提也反应了结对编程可能出现的缺点。
由于双方注意力的高度集中，几个小时实践下来，会很累，需要耗费很大的精力来实践。以至于很少有团队能长期这样坚持。
双方的技术水平和编程品味差距不能太大，不然不利于交流。试想一个场景，Review代码的人看不惯编写代码的人的风格和实现算法，直接鄙视编码的同事，老子有更厉害的算法，老子更牛逼。 所以，这样是万万不行的。
双方最好是熟悉项目不同模块的开发人员，比如我熟悉模块A，你熟悉模块B。这样一旦结对编程，互相收获会更大，经常这样，我也可以熟悉模块B，你也可以熟悉模块A了，有利于团队建设，分散节点风险，控制风险。比如，项目的某模块A使用了一个复杂性较高的算法，但是这个A模块是小明编写的，没其他人熟悉模块A，但是恰恰在项目的关键时期，小明请了婚假之类较长的假期，项目由于新功能的发布，需要结合业务修改模块A的算法，但是由于该算法有一定的复杂性，项目组内没有其他成员敢碰模块A，在有限的时间内，其他组员也可能完成模块A的修改，这样会导致项目只能拖延，公司可能流失客户。
一些公司可能是看工作量，成果算KPI的。SVN，Git中都是编写代码的同事的commit更多，Review代码同事的commit更少。如果结对编程，那么Review代码的人岂不是活也没干？ 怎么算员工绩效？ 从一般的公司管理层的思维角度会认为，产出比太低，耗费公司资源。
归而结网，软件工程中提出的各种方法论目的无非就是尽量在更短的时间内快速交付并发布高质量的软件。这些各种方法论都不是万能的，都需要根据团队的特点适当选择，找出适合自己团队的最佳实践，应该靠不断分析、试错、调整，而不是照本宣科。