如何说服队友遵守一些基本规则

我的队友有问题。长话短说：我们是三个学生，正在为一个竞赛项目工作。该项目包含2个独立的应用程序：一个用于Windows（由我开发）和一个用于Android（由我的同事负责开发）。我们的代码库永远不会相交，应用程序将通过第三方工具进行通信。

问题如下：去年我在一家大公司实习时，我有一些在团队中工作的经验，并且我尝试为我们的代码强制执行一些编码标准。我还设置了一个git仓库/ wiki /协作软件，可以用来推送代码/编写想法，文档协议等，但是看来我是唯一使用这些工具的人。

我试图告诉他们，从长远来看，编写高质量的代码和记录每一个步骤将使我们受益，但他们似乎没有看到它的好处。我也在考虑添加一些集成测试，但是据我所见，只要他们不使用当前的工具来简化他们的生活，我想我就无法说服他们集成测试的用处。

同行的大多数代码都驻留在他们的计算机上，他们没有共享通用的代码库，而且正如我发现的那样，他们通过使用usb棒开会和共享代码来集成自己的代码。

我的问题是：我对此事是否太苛刻？我是否执行一些荒谬的规则？请记住，这是一个小项目，要求非常明确（我创建了说明应用程序应该做什么的文档），三个熟练的开发人员可以在3-4天之内完成此操作，因此他们可能看不到书写质量的额外复杂性代码，只要它们当前的方法可以正常工作。

有什么方法可以向他们展示使用git等记录代码的好处吗？

我的问题是：我对此事是否太苛刻？

您可以将一匹马带到水里，但是不能让他喝水。

很难说您是否“太苛刻”，但是期望您的队友采用您希望的所有基础架构可能是不现实的。确实，如果团队合作良好，那么使用Wiki在三个人之间进行交流可能就太过分了。

缩减您的期望并寻找实现某些目标的方法，而无需他们开始使用他们不知道的工具。如果他们不知道如何使用git，那么无论如何他们可能不会从中获得很多好处。但是，您仍然要确保在硬盘故障或其他灾难的情况下备份所有代码，因此请他们定期将其项目文件夹复制到Google Drive，Dropbox或类似的在线文件共享服务。确保您执行相同操作。

我的态度是，如果您可以学习在小型项目上做这些事情，那么大型项目来临时您就会做好准备。

如果他们在这个项目中遵循良好的开发实践，他们将有代码向未来的雇主展示，并且他们将拥有使他们有价值的经验。

如果您需要更多的材料来说服他们，我将参考Pragmatic Programmer或Code Complete。

另一方面，考虑减少它们的松弛度。如果项目是概念证明，并且在比赛结束后马上进行分类，那么您应该考虑让他们随心所欲。他们可能只是为了一开始就编写代码而苦苦挣扎，而没有良好实践的精神负担。

恐怕您描述的规则根本不是基本的。

IMO最简单的任务就是说服您的队友使用某些编码标准。实现此目的的一种简单方法是，向他们展示格式正确，样式错误的相同代码段，要求他们阅读代码，理解代码的作用并让他们自己判断。

使用git仓库会给新手带来很大的痛苦。当我由3个人组成的团队研究一个Android项目时，刚开始我们的版本控制系统遇到了很多麻烦。因此，我希望您的队友也会遇到麻烦。

您已经提到，经验丰富的开发人员需要3-4天才能完成项目（我认为这将使您的团队花费2-3倍的时间）。这是一个很短的时间，因此使用新工具从长远来看会有所帮助的论点根本行不通。

您可以做的是简短的演示，以演示如何使用这些工具。首先介绍最基本的功能，坐在他们身边并帮助他们使用工具。准备执行所有任务，例如配置git，创建Wiki页面结构等。

编辑：作为对评论的答复，我认为建立明确的任务，估计和期限以及跟踪花费的时间比使用git或类似工具更重要。如果您打算以后使用该应用程序，那么跟踪已经完成的功能以及每个功能花费的时间非常重要。因此，我建议您从任务管理开始，然后继续使用要使用的工具。

实际上，我喜欢乔尔·斯波斯基（Joel Spolsky）的想法，因为他在《当你只是咕Gr咕Getting做完事情》中阐述了他的想法。总结一下：

1. 做到这一点 -编写makefile，创建每日构建服务器等。
2. 没有人使用源代码控制或错误数据库？自己开始使用它们。如果有人报告了与您工作有关的错误，请礼貌地请他们使用错误数据库向您报告错误，以便您可以跟踪它们；否则您将无法将它们伸直在脑海中并进行修复。在任何不平凡的项目中，都会存在只能通过源代码控制解决的情况：自己对代码使用源代码控制，并英勇地扑进来，以防发生这种情况。一旦发生几次，他们就会说服
3. 创建一个卓越的口袋 -为自己做正确的事情：规范，安排时间等。由于这似乎不像一个工作项目，因此您似乎无法一路接受这条建议，因为您不能雇用相信您的讯息的新团队成员
4. 成为无价之宝 -证明您是在团队中巩固影响力的杰出贡献者。否则，您将冒着成为重视过程和工具胜过结果的人的风险。

文档，Wiki，版本控制软件，方法论等都是随着时间的推移获得的经验教训；几个项目的工作，可能需要几个团队的工作。它通常适合那些已经就业或认真对待自己行业的人。他们是学生，因此他们的兴趣可能会受到限制，因为将来会发生什么。:)

但是要尝试回答您的问题：

如果您与他们同在一个团队中，则需要以有利于他们利益的方式运用您认为重要的内容。举个例子：当共享USB时，他们是否应该抱怨自己的代码中断很多？然后，也许给他们一种简单的（非复杂的）方式，将SVN（而不是git）用作版本控制工具。

我也同意阿诺德的评论。

当您与他们一起使用时，您看到了所有这些工具的好处，这就是您如何看待它们的价值以及为什么理解它们的用途。如果您的队友没有看到他们当前的工作方式增加了价值，那么他们将不会应用它。可悲的是，这对于由具有任何经验水平的人员组成的团队来说甚至都算在内。

该方法存在问题：

1. 您的方法不对称。您的其他团队成员需要进行更改，但是您没有在学习他们的良好做法。在这种情况下执行规则很困难。更好的方法是从团队的所有成员那里收集良好的规则和实践，然后每个人都阅读得到的文档。

2. 学习困难。别人的规则只是没有意义，因为这些规则不具有程序员期望的逻辑结构。强制执行没有意义的规则不是有用的活动。

3. 每个人都学到了不同的东西。来自不同背景的程序员很自然地学到了不同的东西。他们的长处不同，编写代码的方式也不同。他们使用的工具是不同的。强制执行一组规则/工具/样式将是一场噩梦，因为这些限制正在失去那些开发人员花了多年时间学习的力量。
4. 改变需要时间。虽然发明您要执行的规则的人很容易遵循规则，但其他所有人都在受苦，并花时间学习新规则。这就是团队中的每个人都应该能够更改规则的原因之一。
5. 为整个团队选择工具/编码约定或样式是一项艰巨的任务。它只能随着时间的流逝缓慢地进行，测试哪些东西有效，哪些无效。给团队2个星期以开始遵循50条规则的想法是行不通的。

我在大学里发现了这个问题。许多人根本不愿意学习另一种（也许更专业的方法）工作方式。

如果您已经安装了系统，并解释了如何使用该系统，那么很多人都愿意尝试一下。我还认为存储库使用的工具非常少，人们通常只会使用类似保管箱的工具。