xiaotianhu

@Ma4cus #7 讨论找工作和经济大环境啊，又不是来宣传产品的

「当下很火」就注定这玩意不太是独立开发能搞得定的

大家都知道火，竞争嘎嘎激烈啊 烈火烹油很容易把你烤熟了~

独立开发的壁垒是「信息差」，利基市场...

感觉编程之美上有一道类似的题啊。控制 CPU 使用率，只不过没法自动调节

自己能搞得定的，就不太乐意付费。
选择比较多的，就不太乐意付费。
除非能好很多倍，比如有人说到的 cursor ，想想付出与收益的成本，普通人做不来这种东西的。

隔行如隔山，在消费层面也是这种心态。

比如程序员不太会设计，为了设计我就很容易付费。Canvas 一个月 30 块钱，一大堆模板给你选，很方便的做个设计，套个样机，生成个小红书封面，这钱值得 因为让我学下 PS 不如杀了我喂猪。

但是 Cursor ，我用 Trae 也差不多，而且我主力是 Vim ，免费选择太多了，不买。

上班从来都是自带显示器的

前一阵 100 块钱收了一个 dell U2412 ，那个效果 丝般顺滑，润的不行了。看一天毫无压力

家里还有一个 dell 2209 ，CCFL 的 传家宝了，真怕他坏了。所以收了一个 2412 ，不比 ccfl 的差。写代码太舒适了

弄了个 15pro 准备换 TC 的 LCD ，现在国产 LCD 好像很完善了。值得试试。

我假设 lz 是开发，问的是代码项目而不是其他。
这个问题想问的，我觉得主要还是代码类项目的复杂度问题怎么衡量。代码量大就复杂吗，如果都是差不多的逻辑，一大堆的增删改查，应该算不上「复杂」。
我记得是有一些指标来衡量代码复杂度的，例如说圈复杂度（独立现行路径条数），需要判断的分支越多，就越复杂。
依赖也会带来复杂度，虽然我们希望好的设计能尽量解耦减少依赖（也是为了降低复杂度），但依赖终归不可避免。你不 include 文件改调用接口了，依赖只是换了一种形式而已。

原来我做了很多增删改查的项目，虽然随着业务的变化，很多数据看起来是需要经过一圈计算才能拿到，但核心也还是增删改查，感觉不算「复杂」。产品把业务规则说明白了，我翻译成代码就行了。

后来在去大厂搞了一些项目，比如说 API 网关的流控计费这种；几乎是不需要跟数据库打交道的，一年没写 SQL ；数据的持久化用 levelDB+raft 搭的分布式存储；一个请求，接收后，要经过七八个模块，有同步的处理有异步的处理，体感上「复杂度」就上升很多。

就是你接手的时候，梳理模块链路的文档就要写 1w 字+几张流程图；
随着业务的增长，主流程之外的补丁式的分支流程，就是各种特例和意外非常多；
整个流程很难在短时间记在脑子里从头到尾说明白；
细节部分经常忘了是怎么回事需要去回看；
出了问题很难快速定位到是哪儿的问题，不知道怎么在一天几百 G 的日志里找你要的关键词；

在这样的系统上工作，大概就是一种处理「复杂问题」的感觉，不管什么需求，都很可能牵一发动全身，所以你不得不非常谨慎反复求证，跟负责人反复探讨确认 edge case ，做完之后反复测试，上线之后一天里提心吊胆，就是复杂需求了。

我一直用 Vim 开发 swift 啊，很好用。只有在执行的时候点一下 xcode 里的开始，偶尔 debug 也用 xcode ，问题就解决了...