约定

一旦有多个开发人员从事一个项目，您就会遇到麻烦。 沟通是开发人员工作的100％。 我们使用自己的语言（在会议，一对一，聊天等），肢体语言甚至我们的代码进行交流。 有趣的是，我们传达的是意图，而不是言语本身。 事实证明，接收方可以决定消息的含义，而不是发送方。 因此，我们必须尽力确保接收端能够理解我们试图传输的意图。 改善通信的一种选择是通过约定。 它们以许多不同的方式提供帮助，但最常见的是在相同情况下具有相同含义。 开始于其他项目？ 如果结构具有约定，则可以更快地找到访问方式。 使用相同的术语传达对功能的更改会有所帮助。 在本文中，我们将介绍几种类型的约定，这些约定将成为您日常生活的一部分。

代码约定

每个人都听说过代码约定。 它们帮助开发人员找到进入项目的方式或更快地了解代码。 如果所有内容都以相同的样式编写，则突然之间与您之前阅读的代码或您昨天编写的代码没有太大不同。 有很多不同的代码约定和意见，所以我不建议使用特定的约定和意见。 只需选择一个并坚持下去即可。 确保团队中的每个人都遵守他们。

最好的方法是使用自动格式化程序。 关于Swift，有swiftformat。 遗憾的是，它还没有配置文件，必须通过命令行参数启动。 但是它工作得很好。

强制执行代码约定的另一个工具是swiftlint。 它只有几个自动格式选项，但是它提供了其他有趣的配置来强制一种代码风格。

提交约定

确保不丢失任何代码，并确保我们使用版本控制系统的团队合作。 这些工具试图通过锁定文件以进行更改或显示合并冲突来限制错误，以防多个开发人员更改同一文件。 提交我们的代码后，我们给其他开发人员留下了一条信息，供他们快速了解我们所做的事情，而他不必阅读更改就是代码。 提交消息比大多数开发人员认为的重要。 如果您搜索了几个小时的更改，您将欣赏到结构良好且有意义的提交消息。 由于提交消息又有不计其数的不同约定，所以我不建议您这样做。 但是我倾向于使用这个：

：

这似乎包含一些开销，并且我的同事鄙视诸如更改类型之类的信息。 但是，让我们仔细看看我的建议。

票证：这是此更改影响的票证名称。 它不一定是此票证的唯一更改，但是如果我们要查找的是确切的要求，则需要该票证。

类型：我想知道此更改是由于功能，错误修正，某种必要的工作还是任何其他原因引起的。 您可以在“角度提交消息格式”中找到一些有关类型的建议。 不少人可能会对这种类型的误导性感到担忧。 如果开发人员没有分开提交，情况就是这样。 在我看来，这甚至可以帮助他学会这样做。

简介：这包含更改的意图，而不是开发人员所做的精确更改。 因此，与其编写“添加一些文件并将其更改为执行此操作或那样操作”，不如编写“此添加功能1”或“这将在注销后解决崩溃问题”。 使用这种消息，将改善您的意图交流。

结论

如您所见，有很多方法可以通过约定改善我们的沟通。 明确的意图有很长的路要走。 对于我们的项目，默认情况下，我们将遵循swiftlint建议的代码约定。 此外，将使用上述提交消息格式。

下一个：Git Hooks

上一篇：开发者机器