走另一条路的6个步骤

尽管Bob叔叔警告The Dark Path时过多批评强类型编译器，但我认为还有很多需要考虑的问题。 除了使用使我们感到安全和免受空值引发的异常影响的编程语言外，您还可以采用很多其他途径，这些途径并不那么黑暗。

1. 自动化测试
2. 林亭
3. 编码标准
4. 代码评论
5. 持续学习
6. 建筑组织

自动化测试

正如Bob叔叔指出的那样，自动化测试非常重要。 它通常被视为与动态语言之间的平衡，动态语言在编译器中对强类型语言没有很好的保护。 JavaScript，Ruby和Python都从测试中受益匪浅，这些测​​试可确保代​​码正常工作，并且尽早发现并及时发现问题。 我认为我们都可以同意，可以全部自动化的单元测试，功能测试，UI测试和集成测试可以照亮黑暗的道路。

林亭

静态分析会在编译代码时生成警告和错误，涵盖了硬性要求和一些有力的建议。 但是编译器适用于计算机。 短毛绒为人们工作。 使用SwiftLint，可以识别代码的多种改进方式，并为项目的维护方式设定标准。 您可以从一开始就使用最少数量的棉绒规则开始，然后逐渐启用更多规则。 它确实可以帮助使代码库的外观和感觉更好，并且允许linter告诉您在提交更改之前可以进行哪些改进，从而可以减少代码审查中的反馈。 它还设置了编码标准，这是下一步。

编码标准

大多数编码标准都很轻巧，这很好。 最好使其简短而甜美。 如果不能轻易记住这些标准，就不会那么严格地遵循它们。 这些标准也应被视为准则，而不是硬性要求集，这些要求实际上可能会随着团队和所使用技术的变化而随着时间而改变。 新的思想和技术一直在涌现，而当前的编码标准可能会包含这些思想和技术。

代码评论

随时间推移设置编码标准的一种方法是使用代码审查。 当您的团队发现编码模式来鼓励或劝阻时，现在是开始就这些发现进行一对一对话的好时机。 随着对代码审查的反馈变得有些重复，可以将这些技巧写下来，以一种不太短暂的方式与团队分享。 代码审查的目的应该是一起学习并分享有助于提高代码质量的技巧。 代码审查不应该是变更需求的清单，因为它将迅速将过程转变为开发周期中不受欢迎的步骤，从而在团队中引起不满。 没有人想要。 而是将其视为分享技巧并更好地了解其他人如何进行软件开发的机会。 对于审稿人来说，这是一个学习和提倡更改的绝佳机会，一旦更改代码，更改可能会影响他们的工作。

持续学习

在常规代码审查期间，会发现许多有关代码更改的发现，以及有关团队中每个人的强项，弱项以及兴趣和激情的发现。 除了在编码标准中添加更多内容外，撰写内部博客文章甚至与团队建设相关的公共博客文章也很有帮助。 写下并分享您所学的内容是巩固这些课程的好方法。 有时不妨将这些课程中的一些内容介绍给整个团队，也许要点午餐，以供不时的午餐和学习 。 当发现兴趣和激情时，鼓励博客文章和演示文稿加倍努力学习并为团队造福的好提示。

建筑组织

最后，只需将所有工作分解成多个部分，以便团队的不同成员可以拥有不同的模块，这些模块就可以整体上取得很多进展。 首先，设计和计划一个定义明确，目的有限的模块要容易得多，可以对其进行构建和测试以表明其按预期工作。 其次，随着新成员加入团队，让他们一次在一个模块上加速工作并让他们在较短的时间内拥有它的所有权变得容易得多，这样他们就可以掌握它并尽快开始进行有用的更新。 第三，它使团队有机会按时处理不同的模块，以更多地了解项目的其余部分，并在此过程中了解他们的新知识。