每次老板让我改什么小问题,都会发现项目要么不能编译,要么跑起来各种报错
然后就是修改这个启动编译问题,再去修小毛病
关键是他们几个人天天都在跑这个项目,一问他们就说都正常,但™编译/报错确确实实存在的,见™鬼了
我只是偶尔搭把手的,每次调试个半天。。
1
AmosLi 173 天前
你们单位的不行呗, 等情况好了 赶紧溜
|
2
yph007595 173 天前 2
他们有自己的本地配置文件,没有上传到仓库里
|
3
4ark 173 天前
好项目就不会这样,之前试过一次对着文档都要搞一个小时才能启动,期间找了四五个同事要这个那个资源
|
4
luliumytime 173 天前 via iPhone 1
问就是 node_modules.zip
|
5
HojiOShi 173 天前
我是搞 Android 的,每次要导入调试什么几年前的 demo 或库,都要像修文物一样改来改去,也是习惯了。不过需要改的东西也不是很多,熟练的话实际上不需要很长时间。
|
6
winterbells OP @AmosLi 主要提交太随意了…也不测一下,然后都在自己的分支上,很久才拉一下 master
@yph007595 有的时候是配置文件缺失,有的时候 main 都报错 @4ark 主要是看人,我基本都是提交前合并 master ,跑完一遍流程再提 pr 。有人测试没问题,提 pr 了,再修改个乱七八糟的东西就不测了 @luliumytime 虽然不是 node.js 但依赖也巨 tm 坑人… 不知道怎么回事,总是喜欢魔改一些库,然后一更新就 sb 了,一堆冲突 @HojiOShi 我主要也是做安卓的,花了两年才把魔改的三方库抽离出来,还有数据库也抽成模块。整理乱七八糟的 build gradle 。 一开始一堆 gradle 语法的 warning ,直到升级版本变成 error 了才不得不改。结果现在那些东西全被我删了😅。根本不需要奇怪的 lint ,编译检查什么的,速度还变快了 |
7
yleimk 173 天前 1
让他们配置 ci ,不过 ci 不准合并
|
8
weeei 173 天前 1
最牛逼的,他们内部合作一点问题没有。
|
9
IvanLi127 173 天前 1
这很正常,项目没有愿意负责的人主导就是这效果,一直没人管就烂下去了。
八仙过海,各显神通。 |
10
kneo 172 天前 via Android 1
可以想象。
他们自己环境不干净,配置也不干净,脚本也没提交,有时候有什么不对自己瞎改能工作就行了,也不敢提交。时间长都忘了。 项目要是没新人进来的话他们永远不知道仓库里脚本配置有问题。 一问就是自己这没问题,可能是你的问题,假装满不在乎,或者假装自己很忙。 一个词来评价:不负责任。 |
11
winterbells OP |
12
sunocean 172 天前
@winterbells 1 , 和团队保持版本同步是一个好习惯。
2 ,不要一味的追新,不然出问题了锅是你的。 |
13
winterbells OP @sunocean 他们也没有统一的版本,新环境下对于没有版本号的依赖只能默认最新了,然后就开始冲突…
|
14
sunocean 172 天前
@winterbells 那就是公司管理问题了,没有标准,想怎么样就怎么样
|
15
yjxjn 171 天前
就是项目管理问题。
我做了好几个大项目,上千人那种规模,大家默认是只要有人 PULL 完发现有问题,不好意思,就会追溯到上一版提交的人。 这么做的好处就是,别人留的坑,都别想浪费时间让我擦。 即使有新人上项目,也不存在你说的那种问题。 |
16
winterbells OP @yjxjn 这就是大项目的好处了,人多,强迫管理者做规范。小公司难搞
|