Java 我应该首先改进公司的哪些工作流程？

我刚开始在一个新的地方工作，我看到他们做了一些我觉得非常糟糕的事情，我想知道他们是真的错了，还是我太严格了。请让我知道我的批评是否到位，以及您对哪个问题最糟糕、应该首先解决的看法。开发都是用Java实现的

不使用svnignore。这意味着不能使用svn stat，开发人员忘记了添加文件和中断构建

生成的文件与提交的文件放在同一文件夹中。无法使用简单的maven clean，必须逐个查找它们。Maven clean并没有将它们全部移除

未修复IDE分析警告。Analyze代码返回大约5000条不同类型的警告

不遵循约定：SpringBean名称有时以大写开头，有时不以大写开头，ant属性有时以下划线开头，有时以点分隔符开头，等等

增量构建需要6分钟，即使没有任何更改

开发人员只使用远程调试，不知道如何从IDE内部运行Tomcat服务器

开发人员总是在每次编译后重新启动服务器，而不是动态地重新加载类并保存服务器的状态。他们至少需要10分钟才能开始检查代码中的任何更改

开发人员仅从命令行编译。当出现编译错误时，他们会手动打开文件并转到有问题的行

项目依赖关系中的一团乱麻。有200多个开源软件被依赖，没有人知道到底需要什么以及为什么。他们知道并非所有的依赖关系都是必需的

将Maven和Ant混合在一起会使两者的优点失效。在一种情况下，甚至依赖项检查也不是由Maven完成的

没有正确使用泛型

开发人员不使用Subversion与IDE的集成（Eclipse、Intellij Idea）

---

你觉得怎么样？我应该从哪里开始？我提到的任何事情都不是真正的问题吗？

你没有提到持续集成，但一个好的开始是在构建失败时给开发人员一个快速的反馈。一旦有了它，您就可以添加代码质量指标，以鼓励他们纠正警告或泛型的错误使用

只有具备了所有这些，您才应该向他们展示如何热部署、调试、使用IDE等等，从而提高他们的工作效率

---

祝你好运：）

一般来说，我认为那些浪费开发人员时间的事情应该首先得到处理。开发者的空闲时间越少，收益就越大

1） 这和12）一起应该优先考虑，因为破坏的构建需要时间

3） IDE警告没有那么重要，因为它们只是警告，可以像未使用的导入一样简单

4） 缺少命名约定不会破坏任何东西，可以逐步强制执行。不管你怎么做，这都需要很多时间。这不应该被高度优先考虑

5） 我假设您有一个独立的构建服务器来处理构建，六分钟听起来不像是很长的时间。如果您没有构建服务器，这将是一项很好的投资

7） 听起来好像所有开发人员都浪费了很多时间，这应该是高度优先的

11） 这些可能会导致在3）中出现很多警告，应该是固定的，但不是最高优先级

---

12） Subversion与IDE的集成应该会有很大帮助，我认为开发人员会认为这非常有用。

我会这样看待它：

• 任何影响生产率的问题都应该首先解决
• 第二，影响盈利能力的问题得到解决（大多数生产率修正也是盈利能力修正）
• 吹毛求疵

因此，您应该具备以下条件（按照我的意见的顺序）：

7-编译后重新启动服务器

5-增量构建速度

6-仅远程调试

8-从命令行编译

12-Subversion集成（与上面的第5部分处于同一级别）

2-生成的文件

11-未正确使用泛型

然后

1-Svingnore

9-项目依赖性（我相信这将花费大量时间）

10-混合Maven+Ant

3-IDE警告

4-公约

从这个意义上讲，我之所以有这种排序，是因为时间和利益的关系。如果用户编译和检查代码需要16分钟，老实说，这简直是疯了。假设一个开发人员每天编译5次，我们大约需要80分钟，什么也不做

在那之后就是生产力。如果您加快开发人员完成工作的速度，完成的工作的营业额将大幅上升。（

盈利能力+++

）

---

这之后就是“吹毛求疵”的事情了。我这样说并不是为了推断它们不重要，但事实上，从外观上看，您有更重要的事情要做，所以在更正代码中的大小写之前，请先完成这些事情。

我不是一个专业用户，我无法对上面的一些内容发表评论，但列表中的大多数内容看起来都是有待改进的好地方。我认为我能给出的最好建议是：

• 慢慢来。他们可能已经这样做了很长时间，可能会抵制改变
• 让团队（可能还有经理）参与变更。召开一次会议，讨论您看到的改进（保持简单，只是一些），他们对这些改进的看法，以及他们是否认为实施这些改进是明智的。然后，如果同意的话，与某人配对，使改进到位
• 提供易于更改的工作实践演示。例如，在实时设置中显示调试会话期间动态类加载的差异
• 对列表进行优先排序