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

[RedisMasterNode]

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

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

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

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

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

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

[MIUIOS]

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