为什么许多老程序员不建议编程新手用 IDE？

倒是不会建议不要新手用 ide，但我会建议新手不要用 ide 的「项目模版」功能，这两个建议是有区别的。

ide 的目的就是提高编码效率，建议新手不要用 ide 是不合理的。这就好像，你手上有武林秘籍，能丰富你的招式，但你非不让新手练，这不是给新手绊脚么？

但是，老手真不建议新手用 ide 的项目模版功能，这个功能会阻碍新手修炼内功。新手至少得学会自己从 cli 开始创建一个项目，知道项目的构建流程，用了哪些构建插件，并学会配置 ide 去识别这个从 cli 端创建起来的项目。如果新手不会配置，那大概率当新手拿了别人的项目并用 ide 打开后就只能等着一片报红。

新手不应该只会用 ide 一件项目模版，然后就只管开发逻辑，不管构建逻辑了。比如后端，springboot 很流行。但很多新手开发了半天，只会从 ide 里面点点点然后嗖地一下启动一个标准的 spring 项目模版，然后只管开发 .java 文件，pom.xml 的构建逻辑是一行看不懂。可能遇到个需要添加特殊 starter 的依赖就抓瞎了。甚至可能只会 ide 启动 spring 然后和别人联调，跑课程项目的时候也只会开着个 ide 去演示，怎么打包部署到服务器上独立运行一概不知。

这是不行的，新手得学会这些繁琐的构建配置。

那么为什么一定要学会繁琐的构建配置，而不用统一模版呢？能跑就行了呗。因为真实项目的构建需求往往很复杂，ide 默认的项目模版是无法涵盖生产需求的。还是以 java 工程为例子：

• 如果一个工程里遇到了依赖冲突，该怎么排查？该怎么解决？
• 多模块的 pom 工程里怎么统一标准？
• 对于大型项目如何加速构建速度？是否可以把一些常用依赖下沉到容器 / 服务器，然后构建的时候常用依赖的 scope 用 provided？
• 如果涉及到多 jdk 版本的交付？如何设置 profile 来配置不同构建步骤？
• 如果团队里有个大牛写了一些自动生成代码的 maven 构建插件，你该如何在 ide 里做参数配置保证每次 debug / run 的时候都运行这些插件？
• jvm 查找类的顺序跟依赖申明的顺序关系是什么？如果有紧急 bug 如何通过同名类覆盖原来的实现？

虽然这些问题并不一定涉及核心业务逻辑，但是解决这些问题往往可以给一个团队带来很多效率上的提升。如果别人不能解决，你能解决，那么你就相比于别人有更加不可替代的价值。甚至可以更快加薪晋升。

其实我所罗列的这些问题，在企业级的项目里很常见，并且只要你对工程项目的构建流程和配置文件有一定的熟悉程度，都不难解决，在别的语言和项目体系里，客制化构建配置的需求也比比皆是。而去熟悉这些项目，就需要大家在写代码之初养成一个好习惯，去学习配置、了解配置，而不是只会用 IDE 自带的项目模版。