有人像我一样讨厌本地无法运行起来的项目的吗？

[RedisMasterNode]

交接过来的项目本地运行不了，看代码能上手但是调试效率很低，不知道每个接口运行进来是怎么走的，每个方法返回了什么数据，最终如何形成整体的大响应 Body 。

最搞笑的是并不是因为又什么历史包袱，而是说，测试环境跑也可以，本地写点单测。

什么鬼逻辑...合着报问题了直接本地跑一下看看执行路径不香？测试环境找不到问题的时候反复加 log 部署调试很好玩？

球球了做个人吧，是真的有人觉得线上看日志调试比本地 Debug 快吗？

PS：防杠叠保护甲，并不是那种一两个接口，逻辑究极简单的项目。不说多复杂，起码也是个正常规模复杂度的项目：

[Nazz]

我讨厌 CGO

[silencil]

本地跑不起来的项目我直接跑路，没开玩笑，去了一个 sass 公司，项目架构应该 ssm 都不算，我看了一上午的代码就不想干了，第二天就没去。

[RedisMasterNode]

@silencil +1 没开玩笑。

老项目堆很久了我能理解，以前也接过，历史上很多人经手，大家都不容易，还能有点同情分。

新项目就 1 、2 个人开发过的，交接过来本地不能跑，不知道图什么，图方便吧大概。

[jsrunner]

一样。微服务的尤其讨厌。尤其还依赖非服务之间的接口

[chenzhq2]

前端吗？可以尝试将测试环境（甚至线上环境）的请求转发到本地 dev-server ，大部分项目都可以这么处理，甚至包括微前端。
本地 Mock 容易带来跟不上迭代的脏数据，长期不更新会出现破窗效应。

[815979670]

我在对接这个接口的时候有个习惯，把对方返回的数据格式 保存一个样例到注释里，这样阅读代码排查问题会方便很多

[w4ngzhen]

个人最不喜欢的就是一个项目会有 N 多个补丁式的脚本运行后才能进行开发、构建，而且没有文档来说明这些脚本究竟的作用是什么。

[skyemin]

大厂好多都这样,本地依赖太多起不来,都是远程 debug

[Curiosity777]

@chenzhq2 请教下，这个转发如何实现，使用什么工具？

[kkbear]

大部分是项目解耦做的不好

[morenacl]

“微”服务体系里一个好的 api 网关就至关重要，请求镜像能解决很多调试的问题

[willx12123]

一般主流语言的 debug 都有远程断点能力，比如 go 的 dlv 就可以远程断点，goland 也支持接入，楼主可以研究一下。

[xiaolongorigino]

很多项目都有测试环境的 debug 工具啊，非要本地跑起来干啥。。。

[ZZ74]

我也不喜欢，但是有一种云 k8s 沙盒服务，你自己的代码写好，本地推上去，就有一整套环境了，然后你们远程调试就行 也还不错

[Martens]

试试远程调试/开发

[RedisMasterNode]

我要补充一点防杠，也是主楼没有说清楚。

这里不能本地构建可以再拓展一下，泛指没有本地调试方法的项目。远程开发，dlv ，或者任何的调试工具，只要能本地调试（不要求本地允许）都是可以的。

主楼说的不能跑，应该修改为不能本地 debug ，比如有网络隔离，不能直接访问 test 环境，导致只能通过 log 等手段反复部署调试的 ''垃圾服务''（当然也包括各种依赖问题导致无法运行的服务）

[RedisMasterNode]

不管是本地跑，还是开发机器远程跑，能调试都是好的。

不能调试是指本地不能跑，要跑就要通过 cicd 部署上隔离的环境，以及类推更多的 case ，最终无法在 ide 上调试。

谢谢楼上的远程调试的同学手下留情，不要错杀好人....

[wu67]

在上家遇到过，测试环境接口配错了没法跨域，本地根本没法配置跨域的那种，改动全盲改然后推 dev ，每次构建还要几分钟

[abigeater]

+1 不能在本地进行调测的项目 虽然还是得去做 但没有开发热情可能写一点就摸鱼再继续写

[GeruzoniAnsasu]

打 . 日 . 志 . 不 . 叫 . debug !!

[chenzhq2]

@Curiosity777 我用的 whistle ，对前端开发比较友好。

[RedisMasterNode]

@wu67 过瘾不，用户说报错了我还得回他一句，“你等一下啊，我用你的请求在测试环境加点日志跑一下看看哪里有问题”

[wu67]

@RedisMasterNode 超辣鸡的, 那时候还是新冠开始, 我们本来关在家就很郁闷了, 还要接手这破项目...后来我去另一个组了, 这个破项目就没我什么事了

[kaneg]

我们有个项目本地启动一次要近 10 多分钟，每改一行就得 10 多分钟才能看到效果，真得折磨人😩

[whileFalse]

不讨厌，但一定要有充分的理由。
现在很多上微服务的公司，搞来搞去发现最合适的是按大模块拆几个服务。微服务纯粹是浪费资源（机器和人）

[whileFalse]

这还是在本地能跑起来一个或几个微服务的情况下。如果跑都不能跑，那这个代价不小，要拿出对等重量的理由

[chenqh]

@kaneg java 吗?还是前端项目

[veightz]

@w4ngzhen +1

[sujin190]

我们能在链路追踪 Trace 记录里开启全链路请求响应体记录，这样有啥问题就很容易看出来，而且自己想用相同数据重试下也方便

[rabbbit]

所以我很好奇大型 c++ 项目都是怎么开发的，build 一下十几分钟起步，编译 chromium 能好几个小时，咋 debug ？

[RedisMasterNode]

@sujin190 如果，如果问题是某些数据转换逻辑呢？内存中的格式变换聚合，埋了 trace span 吗？

而且宽泛讲，很多问题压根不出现在对外调用中，或者反正就是出在了非 trace 埋点的地方，怎么查，是不是还得靠日志和断点调试。

总之，tracing 接入并不解决一些代码逻辑的问题，本地调试是最后兜底的手段

[NX2023]

我是真的受不了，我只能说

[shuimugan]

本地跑不起来的项目，搞不好触发一个逻辑要找好几个人。
本地能跑起来的项目，想加断点就加断点，想加 hook 就加 hook ，想复制流量就能复制，数据库甚至是虚拟机随时可以备份和还原环境，效率贼高，谁还想碰那些效率巨低的东西。

[DefoliationM]

mock 没做好，那要是微服务，更难受。

[a1b2c3T]

干过阿里私有云外包项目，简直了，去了先看了俩礼拜文档，十几套环境😵‍💫然后跑路了

[dcsuibian]

我记得有种说法：云原生=本地跑不起来

[RedisMasterNode]

@dcsuibian 人的问题，跟云原生没有半毛钱关系。所有我在 k8s 里写过的项目都能在本地运行。

[wws2023]

有好的解决办法？目前只想到搭远程开发环境

[momo24672]

我也受不了，更受不了启动 app 前去 Secret Manager 下拉 Secrets ，我更愿意把 Pull Secrets 放到打包步骤里。

[neoblackcap]

@rabbbit 大型 C++项目有各种编译优化手段，预编译，分布式编译。而且 build 一般都是初次编译比较慢而已，之后一般都是增量，不会动不动都是几十分钟。还有就是模块化设计，动态库设计好，直接只测单一模块

[RedisMasterNode]

@wws2023 这怎么都到解决办法了，没道理要解决的啊，维护能调试的程序是开发者的职责

[Adelell]

只要原代码在手里，别人能跑起来，我就能跑起来。原因无非就是依赖包的版本不对。

[jqtmviyu]

@Curiosity777 #9 重写 url 或者 host, 我是用 charles

[lstz]

挺讨厌的

如果这个公司连 CICD 都不配，那我选择跑路。 如果有配 CICD ，那就是我的问题，我服输

[dcoder]

你们抱怨归抱怨, 但是用微服务的组, 本地项目跑不起来的情况很多...

[xuanbg]

不明白为什么在测试环境能跑起来的代码本地跑不起来。哪怕是微服务也一样能本地作为一个服务实例加入到测试环境，并且让网关把请求转发到你本地。这样不就可以打上断点进行调试了吗？

说实在的，有些问题光看日志莫名其秒的，打个断点一下就清楚问题在哪里以及为什么了。

[InDom]

我们的项目，甚至发布只能以整个系统打包的方式交付（灌装）。

还是后来才整了个软件化部署，但最后还是以灌装方式发布...

[amon]

其实就是喜欢掌控和确定性，讨厌失控和不确定性。

[ecloud]

哈哈哈。本司的产品是基于 Nacos+Webflux+Pulsar+Powerjob+redis+PG 这套复杂的“微服务”。本地全起来能让你机器爆炸。起一部分的话只能用假数据扔 Pulsar 。之前 dev 环境的 Nacos 总被私服注册，研发团队内部经常互骂。最近单开了一个给大家随便玩的 Nacos ，终于算是和谐了一丢丢

[ecloud]

@xuanbg 技术上没毛病，流程上不允许。比如我们用 Nacos 调度微服务的。QA 环境的 Nacos 开放注册的话，你随便开个私服就把别人的给顶了，到时候一个请求就被均分到两个服务上了。虽然理论上所，开私服的人应该先把原有服务停掉，干完了自己的活再把私服注销，原服务恢复。但是，你怎么能保证每个人都做到。张三刚开了私服挂上去，因为个什么紧急的事情被叫去开会了。李四在调试他自己的服务的时候发现发出去的请求都消失了，找谁说理去？

[ecloud]

@willx12123 比如 java 来说，openjdk 默认没有远程 debug 的 agent ，然后 rancher 的健康检查会因为你断点了就自动重启容器。那么，你搞一个远程调试的容器，其配置就要特化。那么这个特化的容器跟生产环境就不一样了，到时候出了啥问题又要扯皮。测试说我反正在这个容器里测试是正常的，研发说我代码肯定没错，运维说原则上这点容器的差别不影响你程序……

[Curtion]

本地运行不了一般都是缺少运行时环境，尝试看能不能本地部署或者 hook 一下

[pocarisweat]

12 factor app 是不是已经没人当回事了？

1. 基准代码
一份基准代码，多份部署
2. 依赖
显式声明依赖关系
3. 配置
在环境中存储配置
4. 后端服务
把后端服务当作附加资源
5. 构建，发布，运行
严格分离构建和运行
6. 进程
以一个或多个无状态进程运行应用
7. 端口绑定
通过端口绑定提供服务
8. 并发
通过进程模型进行扩展
9. 易处理
快速启动和优雅终止可最大化健壮性
10. 开发环境与线上环境等价
尽可能的保持开发，预发布，线上环境相同
11. 日志
把日志当作事件流
12. 管理进程
后台管理任务当作一次性进程运行

[Shanee]

如果是因为 web hooks 跑不起来的话, 可以用 ngrock

[lisongeee]

相比之下前端在这方面就好多了，甚至都不用下载到本地打开

大多数组件库文档现在都支持在浏览器实时修改并预览代码

甚至还能在浏览器运行 nodejs 程序实时执行项目打包

[11232as]

本地改代码，上传 git ，上堡垒机编译机编译，上堡垒机开发 Server 热更新，然后测试，然后发现有问题...
开远程 Debug 需要走权限因为开发 Server 被丢到生产网段去了，打 Log 也痛苦，整个流程搞下来 10 分钟起步...

[BlackSiao]

确实，这种搞起来超级难受

[securityCoding]

习惯了

[xwwsxp]

@11232as 你们自己搭建一套 devops 啊 ；不然，效率太慢了

[CynicalRose]

Java 的微服务项目，几十个微服务环境关联，根本没法本地调试，必须要部署到 dev 或者 test 环境。已经将就好几个月麻木了😫

[cbdyzj]

@Curiosity777 我之前写的一个转发小扩展
https://github.com/alchemy-works/url-shift

[kaneg]

@chenqh 是 Java 项目。

[matrix1010]

我甚至连本地 docker 都不愿意启，数据库直接 sqlite 。这种时候就体现了 orm 的好处，本地和测试用 sqlite ，线上用 pg 直接无缝衔接

[xiaokongwu]

大点的公司都这样，还有各种跨 BGBU 的接口，本地调简直做梦

[xylxAdai]

@rabbbit 我之前就做 chromium 内核的，每次编译几分钟十多分钟不等吧，麻烦的就是调试真的很难，debug 完全靠打 log 或者手动改对应符号表。因为实在太大了。带符号表的 so 几百 M

[dayeye2006199]

没法子，我是做分布式机器学习的，有些问题只有几百张卡一起跑，还不一定复现的出来，写东西就是连猜带蒙，单元测试只能管住及小范围的功能。
最差的情况，写一点东西，十来分钟的构建时间，然后塞去集群跑任务，几十分钟至几个小时的排队时间，几个小时至几天的运行时间，才能知道你修复的 bug ，构建的功能是否是对的。然后重复这个过程

[justdoit123]

我感觉这是不能一概而论的。情况不同，处理方式不同。

复杂的业务系统，有时候你本地跑起来也没用，即便是单体架构。因为你本地未必有数据。如果每次写一个业务功能，都要写对应的单元测试、mock 这个业务各种场景的数据，那开发进度会大受影响。随着业务发展，可能还要写各种数据迁移。 如果这个业务是重要的（比如，飞机航班）、商业价值高的。那这样做没问题，也应该这样做。但是如果只是前景都不明朗，就投入一两人力的探索性系统，这些都不重要。提早把过多精力，放在这些方面有点浪费了。

我理解 OP 的感觉。我也很讨厌这种无法启动的项目。我觉得我们能做的事大概就是，在接手项目时候，所需要的适应时间成本一定要计算进去。这其实是切换上下文带来的时间成本，别说是接受别人的项目。回头维护自己过去写的项目，你可能都需要有不小的上下文切换开销。时间充裕了，至少不会因为时间问题加剧这种情绪。

[totoro52]

@silencil 你说的事我遇到过， 我当天就跑路了， 也是做 saas ，那个项目说大不大，可文档都没有，最后鼓动了很久打了各种支持库终于跑起来了， 我也跑了