个人认为 Gradle 这种构建方式真繁琐

[maxxfire]

明明可以图形化操作，非得整成编程的方式。
明明可以把配置项列出来，让开发人员去选择 /配置，点下一步 /下一步就构建完了。非得弄成去查手册写代码。
不够友好，也浪费时间。。有点反人类的设计。。

[tulongtou]

这个帖子会挨喷，前排围观

[jeremaihloo]

这个帖子会挨喷，前排围观 +1

[fansangg]

复制黏贴他不香吗？我每起一个 module，你都要我点下一步 /下一步，这才是浪费时间吧？

[prof]

谷歌为了 groovy 语言的推广吧。可能是商业产物。

[Aurt]

最大的问题不是性能差么？

[zongren]

可视化有啥优点？

[murmur]

gradle 除了必须得挂各种代理还得搞定 bintray 的问题其余的都还行

[xiangyuecn]

经常打开一个项目 动不动就在那下载，真不知道我啥也不干就看看代码，它要在那里下载什么卵几把玩意

[zagfai]

图形化就是低效的代表。 嗯 不喷多 就喷这一点。

[JerryCha]

nuget 真香

[chendy]

目标用户不会写代码才有图形化的刚需啊…

[firemiles]

可以配置文件加上图形化，类似 vscode 那种，自动生成菜单可以编辑，当然也能打开原始 json 直接撸

[qiyuey]

你的标题我是有一定认可的，但是这个内容不敢苟同

[hmzt]

@chendy
@zongren
图形化好处多了, 如果随便点点界面就能实现想要的功能谁还会去写代码, 一页一页翻文档有界面操作那么直观吗, 有个一键生成配置文件的交互界面它不香吗

[251243021]

可视化并不是刚需...但是需要挂代理和各种网络问题才是让人烦恼的

[Cbdy]

不敢苟同

[InkStone]

图形化处理不了复杂的场景。自定义非标准的 task，或者写个插件，虽然不是每个项目都需要，但也不是什么罕见的事情吧

[zgqq]

我喜欢 gradle 这种方式

[skinny]

最不能忍受的是慢……

[hantsy]

Gradle 可以浪费大量的时间，对于公司上班的，用来打酱油真不错。

Groovy DSL 语法除了人阅读比较友好外，没其它好处，但是什么配置修改都要查文档。对于 Maven 的默认的 XML （成熟的规范，工具支持优秀），Gradle 下工具支持就差得太远了，工作效率真的太低了。

[bookit]

这货本身就巨大、巨慢，

搞得繁文缛节，纯属垃圾

[HuHui]

你这个点完全是在吐槽 DSL 啊

[chendy]

@hmzt 但是问题是，对于这个场景，能图形化的东西写代码也不复杂，复杂的东西图形化也没多简单
想了一下可能楼主是是没用过 gradle 被迫使用而且用不明白所以无能狂怒？

[hmzt]

@chendy 写代码是不复杂, 问题是条条框框的规则不知道怎么写, 这种时候界面要比文档友好太多了, 尤其是 android studio gradle 规则大改过一次, 指不定哪天又改了, 如果有个界面就能只关心功能不用去管那些指令规则了

[seesawzhao]

这货主要是慢，各种慢，连仓库慢，构建慢。

[luren123]

@hmzt 可视化好处确实非常多，就拿 git 来说，命令行是可以操作，详细 diff 和 冲突处理，还是 sourceTree 这种来的爽，清晰、直观、不容易出错；

[busymilk]

+1

[yinzhili]

作为后端开发者我觉得 maven 比 gradle 更好用

[slyang5]

我觉得非常友好 用了就回不去了 😆。有点学习成本吧 用起来非常优雅

[poemrain]

@luren123 赞同

[zhuangzhuang1988]

还是微软的东西设计好
能图形则图形

[nightwitch]

标题起的不错，内容没喷到点上。随着功能的发展，图形化的界面很快就会复杂到很难使用，最后变成不得不谷歌才能知道该点击哪一个正确的按钮。（想一下 Excel 里究竟有多少功能是你必须要谷歌才知道怎么用的

http://www.yinwang.org/blog-cn/2017/05/25/dsl
看看王垠是怎么喷的

[secondwtq]

首先，“图形化”和"文本配置“没有本质性区别。

“把配置项列出来”可行性不高——Gradle 配置文件是一个完整的 Groovy 脚本 + 一套 DSL，全都列出来的话估计比 System32 文件夹还大

其次，虽然楼主认为 Gradle 低效，但是 Gradle 实际效率横向比较是不差的——也就是说 Gradle 目前还是比较符合 state of the art 的，目前没有明显更优的选择——或者说“高效图形化配置”这一个领域现在几乎是空白，需要像 Larry Tesler 那种大胆创新。我个人非常欢迎楼主进行自己的探索。

最后，我个人认为更根本的问题出在我们为什么需要如此复杂的规则。Gradle 本身的设计没有什么大问题，但是 Gradle 解决的问题和需求本身可能是错误的。

[6IbA2bj5ip3tK49j]

这玩意儿确实难用。主要的点在，不管你用什么 IDE/编辑器，不看文档压根下不下去。
kotlin dsl > maven >>>>>>>>>> groovy dsl

[6IbA2bj5ip3tK49j]

@xgfan 压根写不下去。

[mxalbert1996]

最基本的配置不是都可以在 GUI 里设定么？更高级的各种自定义任务之类的本来就是 GUI 不可能完成的。

[jordanqin]

图形化的话，自动化打包、自动发布、根据各种业务条件打包怎么办？

[beneo]

gradle 最大的问题是，版本更新太快

[beneo]

不是完全的向下兼容，然后又得去看文档。

[i18ns]

主要问题是：版本太多；加载太慢；不同项目依赖不一样，打开不了几个项目，那可怜的 ssd 空间就不够了。

[dragonsunmoon]

这个帖子会挨喷，前排围观 +1

[HangoX]

楼主是因为配置的是 Android 的配置吧？如果是的话，我说一下，gradle 的配置其实不复杂，复杂的是 AGP 配置，这个东西一开始没有文档，没有代码提示，什么鬼都没有，的确很蛋疼。但是现在 as4.0 谷歌加入了强大的 gui 配置，现在可以直接 gui 配置风味了。你要是参与到大型项目中，gradle 是非常好的一个东西。因为打包配置非常复杂，gui 是绝对不能做到的，就是需要敲代码

[fairytale110]

你的需求是 XCode 吧？哈哈哈

[Fleey]

个人认为写 react 真繁琐，明明要做什么 Jquery 莽就行了，非要整一大堆开发环境，明明有些事情 Jquery 莽几下就弄好了，非得去学语法和轮子用法。不够友好，也浪费时间。。有点反人类的设计

[cigarzh]

你来写

[zysuper]

sbt 表示这些都是浮云。

[zongren]

可视化有啥优点？
@hmzt 但是我感觉图形化不一定比代码效率高，可以参考各种图形化编程工具，很难用

[m30102]

gradle 不好的地方就是随便在网上拉一个 android 项目来下导入基本都是构建失败。
构建失败有时是玄学，与 As 版本，gradle 版本，gradle 插件版本 都可能有关系

[byte10]

@m30102 这个观点，我深表赞同，都不知道谁设计这出声玩意，学习成本高，不向下兼容。难搞。很多坑。不不过 这安卓本来就麻烦，没办法