这是一个创建于 179 天前的主题，其中的信息可能已经有所发展或是发生改变。
每次老板让我改什么小问题，都会发现项目要么不能编译，要么跑起来各种报错
然后就是修改这个启动编译问题，再去修小毛病
关键是他们几个人天天都在跑这个项目，一问他们就说都正常，但™编译/报错确确实实存在的，见™鬼了
我只是偶尔搭把手的，每次调试个半天。。
16 条回复 • 2024-06-09 15:19:45 +08:00
 |
1
AmosLi 179 天前
你们单位的不行呗, 等情况好了 赶紧溜
|
 |
2
yph007595 179 天前  2
他们有自己的本地配置文件，没有上传到仓库里
|
 |
3
4ark 179 天前
好项目就不会这样，之前试过一次对着文档都要搞一个小时才能启动，期间找了四五个同事要这个那个资源
|
 |
4
luliumytime 179 天前 via iPhone 1
问就是 node_modules.zip
|
 |
5
HojiOShi 179 天前
我是搞 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 179 天前 1
让他们配置 ci ，不过 ci 不准合并
|
 |
8
weeei 179 天前 1
最牛逼的，他们内部合作一点问题没有。
|
 |
9
IvanLi127 179 天前 1
这很正常，项目没有愿意负责的人主导就是这效果，一直没人管就烂下去了。
八仙过海，各显神通。 |
 |
10
kneo 178 天前 via Android 1
可以想象。
他们自己环境不干净，配置也不干净，脚本也没提交，有时候有什么不对自己瞎改能工作就行了，也不敢提交。时间长都忘了。 项目要是没新人进来的话他们永远不知道仓库里脚本配置有问题。 一问就是自己这没问题，可能是你的问题，假装满不在乎，或者假装自己很忙。 一个词来评价：不负责任。 |
|
11
winterbells OP |
 |
12
sunocean 178 天前
@winterbells 1 ， 和团队保持版本同步是一个好习惯。
2 ，不要一味的追新，不然出问题了锅是你的。 |
|
13
winterbells OP @sunocean 他们也没有统一的版本，新环境下对于没有版本号的依赖只能默认最新了，然后就开始冲突…
|
|
14
sunocean 178 天前
@winterbells 那就是公司管理问题了，没有标准，想怎么样就怎么样
|
 |
15
yjxjn 177 天前
就是项目管理问题。
我做了好几个大项目，上千人那种规模，大家默认是只要有人 PULL 完发现有问题，不好意思，就会追溯到上一版提交的人。 这么做的好处就是，别人留的坑，都别想浪费时间让我擦。 即使有新人上项目，也不存在你说的那种问题。 |
|
16
winterbells OP @yjxjn 这就是大项目的好处了，人多，强迫管理者做规范。小公司难搞
|
Select Language