明明可以图形化操作，非得整成编程的方式。
明明可以把配置项列出来，让开发人员去选择 /配置，点下一步 /下一步就构建完了。非得弄成去查手册写代码。
不够友好，也浪费时间。。有点反人类的设计。。
明明可以把配置项列出来，让开发人员去选择 /配置，点下一步 /下一步就构建完了。非得弄成去查手册写代码。
不够友好，也浪费时间。。有点反人类的设计。。
This topic created in 2432 days ago, the information mentioned may be changed or developed.
 |
1
这个帖子会挨喷，前排围观
|
3 |
jeremaihlooMar 6, 2020
2
这个帖子会挨喷，前排围观 +1
|
 |
3
复制黏贴他不香吗？我每起一个 module，你都要我点下一步 /下一步，这才是浪费时间吧？
|
 |
profMar 6, 2020
4
谷歌为了 groovy 语言的推广吧。可能是商业产物。
|
 |
AurtMar 6, 2020
5
最大的问题不是性能差么？
|
 |
zongrenMar 6, 2020
6
可视化有啥优点？
|
 |
murmurMar 6, 2020
7
gradle 除了必须得挂各种代理还得搞定 bintray 的问题其余的都还行
|
 |
8
经常打开一个项目 动不动就在那下载，真不知道我啥也不干就看看代码，它要在那里下载什么卵几把玩意
|
 |
zagfaiMar 6, 2020
9
图形化就是低效的代表。 嗯 不喷多 就喷这一点。
|
 |
JerryChaMar 6, 2020
10
nuget 真香
|
 |
chendyMar 6, 2020
11
目标用户不会写代码才有图形化的刚需啊…
|
 |
12
可以配置文件加上图形化，类似 vscode 那种，自动生成菜单可以编辑，当然也能打开原始 json 直接撸
|
 |
13
你的标题我是有一定认可的，但是这个内容不敢苟同
|
 |
hmztMar 6, 2020
14
|
 |
251243021Mar 6, 2020
15
可视化并不是刚需...但是需要挂代理和各种网络问题才是让人烦恼的
|
 |
CbdyMar 6, 2020 via Android
16
不敢苟同
|
 |
InkStoneMar 6, 2020
17
图形化处理不了复杂的场景。自定义非标准的 task，或者写个插件，虽然不是每个项目都需要，但也不是什么罕见的事情吧
|
 |
zgqqMar 6, 2020
18
我喜欢 gradle 这种方式
|
 |
skinnyMar 6, 2020
19
最不能忍受的是慢……
|
 |
hantsyMar 6, 2020
20
Gradle 可以浪费大量的时间，对于公司上班的，用来打酱油真不错。
Groovy DSL 语法除了人阅读比较友好外，没其它好处，但是什么配置修改都要查文档。对于 Maven 的默认的 XML （成熟的规范，工具支持优秀），Gradle 下工具支持就差得太远了，工作效率真的太低了。 |
 |
bookitMar 6, 2020
21
这货本身就巨大、巨慢，
搞得繁文缛节，纯属垃圾 |
 |
HuHuiMar 6, 2020
22
你这个点完全是在吐槽 DSL 啊
|
|
chendyMar 6, 2020
23
@hmzt 但是问题是，对于这个场景，能图形化的东西写代码也不复杂，复杂的东西图形化也没多简单
想了一下可能楼主是是没用过 gradle 被迫使用而且用不明白所以无能狂怒？ |
|
hmztMar 6, 2020
24
@chendy 写代码是不复杂, 问题是条条框框的规则不知道怎么写, 这种时候界面要比文档友好太多了, 尤其是 android studio gradle 规则大改过一次, 指不定哪天又改了, 如果有个界面就能只关心功能不用去管那些指令规则了
|
 |
seesawzhaoMar 6, 2020
25
这货主要是慢，各种慢，连仓库慢，构建慢。
|
 |
luren123Mar 6, 2020
26
@hmzt 可视化好处确实非常多，就拿 git 来说，命令行是可以操作，详细 diff 和 冲突处理，还是 sourceTree 这种来的爽，清晰、直观、不容易出错；
|
 |
busymilkMar 6, 2020
27
+1
|
 |
yinzhiliMar 6, 2020
28
作为后端开发者我觉得 maven 比 gradle 更好用
|
 |
slyang5Mar 6, 2020
29
我觉得非常友好 用了就回不去了 😆。有点学习成本吧 用起来非常优雅
|
 |
zhuangzhuang1988Mar 6, 2020
31
还是微软的东西设计好
能图形则图形 |
 |
nightwitchMar 6, 2020
32
标题起的不错，内容没喷到点上。随着功能的发展，图形化的界面很快就会复杂到很难使用，最后变成不得不谷歌才能知道该点击哪一个正确的按钮。（想一下 Excel 里究竟有多少功能是你必须要谷歌才知道怎么用的
http://www.yinwang.org/blog-cn/2017/05/25/dsl 看看王垠是怎么喷的 |
 |
secondwtqMar 7, 2020
33
首先，“图形化”和"文本配置“没有本质性区别。
“把配置项列出来”可行性不高——Gradle 配置文件是一个完整的 Groovy 脚本 + 一套 DSL，全都列出来的话估计比 System32 文件夹还大 其次，虽然楼主认为 Gradle 低效，但是 Gradle 实际效率横向比较是不差的——也就是说 Gradle 目前还是比较符合 state of the art 的，目前没有明显更优的选择——或者说“高效图形化配置”这一个领域现在几乎是空白，需要像 Larry Tesler 那种大胆创新。我个人非常欢迎楼主进行自己的探索。 最后，我个人认为更根本的问题出在我们为什么需要如此复杂的规则。Gradle 本身的设计没有什么大问题，但是 Gradle 解决的问题和需求本身可能是错误的。 |
 |
6IbA2bj5ip3tK49jMar 7, 2020
34
这玩意儿确实难用。主要的点在，不管你用什么 IDE/编辑器，不看文档压根下不下去。
kotlin dsl > maven >>>>>>>>>> groovy dsl |
|
6IbA2bj5ip3tK49jMar 7, 2020
35
@xgfan 压根写不下去。
|
 |
mxalbert1996Mar 7, 2020 via Android
36
最基本的配置不是都可以在 GUI 里设定么？更高级的各种自定义任务之类的本来就是 GUI 不可能完成的。
|
 |
jordanqinMar 7, 2020
37
图形化的话，自动化打包、自动发布、根据各种业务条件打包怎么办？
|
 |
beneoMar 7, 2020
38
gradle 最大的问题是，版本更新太快
|
|
beneoMar 7, 2020
39
不是完全的向下兼容，然后又得去看文档。
|
 |
i18nsMar 7, 2020
40
主要问题是：版本太多；加载太慢；不同项目依赖不一样，打开不了几个项目，那可怜的 ssd 空间就不够了。
|
 |
dragonsunmoonMar 7, 2020
41
这个帖子会挨喷，前排围观 +1
|
 |
HangoXMar 7, 2020
42
楼主是因为配置的是 Android 的配置吧？如果是的话，我说一下，gradle 的配置其实不复杂，复杂的是 AGP 配置，这个东西一开始没有文档，没有代码提示，什么鬼都没有，的确很蛋疼。但是现在 as4.0 谷歌加入了强大的 gui 配置，现在可以直接 gui 配置风味了。你要是参与到大型项目中，gradle 是非常好的一个东西。因为打包配置非常复杂，gui 是绝对不能做到的，就是需要敲代码
|
 |
fairytale110Mar 7, 2020
43
你的需求是 XCode 吧？哈哈哈
|
 |
FleeyMar 7, 2020
44
个人认为写 react 真繁琐，明明要做什么 Jquery 莽就行了，非要整一大堆开发环境，明明有些事情 Jquery 莽几下就弄好了，非得去学语法和轮子用法。不够友好，也浪费时间。。有点反人类的设计
|
 |
cigarzhMar 7, 2020
45
你来写
|
 |
zysuperMar 8, 2020
46
sbt 表示这些都是浮云。
|
 |
m30102Mar 17, 2020
48
gradle 不好的地方就是随便在网上拉一个 android 项目来下导入基本都是构建失败。
构建失败有时是玄学，与 As 版本，gradle 版本，gradle 插件版本 都可能有关系 |
Select Language