Just because two people know a part of a system does not mean it shouldn't be documented.
And I would be glad to know that I don't have to remember every tiny detail of a system just because it it's stored nowhere else than in my head.
For a small system this might work, but as the system gets larger, your limiting yourself and your colleagues. I'd rather use the memory capacity for a new system than to remember everything of the old system.
The set of deliverables should be decided independently of whether you use pair programming or not.
Six months or two years later, all the people involved could be in a different project (or a different company). Do you want to be able to come back and use the design documentation? Then, produce it. If you don't want to come back, or the design is simple enough that with the specs and the code you can understand it without the aid of an explicit design document, then you may skip it.
But don't rely on the two people explaining the design to you one year later.
Maintenance. You can't expect the team to remain static, for there to be no new members or loss of old members. Design documentation ensures that those who are new to the project, that have to maintain it years down the line, have information on decisions that were taken, why the approach was chosen, and how it was to be implemented. It's very important for the long term success of a project to have this documentation, which can be provided via a combination of traditional documents, source comments, unit tests, and various other methods.
I don't see that pair programming makes design documentation obsolete. I immediately have to think about the Truck factor. Sure, the senior may know what the design is. But what happens when he is ill? What happens when he gets hit by a truck? What if he is fired?
Pair programming does spread knowledge, but it never hurts to document that knowledge.
Who knows about the first-written code? The answer is nobody knows, because it hasn't been written. The reason it hasn't been written is because nobody knows what to do, hence the need for a design document.
Pair programming is just two people sharing one computer. By itself, it says nothing about what kind of design methodology the pair(s) uses.
Pair programming, when taking as part of "ExtremeProgramming", means following the Extreme Programming guidelines for design. This typically involves gathering and coding to "user stories". These stories would then stand in place of other design documentation.
The experience of people may be in sync with the code, as you say. But the design decisions are not all captured in the code - only the choices made are there.
In my experience, to really understand why code is designed the way it is, you need to know about the design choices that were not selected, the approaches that had tried and failed etc. You can hope that the "chinese whispers" chain transmits that correctly, given that there's no record of this in the code to refresh memories or correct errors...
... or you can write some documentation on the design and how it was arrived at. That way, you avoid being taken down a dark alley by the maintenance programmers in future.
If you have functional tests - especially behaviour-driven development (BDD) tests, or Fitnesse or FIT tests then they're certainly a form of "active documentation"... and they certainly have value as well as being regression tests.
If you write user stories and break them down into tasks and write those tasks on cards for pairs to do then you're doing a form of documentation...
Those are the two main forms of documentation I've used in XP teams that pair on all production code.
The only other document that I find quite handy is a half-page or so set of bullet points showing people how to set up the build environment for a development machine. You're supposed to maintain the list as you go along using it.
Well if you want a spreadsheet program instead of a word processor a design doc use useful :-)
XP, pair programing, agile, etc... do not mean you do not have a plan, it is just a far less detailed plan (at the micro level) of what is going on. The use cases that the user picks are more of the design, and it is more of a living document than with other styles of design/programming.
Do not fall into the trap that because youa re doing something "cool" that you no longer need good practices - indeed this style of programming requires more discipline rather than less to be successful.
Pair programming is an opportunity for the team to avoid having to spend a large proportion of the project time on documenting everything. But the need for documentation depends on how good you are at remembering the important stuff and how good your code is. You may still want lots of documentation if the code is difficult to work with.
You could try some experiments:-
Document a couple of small parts of the design and note how often you have to refer to it.
Document stuff that is always a pain to work with.
因此，最重要的是，结对编程可以产生更好的文档。 它并没有消除文档（尽管您可能无法找到 Word 文档）。
No Nor does lack of pair programming mean you need documentation. Documentation is needed! What it looks like may surprise you!
An agile team will decide when and what documentation is needed. A good rule of thumb, if no one is going to read it, don't write it. Don't get caught up in the waterfall artifact thinking by provide artifacts because the Project Manager says so.
Most think of documentation as something you do with Word. If an agile team is working properly, the code itself, with TDD (test driven development) will have a set of automated test that document and enforce the requirements. Image, documentation that is in sync with the code ... and it stays that way.
Having said that, pairing does help domain, application, practice and skill knowledge propagate through the team very quickly. Pairing also helps ensure that the team follow the engineering practices including TDD and other automated test. The results are that the application remains healthy and future change is easy to bring about.
So, bottom line, pair programming produces better documentation. It does not eliminate documentation (although you might not be able to find a Word document).
I am a pro-advocate and a fan of documentation. Pair programming does not require "one senior developer". In my experience with pair programming, developers of all levels are paired together, for the purpose of rapid development. There are many times I worked with junior developers and would trade off on the keyboard. There are many times I worked with senior architects and would trade off on the keyboard. Documentation is still necessary, especially with your core components and database.
发布评论
评论（16）
如果您的团队超过 2 人怎么办？
仅仅因为两个人知道系统的一部分并不意味着它不应该被记录下来。
我很高兴知道我不必记住系统的每一个微小细节，因为它只存储在我的脑海中。
对于小型系统，这可能可行，但随着系统变得更大，您会限制自己和同事。 我宁愿使用新系统的内存容量，也不愿记住旧系统的所有内容。
What if your team is larger than 2 persons?
Just because two people know a part of a system does not mean it shouldn't be documented.
And I would be glad to know that I don't have to remember every tiny detail of a system just because it it's stored nowhere else than in my head.
For a small system this might work, but as the system gets larger, your limiting yourself and your colleagues. I'd rather use the memory capacity for a new system than to remember everything of the old system.
你玩过“电话”吗？ 我认为你不应该用你的代码库来玩它。
Have you ever played "telephone?" I don't think you should play it with your codebase.
如果高级程序员离开公司/项目怎么办？
What if the senior programmer leaves the company/project?
可交付成果集应独立于您是否使用结对编程来决定。
六个月或两年后，所有相关人员可能都在不同的项目（或不同的公司）中。 您希望能够回来使用设计文档吗？ 然后，生产它。 如果你不想回来，或者设计足够简单，通过规范和代码你可以理解它，而无需明确的设计文档的帮助，那么你可以跳过它。
但不要依赖一年后两个人向你解释设计。
The set of deliverables should be decided independently of whether you use pair programming or not.
Six months or two years later, all the people involved could be in a different project (or a different company). Do you want to be able to come back and use the design documentation? Then, produce it. If you don't want to come back, or the design is simple enough that with the specs and the code you can understand it without the aid of an explicit design document, then you may skip it.
But don't rely on the two people explaining the design to you one year later.
维护。 你不能指望团队保持静止，因为不会有新成员或老成员流失。 设计文档可确保那些刚接触该项目、必须多年维护该项目的人员了解所采取的决策、选择该方法的原因以及如何实施该方法的信息。 拥有此文档对于项目的长期成功非常重要，可以通过传统文档、源代码注释、单元测试和各种其他方法的组合来提供。
Maintenance. You can't expect the team to remain static, for there to be no new members or loss of old members. Design documentation ensures that those who are new to the project, that have to maintain it years down the line, have information on decisions that were taken, why the approach was chosen, and how it was to be implemented. It's very important for the long term success of a project to have this documentation, which can be provided via a combination of traditional documents, source comments, unit tests, and various other methods.
我不认为结对编程会使设计文档变得过时。 我必须立即考虑卡车系数。 当然，前辈可能知道这个设计是什么。 但当他生病时会发生什么？ 当他被卡车撞时会发生什么？ 如果他被解雇了怎么办？
结对编程确实可以传播知识，但记录这些知识总没有坏处。
I don't see that pair programming makes design documentation obsolete. I immediately have to think about the Truck factor. Sure, the senior may know what the design is. But what happens when he is ill? What happens when he gets hit by a truck? What if he is fired?
Pair programming does spread knowledge, but it never hurts to document that knowledge.
谁知道第一个写的代码？ 答案是没有人知道，因为它还没有被写下来。 之所以没有写出来，是因为没有人知道该做什么，因此需要一个设计文档。
Who knows about the first-written code? The answer is nobody knows, because it hasn't been written. The reason it hasn't been written is because nobody knows what to do, hence the need for a design document.
结对编程就是两个人共用一台计算机。 就其本身而言，它没有说明这对组合使用哪种设计方法。
结对编程，作为“Extreme 编程"，意味着遵循极限编程指南进行设计。 这通常涉及收集和编码“用户故事”。 这些故事将取代其他设计文档。
Pair programming is just two people sharing one computer. By itself, it says nothing about what kind of design methodology the pair(s) uses.
Pair programming, when taking as part of "Extreme Programming", means following the Extreme Programming guidelines for design. This typically involves gathering and coding to "user stories". These stories would then stand in place of other design documentation.
正如你所说，人们的体验可能与代码是同步的。 但设计决策并没有全部记录在代码中——只有做出的选择。
根据我的经验，要真正理解为什么代码是这样设计的，您需要了解未选择的设计选择、尝试过但失败的方法等。您可以希望“中国窃窃私语”链传达这一点正确的是，考虑到代码中没有记录来刷新记忆或纠正错误……
或者您可以编写一些有关设计及其实现方式的文档。 这样，您就可以避免将来被维护程序员带入黑暗的小巷。
The experience of people may be in sync with the code, as you say. But the design decisions are not all captured in the code - only the choices made are there.
In my experience, to really understand why code is designed the way it is, you need to know about the design choices that were not selected, the approaches that had tried and failed etc. You can hope that the "chinese whispers" chain transmits that correctly, given that there's no record of this in the code to refresh memories or correct errors...
... or you can write some documentation on the design and how it was arrived at. That way, you avoid being taken down a dark alley by the maintenance programmers in future.
取决于“设计文档”的含义。
如果您有功能测试 - 特别是行为驱动开发 (BDD) 测试，或者 Fitnesse 或 FIT 测试，那么它们肯定是“活动文档”的一种形式...并且它们当然也有价值作为回归测试。
如果您编写用户故事并将其分解为任务，然后将这些任务写在卡片上供两人一起完成，那么您正在制作一种形式的文档...
这是我认为的两种主要文档形式我们在 XP 团队中使用过，它可以在所有生产代码上配对。
我发现非常方便的唯一其他文档是半页左右的一组要点，向人们展示如何为开发机器设置构建环境。 您应该在使用该列表时维护该列表。
Depends what you mean by "design documentation".
If you have functional tests - especially behaviour-driven development (BDD) tests, or Fitnesse or FIT tests then they're certainly a form of "active documentation"... and they certainly have value as well as being regression tests.
If you write user stories and break them down into tasks and write those tasks on cards for pairs to do then you're doing a form of documentation...
Those are the two main forms of documentation I've used in XP teams that pair on all production code.
The only other document that I find quite handy is a half-page or so set of bullet points showing people how to set up the build environment for a development machine. You're supposed to maintain the list as you go along using it.
代码库可能太大，您无法记住要实现的内容的每个细节。 在这种情况下，参考很有用。
此外，如果您要与其他组件等交互，则需要设计。
The code base may be so large you can't humanly remember every detail of what you were intending to implement. A reference is useful in this case.
Also, you need a design if you are interacting with other components etc.
好吧，如果你想要一个电子表格程序而不是文字处理程序，那么设计文档会很有用:-)
XP、结对编程、敏捷等...并不意味着你没有计划，它只是一个不太详细的计划（在微观层面）正在发生的事情。 用户选择的用例更多的是设计，并且与其他风格的设计/编程相比，它更像是一个动态文档。
不要陷入这样的陷阱：因为你正在做一些“酷”的事情，所以你不再需要良好的实践——事实上，这种编程风格需要更多的纪律而不是更少的纪律才能取得成功。
Well if you want a spreadsheet program instead of a word processor a design doc use useful :-)
XP, pair programing, agile, etc... do not mean you do not have a plan, it is just a far less detailed plan (at the micro level) of what is going on. The use cases that the user picks are more of the design, and it is more of a living document than with other styles of design/programming.
Do not fall into the trap that because youa re doing something "cool" that you no longer need good practices - indeed this style of programming requires more discipline rather than less to be successful.
结对编程为团队提供了一个机会，可以避免花费大量的项目时间来记录所有内容。 但对文档的需求取决于您对重要内容的记忆程度以及您的代码的质量。 如果代码难以使用，您可能仍然需要大量文档。
你可以尝试一些实验：-
设计并记下您的频率
必须参考一下。
跟...共事。
Pair programming is an opportunity for the team to avoid having to spend a large proportion of the project time on documenting everything. But the need for documentation depends on how good you are at remembering the important stuff and how good your code is. You may still want lots of documentation if the code is difficult to work with.
You could try some experiments:-
the design and note how often you
have to refer to it.
to work with.
否 缺乏结对编程也不意味着您需要文档。 需要文档！ 它的外观可能会让您感到惊讶！
敏捷团队将决定何时需要以及需要什么文档。 一个好的经验法则是，如果没有人会读它，就不要写它。 不要因为项目经理这么说而陷入提供工件的瀑布工件思维中。
大多数人认为文档就是用 Word 做的事情。 如果敏捷团队工作正常，代码本身以及 TDD（测试驱动开发）将拥有一组自动化测试来记录和执行需求。 与代码同步的图像、文档……并且保持这种状态。
话虽如此，结对确实有助于领域、应用、实践和技能知识在团队中快速传播。 结对还有助于确保团队遵循工程实践，包括 TDD 和其他自动化测试。 结果是应用程序保持健康并且很容易带来未来的变化。
因此，最重要的是，结对编程可以产生更好的文档。 它并没有消除文档（尽管您可能无法找到 Word 文档）。
No Nor does lack of pair programming mean you need documentation. Documentation is needed! What it looks like may surprise you!
An agile team will decide when and what documentation is needed. A good rule of thumb, if no one is going to read it, don't write it. Don't get caught up in the waterfall artifact thinking by provide artifacts because the Project Manager says so.
Most think of documentation as something you do with Word. If an agile team is working properly, the code itself, with TDD (test driven development) will have a set of automated test that document and enforce the requirements. Image, documentation that is in sync with the code ... and it stays that way.
Having said that, pairing does help domain, application, practice and skill knowledge propagate through the team very quickly. Pairing also helps ensure that the team follow the engineering practices including TDD and other automated test. The results are that the application remains healthy and future change is easy to bring about.
So, bottom line, pair programming produces better documentation. It does not eliminate documentation (although you might not be able to find a Word document).
我是文档的拥护者和粉丝。 结对编程不需要“一名高级开发人员”。 根据我的结对编程经验，各个级别的开发人员都会结对在一起，以实现快速开发。 有很多次我与初级开发人员一起工作，并且会在键盘上进行权衡。 我有很多次与高级架构师合作，并会在键盘上进行权衡。 文档仍然是必要的，特别是对于您的核心组件和数据库。
I am a pro-advocate and a fan of documentation. Pair programming does not require "one senior developer". In my experience with pair programming, developers of all levels are paired together, for the purpose of rapid development. There are many times I worked with junior developers and would trade off on the keyboard. There are many times I worked with senior architects and would trade off on the keyboard. Documentation is still necessary, especially with your core components and database.
结对编程仅支持您的编码和逻辑方面。
但文档是很好的做法。 总是做文档...
Pair Programming only enables your coding and logical aspect.
But documentation is good practice. Always do documentation...