Scala是一种维护噩梦

Scala也可以通过淹没在代码复杂性或依赖地狱燃烧它们的团队来缓慢生产力。 Scala以疯狂的，复杂的代码而闻名 - 每个人都知道那个风险因素。 这篇文章的其余部分侧重于维护负担，较少讨论的Scala生产力排水。 Scala库需要与不同的Scala版本编译。 Utest v0.7.7为Scala 2.11，Scala 2.12和Scala 2.13发布了单独的JAR文件。 Scala 2.12依赖于utest v0.7.7的项目需要抓住与Scala 2.12编译的JAR文件。 Scala 2.10用户无法使用Utest v0.7.7，因为没有JAR文件。 小型版本在大多数语言中兼容。 使用Python 3.6构建的Python项目可以在Python 3.7项目中使用。 想想Scala小版本，如其他语言的主要版本。 频繁的主要版本颠簸意味着很多升级/维护工作。

一些依赖关系强制您使用其他库可能会停止支持的旧Scala版本。

Databricks平台未开始支持Scala 2.12 Till到2020年6月发布的DataBricks Runtime 7.将此与Scala发行日期进行比较：

有一个全年的Scala社区转换为Scala 2.13，Spark社区仍然陷入Scala 2.11。这是一个很大的差距，特别是当您认为Scala小版本与其他语言中的主要版本差异一样。

在Spark用户能够升级到Scala 2.12之前，许多Scala项目很长时间丢弃了Scala 2.11的支持。

Spark Devs经常需要搜索项目的Maven页面，并查找他们正在使用的Scala版本的最新项目。

开源维护者累了或转移到不同的技术堆栈。许多人愤怒退出scala（Scala社区的另一个独特因素）。

Scala开源libs在被遗弃后很久就无法使用。拍摄Spark-Google - 电子表格。

该项目不再维护，并且所有JAR文件都适用于Scala 2.10 / Scala 2.11。

假设您有一个火花2 / scala 2.11项目，它取决于Spark-Google - 电子表格，并希望升级到Spark 3 / Scala 2.12。 Spark-Google - 电子表格依赖项将阻止您进行升级。您需要重新拍摄，升级它，并将其发布或发布您的repo中的代码。

SBT-CI-Release项目提供了将项目发布到Maven的步骤的最佳概述。

您需要打开JIRA机票以获取命名空间，创建GPG键，键盘中的寄存器键，并添加SBT插件以获取手动发布过程工作。这比发布到PYPI或RubyGems更多的工作。

知道如何正确发布图书馆也很困难。人数是一个流行的火花库，用于单位测试数据，该数据陷入了尝试为每个版本的Scala / Spark版本的不同组合发布各种JAR文件的陷阱。

构建矩阵难以维护，特别是如果您希望构建矩阵中的不同小区的不同代码组合。

不知何故的现有矩阵滑出并具有与火花3罐相关联的Scala 2.11依赖性。不努力单一，只是展示资助的资金良好，流行的项目甚至可以在处理Scala发布复杂性时绊倒。

Delta Lake项目使用可维护的发布过程，避免构建矩阵。自述文件包括此免责声明：“从0.7.0开始，Delta Lake仅适用于Scala版本2.12”。

李详细介绍了SBT的问题，并创建了一个新的解决方案，但新项目仍在使用SBT构建。

SBT是一个高度活动的项目，超过总计10,000个提交，频繁添加新功能。

Scala项目维护者需要跟踪SBT版本并经常在其项目中升级SBT版本。大多数SBT版本都是常常伴的。

Scala社区应该感谢@ EED3SI9N在这个项目的不懈努力。

SBT插件生态系统并不维护。 SBT插件是版本的和添加的，与常规库依赖项分开，因此SBT项目有两个级别的依赖性地狱（常规依赖项和SBT插件）。

无法完全避免SBT插件。您需要将它们添加以执行构建胖jar文件（SBT-Supply）或将JAR文件发布到Maven（[SBT-SONATYPE] https://github.com/xerial/sbt-sonatype（）和sbt-pgp等）。

tut是已弃用和需要维护操作的插件的示例。至少他们提供了一个迁移指南。

最好避免像瘟疫一样的SBT插件（除非你喜欢维护）。

ScalAtest是最受欢迎的Scala测试框架，最近决定完全忽略语义版本，并通过轻微的释放进行重大打破变化。

Spark和流行的测试库，如火花 - 测试基础取决于ScalAtest核心类。 Spark-Testing-Base用户将无法使用最新版本的ScalAtest。

什么应该火花测试基础？它们已经为Scala＆amp的不同版本拥有二维构建矩阵;火花。它们是否应该为Scala / Spark / ScalaTest的所有可能组合制作三维构建矩阵？ Spark-Testing-Base已经在Maven拥有592个文物。

这里没有好的解决方案。当多个水平的核心借调组件都造成破坏变化时，稳定性和向后兼容性是不可能的。

这种维护讨论可能会思考“为什么有人会使用Scala？”

Scala真的仅适用于困难的问题，如构建编译器，这些难题来自强大的Scala编程功能。

作为雷诺兹提到的，Scala是一种良好的火花语言，因为催化剂和钨依赖于模式匹配。

应避免Scala以实现不需要提前编程语言功能的更容易的问题。

即使是Scala应用程序的最基本也需要维护。升级次要Scala版本可能会导致破坏更改，SBT版本需要定期撞击。

具有库依赖性的Scala项目更难维护。确保您依赖于积极维护的库，并显示为多个Scala版本提供长期支持的模式。

优先顺序依赖依赖性库通过LIB将传递依赖项拉到您的项目中。依赖地狱在scala痛苦。

竭尽全力避免向项目添加库依赖关系。看看我一个流行的Scala库之一的构建文件，并查看所有依赖项是测试或提供的。我宁愿编写数百行代码，而不是添加依赖项，方正地到了库。

不要使用高级SBT功能。使用最小的功能集并尝试避免多项目构建。

使用最小的SBT插件集。跳过项目功能通常比添加SBT插件更好。对于添加SBT插件，我宁愿没有与开源项目相关联的微型材料。我肯定不是添加一个SBT插件，以重命名ScalAtest类，以便在次要发布中发生的重大破坏更改。

ScalAtest语义版本化违规激励我将项目转移到Utest和Munit。感谢ScalaTest对Scala社区的贡献，但希望避免多余的冗余方式做同样的事情。

换离SBT和使用轧机并不容易。李的LIBS似乎是唯一一个实际使用磨坊的流行。其余社区仍在SBT上。

大多数开发人士都不想学习另一个构建工具，因此磨坊将很难获得市场份额。我会建立磨坊项目，但认为它会阻碍开源贡献，因为其他人不想学习另一个构建工具。

Scala是一种功能强大的编程语言，尽管维护开销，但仍可以使小型团队高效。我在这篇文章中提到的所有缺点都可以克服。 Scala是一个非常强大的工具。

Scala还可以在程序员中发出怪异，并创建令人难以难以遵循的码布，与维护成本无关。一些程序员对功能规划范式和类别理论更感兴趣，而不是为支付客户的业务价值而产生的苦差事。

完整的Scala Nightmare是难以修改和高维护成本的难度代码的双重Whammy。 这双鞭子是为什么Scala在许多圈子里有可怕的声誉。 Scala可以是超级力量或陷入组织的令人难以置信的责任。 在频谱的一端，我们有Databricks，这是一个建立在Scala上的280亿公司。 在频谱的另一端，我们有一个遗弃的Scala图书馆的生长墓地。 只有掷骰子，如果您的团队足够好以超过Scala维护负担成本，请使用Scala。