我在一个从事广泛Java开发的组织工作。我们的团队很小,有一个短暂的项目,敏捷开发宪章.我们将利用其他组现有的QA资源,并可能为客户和合作伙伴贡献代码。
反对Scala开发的主要理由是:
我的经验是,Scala通常比Java更容易阅读,只需很少接触到这种语言,并且能够使用现有的Java工具(如Junit ),可以将对现有测试策略的负面影响降到最低。
我估计,根据问题的不同,Scala中的开发可能比等效的25%+开发速度更快。根据我个人的经验,这只是一根指头。如果有人有提高效率的证据,请分享。
我还想编译一个清单,列出在Java上使用Scala的主要好处。请分享你的最爱。
谢谢,约翰
发布于 2011-04-01 17:30:29
不要说-在Scala里建些东西。我建议测试您的Java应用程序。下面是我为Java项目设置Scala规范作为测试框架的一篇文章:http://janxspirit.blogspot.com/2011/01/sneaking-scala-through-alley-test-java.html
人们通常对你编写测试很满意,不管你喜欢什么。
在我的经验中,唯一能支持管理的论点是,你可以在更短的时间内完成更多的工作,而高质量的工作才能降低持续维护的成本。我建议将语言的优雅性、其表现力等问题留给开发人员讨论,而不是与管理层讨论。
强调您可以使用现有的Java库(考虑“利用现有的投资”)。另外,如果您使用Spring或类似的方法,请考虑Java接口的Scala实现,这样可以让那些想要尝试Scala的开发人员在不干扰其他人的情况下这样做。
最重要的是,建立一些东西并证明你能做到。我已经习惯于在几个小时内构建web服务,而在Java中构建web服务的时间要长得多--想想吧。下面是我如何做到这一点的一个例子:http://janxspirit.blogspot.com/2011/01/quick-webb-app-with-scala-mongodb.html
我不认为外部统计数据会很有说服力,因为开发人员在Scala中的工作效率比在Java中更有效的能力实际上取决于开发人员。但如果你能证明的话,你一定会有所收获的。祝好运!
发布于 2011-04-01 17:09:51
实际做一个项目比获得做一个项目的许可容易。
此外,所有来自组织外部的证据都被那些不想改变的人所轻视。他们只是说“这在这里行不通。”(或者更糟的是,“这在现实世界里行不通。”)
你不能收集足够多的外部间接证据。
但是,如果您实际上在Scala中执行了一个实际项目,则对话是非常不同的。你有一个成功的记录,以较低的成本。没有人能对此提出异议。
不幸的是,我们已经走上了获得许可的道路,现在处于不太理想的谈判地位
不怎么有意思。
如果你认为你不得不继续请求许可,那你就完蛋了。
要点是:“请求宽恕比请求许可容易”。
启动一个项目可以在任何时候完成,不管以前的政治是什么(或没有)。
你只要开始这个项目。即使你已经问过一次(或十几次)拒绝。
当你成功的时候,你会因为太成功而请求原谅。
发布于 2011-04-01 23:25:39
大多数管理类型都不关心Scala的好处。他们对新程序员的可用性、培训现有程序员的成本、语言的长期支持前景等都会产生不利的风险。
更糟糕的是,这些人也是监督Java开发人员的人,他们会相信他们做得非常好。暗示一种改变可能被解释为对他们能力的一种花招。
因此,诀窍是(首先)确定Scala与Java完全可互操作,您正在这里建立在过去的成功和现有投资的基础上。然后继续讨论Scala如何通过降低当前的风险来改进它:代码维护成本、生产软件的缺陷、上市时间/机会成本等等。
如果您的经理非常面向人(而且很多人都是如此),那么指出Scala被认为是一种值得使用的性感语言并不会有什么坏处。漂亮的代码不太可能给你的经理留下深刻的印象,但是使用一些有助于吸引和留住有才华的开发人员的东西肯定会吸引更多的兴趣。
Scala不仅仅是Java的替代品,它是一种自然的发展--当你到达游戏的顶端并想更进一步的时候,你会去的地方。能够进行这种迁移恰恰表明了你已经有多好了,所以如果有必要的话,不要为一些自我按摩而感到羞愧。
最后,如前所述,要积极主动!通过一个演示项目来做一些事情,并让其他开发人员对它感兴趣。几个人的基层运动会更有说服力.
https://softwareengineering.stackexchange.com/questions/64432
复制相似问题