我们的健康编码惯例以及它们如何为您提供帮助

在Mobile First，我们以成为快乐的编码员而感到自豪。 在鼓励实验的同时，我们也认识到有时最好遵循我们自己的久经考验的指南以获得最佳结果。

为了保持平台独立性，我们寻求遵循的通用规则，并且不允许自己陷入诸如制表符缩进或语言功能之类的细节中。

我们是快乐的编码员，对我们来说，这意味着……

复制代码行时，可能是在复制错误（错误），非最佳方法或外部依赖项。 如果有问题的代码分散在您的整个应用程序中，您将无法轻松进行改进。 查看高度重复的代码也将给您带来真正的déjàvu！

始终使代码起作用并注入依赖项/参数。

在创建，理解，测试和错误修复代码时，在一堆中做太多事情是无法管理或维护的。 这就是为什么我们使用单一责任原则。 从功能到对象，甚至到整个应用程序（例如Facebook Messenger），都可以转换为各个级别。

始终将任务分解为更小的简单组件，这些组件只能访问其所需的信息。

不要让人们在您的实现内部获取肮脏的手套！ 仅公开已设计并经过测试的要更改的内容。 确保您的实现已通过单元测试针对这些更改进行了测试。

从外部角度查看对象，它的协议有意义吗？

始终使用访问级别的保护，将所有内容设为私有，并在需要时进行升级。 寻找定义明确的协议。

具有全局范围的变量和函数的全局文件（称为“常量”，“助手”或“ utils”）倾向于链接系统的不相关部分，从而使代码难以重用。 单例有相同的问题。 大量使用单例使理解对象依赖性变得很困难-因为您将必须检查实现以查看其使用方式。 由于难以模拟单例依赖关系，因此很难进行单元测试。

始终倾向于依赖注入而不是全局范围和单例。 常量应保存在其所属类的范围内。 这样可以更清楚地了解哪些对象需要运行，从而使代码更易于进行单元测试。 考虑一下对象的生命周期，不要在不需要时不挂对象。

幻数和文字使我们更难理解它们对代码的影响。 它们是非描述性的，并且经常在一个以上的位置需要相同的值，因此，当您要调整该值时，需要在多个位置进行调整……而总是忘记一个位置！

参数化常量/文字，并为元素赋予有意义的名称。

我们编写的所有代码都意识到会被同行评审。

清楚地布置代码，以使其易于阅读，理解和使用描述性名称，以便您的同事可以解密所有内容。 当您在那里时，请先查看自己的拉取请求，然后再添加对等项。

使用源代码管理时不遵循某个过程可能会导致提交未经测试的代码。 它还可能导致提交遗失，进而破坏同级的构建。

遵循 git Flow ：使用功能分支，重新设置基础并使用拉取请求。 创建发布分支，仅允许错误修复，并禁止从dev分支进行合并。

一遍又一遍地执行相同的代码会变得很老，因此我们在代码中寻找有用的模式。 如果有人注意到我们面前的一种模式，为什么还要重新发明轮子呢？

将通用代码拆分为可重用的可测试框架。 寻找现有框架，进行审查并做出贡献。

在事后看来，通常会有更好的方法来做某事，我们对此表示欢迎。 我们认为重做组件化代码的各个部分应该是常见的做法。

识别何时该重构。 如果一段代码偏离了其原始意图，那么重构比将其击败来提交要好！ 可能只是适当地重命名的情况，但是如果有更好的方法可以将其标记为重构。 重构是件好事，这就是世界的运作方式。 相当于生活圈的编码！

…因此，我们认为自己是快乐的编码员。 我们鼓励您尝试一下并创建自己的准则。 通过实施类似的行为准则，您会发现自己可以为将来的项目腾出更多的时间和精力。

保持联系： [e-mail]

在我们的网站We Are Mobile First上查找更多博客文章。