大型 scala 代码库是否可维护？
我对 scala 有一些经验。我想将其引入到有 10 名成员的新项目中。但是，尽管 scala 具有丰富的表现力，但我非常不确定代码的维护和转移给新团队成员的简单程度。目前我只研究了 scala 上的一个大项目 http://code.google.com/p/factorie/ 和一些 scala DSL(apache Camel)。所以我的问题是，对于中级开发团队来说，与 java、python 和 groovy 相比，scala 的可维护/可支持程度如何？
I have some experience with the scala. I want to introduce it into new project with 10 members. But despite all expressiveness of the scala, I am very unsure of how simple the code can be maintained and transferred to new team members. At the moment I have studied only one big project on a scala http://code.google.com/p/factorie/ and some scala DSL(apache camel). So my question is how much scala maintainable/supportable comparing to java, python and groovy for team of mid level developers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一般来说： 代码库的可维护性取决于（仅举几例）
您可以使用任何可用的语言来制造混乱。可以说，您可以使用任何用于生产用途的编程语言创建任何规模的干净且可维护的项目。
也就是说，scala 的可维护性不应该比 java、python 或 groovy 差。不过，第一个项目的结果可能不太容易维护。
In general: the maintainability of the codebase depends on (to name a few)
You can create a mess using any language available. Arguably you can create a clean and maintainable project of any size using any programming language that is intended for production use.
That said - scala shouldn't be any less maintainable than java, python or groovy. The result of the first project may be less maintainable though.
简短回答：是的
详细回答：与 Java 相比，非常如此。
特征、案例类、模式匹配、更高种类的类型、闭包等都共同消除了样板文件，使您更容易执行 DRY 原则。您的代码库大小约为 1/3，并且隔离关键抽象而不是重复逻辑要容易得多。
更好的测试框架也使得保持一组有效的测试变得更加容易。
当然......所有这一切都是在 Aleksi 对所涉及的个人开发人员的意愿/技能提出观点之后发生的。如果团队没有积极致力于可维护性，那么世界上最可维护的语言也无法帮助您！
Short answer: Yes
Long answer: As compared to Java, very much so.
Traits, case classes, pattern matching, higher-kinded types, closures, etc. all conspire to remove boilerplate and make it easier for you to enforce the DRY principle. Your codebase will be around 1/3 the size, and it's much easier to isolate key abstractions instead of duplicating logic.
Nicer test frameworks also make it far easier to keep an effective set of tests in place.
Of course... All of this comes after Aleksi's points on the will/skill of the individual developers involved. If the team aren't actively aiming for maintainability, the the most maintainable language in the world isn't going to help you!