协同训练代码_协同工件作为代码

协同训练代码

一个软件开发项目是一个协作的工作。 几个团队成员一起工作，并产生随时间推移而不断发展的人工制品，Alberto Brandolini（ @ziobrando ）称其为“ 协作建设” 。 通常，这些工件会以它们的当前状态被获取并转换为某种东西，从而成为一种发布。 通常，源代码会被编译并打包到一些可执行文件中。

“协作工件即代码”的想法是认可这一协作构建阶段并将其进一步推进，方法是将尽可能多的协作工件提升为存储在同一源代码控件中的纯文本文件，而其他所有内容均由生成，呈现和存档软件工厂。

协作工件是团队工作并随着时间推移而维护的工件，这要归功于几个人通过诸如SVN，TFS或Git之类的源代码控制管理所做的更改，以及它们的所有好处，例如分支和版本控制。

保持在一起，一起变化

存储文档的通常方法是将MS Office文档放入某个位置的共享驱动器中，或在几乎没有组织的Wiki中写入随机内容。

无论哪种方式，该文档都将很快失去同步，因为代码不断变化，而与存储在其他地方的文档无关，并且众所周知，“视而不见”。

我们现在有更好的选择

我们现在有更好的选择

我们现在有更好的选择

在过去的几年中，软件开发发生了变化。 Github已经普及了用Markdown编写的README.md概述文件。 DevOps带来了基础架构即代码的原则。 BDD方法引入了文本方案的想法，作为活泼的文档，是规范和验收测试的替代方案。 像Impact Mapping一样，出现了规划软件应该做什么的新方法。

所有这些表明，我们可以用结构更复杂的替代文件代替许多非正式文档，并且可以将所有这些文件与源文件并置在源代码控件中。

在源代码管理中的任何给定分支中，我们将得到以下内容：

• 源代码 （C＃，Java，VB.Net，VB，C ++）
• 通过普通的README.md以及可能有用的其他.md文件的基本文档 ，可以对代码进行高级概述
• SQL代码也可以作为源代码，或者通过Liquibase样式配置
• 实时文档 ：单元测试和BDD场景（SpecFlow / Cucumber / JBehave功能文件）作为实时文档
• 影响图 （以及其他所有思维导图）可以以文本形式完成，然后通过诸如text2mindmap之类的工具进行渲染
• 理想情况下， 任何其他类型的图 （UML或通用图）都以纯文本格式定义，然后通过工具（Graphviz，yUml）呈现。
• 依赖声明作为清单而不是有关如何手动设置和构建的文档（Maven，Nuget…）
• 部署代码作为脚本或Puppet清单用于自动部署，而不是有关如何手动部署的文档

纯文本痴迷是一件好事！

没有人通过直接编辑用户最终实际运行的可执行二进制文件来创建软件，但是直接编辑将在发行版中提供的MS Word文档是常见的。

代码中的协作工件表明，每个协作工件都应基于文本，以与源代码控制很好地协同工作，并易于在版本之间进行比较和合并。

尽可能使用基于文本的格式，例如.csv而不是xls，rtf或.html而不是.doc，否则，通常的大PPT文件必须转到另一个专用的Wiki，在此它们可以被安全地忘记并被立即弃用……

类似于Wiki，但生成且为只读

我的同事Thomas Pierrain总结了这种方法的优点，并提供了文档：

• 始终保持最新和版本化
• 易于区分 （文本文件，例如Markdown格式）
• 尊重DRY原则（以SCM为黄金源）
• 每个人（DEV，QA，BA，支持团队...）都可以轻松浏览 ，且其可读性类似于Wiki，该网站具有可读性
• 团队成员可以在众所周知的官方位置轻松修改（就像在SCM中创建或修改文本文件一样容易）

下一步是什么？

这种方法并不是什么真正的新方法（想想LateX…），而我们所需的许多工具已经存在（Markdown渲染器，组织和显示Gherkin方案的网站……）。 但是，我从未在实际项目中看到这种方法能完全完成。 也许您的项目已经在这样做了？ 请分享您的反馈！

参考： Cyrille Martraire博客博客中的JCG合作伙伴 Cyrille Martraire的协作工件作为代码 。

翻译自: https://www.javacodegeeks.com/2012/11/collaborative-artifacts-as-code.html

协同训练代码