@michael2016 #33
>把你的客户数据、商品信息都爬走了
这咋了，防又防不住。能做的工作也就：
前端混淆+接口加解密，难度 3 ，拦下 90%
风控系统，难度 5 ，拦下 99%
指纹验证 + 特征判断，难度 7 ，拦下 99.9%
人机验证，难度 9 ，拦下 99.99%
但是不管怎么做都不是 100%，京东淘宝美团这些应用再怎么加固能拦下逆向扣 so 解密吗，接口数据不照样被各种倒手。
以数据为核心的业务，创立之初就要设想数据被全部爬走的最坏打算，如果无法承受，那么就不该立项。

@ovtfkw 谷歌中文搜索经常能看到 v2 ，特别是技术性话题，权重很高，这个帖子被谷歌爬虫收录后，AI 调用 tool 用中文搜索第一个结果一般就是 v2 相关帖子

你的浏览器没有收藏夹吗，放一个专门放 issue 的就行。之前也折腾过，因为 github 的订阅只能看回复，没有一个列表直观查看，后面整了半天还是回归浏览器收藏夹了。不要啥都依赖插件，我还遇到过 chrome 升级把我一个插件的数据给清空了，找不回来。
回复点击 copy link 可以定位到回复，收藏这个链接就行

太离谱了，所以应该是真的
80 后都 40 几岁了，我想象不出我 40 多岁还能在这个岗位上干活吗

1. docker 部署数据库服务有 I/O 和网络的额外开销，虽然绝大部分场景完全可以忽略，并且可以通过某些手段缓解。能问出这种问题，说明他曾听说早期 docker 实践的一些问题，现在还问可能是被 the world 暂停了五年。
2. 花钱
3. 国外上 cf ，可以防住大部分脚本小子；接口加解密给脚本小子增加难度；接口被爬了就爬了，互联网环境本来就是不可信环境，如果担心爬虫问题就别放到公网，先问问自己是不是接口太过弱智了。
4. 新一代的八股文，RAG 依赖知识库，Agent 依赖工作流

@exploreexe #145 在 chatgpt 诞生的那一年起，计算机就不是个好选择了。市场到今天还没把大量的培训班选手消化掉，新加入的毕业生我估计一半人无法应聘软件岗位，而其他行业也不太好过，特别是设计、修图、视频剪辑等等，难兄难弟。

不太愿意，收集用户数据不关心。
真的要用，同步服务必须是开源的，必须足够安全与可靠。

这些大厂项目的 issue 比故事会还好看
https://github.com/ali-sdk/ali-oss/issues/607
https://github.com/ali-sdk/ali-oss/issues/773

掘金 AI 生成的文章越来越多了，卖课和推广也多。观众用脚投票，新帖子基本都是 0 回复，尽管还是有少数认真写文的人。

核心思想不都写在 readme 上了吗，作者基本都会详细讲解为什么要这样设计，人品好的还会详细指出当前设计的缺点，如何自行改造，而不是吹嘘本框架宇宙无敌没有缺点。
脚手架就是一份“自以为是”的配置合集，你说“黑盒”，是因为你不想大致浏览一遍源码，核心代码一般也就数千行，几百行的也有。
你也不用管什么选型，哪个 star 多，技术选型吸引你，直接用就是了。
有想法的最终会自己设计一套自己使用的脚手架，别人的终究是别人的。

20 刀也不是不能用，就是慢速比较烦人，就我个人体验和 200 刀的差距不算大，而且我才用了一半不到额度，感觉亏大了。

我也对代码有洁癖，所以离职找了家小公司自己当老大，虽然比待遇不如上家，但是编程体验好了很多，再也不用看见一堆 as any 了。

>内部代码混乱成这样，真能把产品做好吗？
任何产品的初期，代码质量的影响可以说微乎其微，只有到了中后期各种问题才会暴露出来，赚快钱的都是捞一波就跑。
当一个产品赚到钱了代码质量依然如此，那就说明到了该走人的时候了，它的生命周期已到了 destroy 阶段，网速延迟有点高的老板可能还以为自己要起飞了。

打工人对此并没有什么好的办法，世界是由草台班子组成的，只能坚持自己的坚持。

最重要的是，lint 一定要持续升级，如果以任何理由拒绝 lint 的升级，那项目引入 lint 没有任何意义。
lint 升级会强迫维护者重构自己代码，会暴露出隐藏起来的运行时隐患，升级 lint 不会破坏代码行为，只会破坏流水线，流水线不是用来看的，连 lint 都不升级那可能对代码行为产生破坏的依赖就更不会升级，那整个流水线也没多大意义，费心搞基础建设，结果不强制推动迭代，那一开始就别搞，一地鸡毛。

去搞跨语言 monorepo 的懒得评论，属于没事找事，我就默认是 typescript monorepo

packages/eslint-config packages/prettier-config
这是错误做法，在新版本 eslint 中，一个 monorepo 应当只有一个 eslint.config 和一个 prettier.config ，它们覆盖所有要 lint 的文件，新版本扁平化配置文件能精细地针对不同文件，不同包，不同场景进行定制配置，旧版本这种到处塞屎的做法已经过时了，共享配置用得好那很好，但是多数人用不好，写得一坨狗屎，应该让最有经验的那人认真写一份集中配置，然后慢慢改进。
所有配置遵循最小化原则，像 prettier 就没几条是需要配置的，默认配置已经很好了。
尽量使用适合团队的 recommended 规则，然后在此之上进行小幅改动，能不改就最好不改。
如果团队个个都是体操大师，请选择 strictTypeChecked+stylisticTypeChecked ，如果只想凑合过过日子，那就降级成 recommendedTypeChecked ，觉得 lint 太花时间就换 strict ，断言选手太多了 recommended 也不是不行。
每个热门项目一般都有积极维护的 eslin 推荐配置，真正要自己配置的规则，其实最多也就几十条，再多那一定是因为各种历史原因堆积下来，维护者没时间去看默认配置的变更，很多开源项目就是这样，推动 lint 迭代比写代码还难，主要是性价比太低。
同上所述，tailwind/unocss 等等东西的配置文件也应该只有一份，一定需要分开的只有 packag.json 、tsconfig.json

权限管理？代码是世上最不值钱的东西，不会以为自己写出来的东西很宝贵吧？值钱的只有能赚钱的业务，这玩意是 copy 不了的。

Monorepo 不是大坑，屎山才是大坑。

@sir283 我可以明确告诉你，现在还活跃打招呼的公司不少都是不想招人的，都是用自动打招呼功能。为什么不想招人还开放职位？因为人事部门有硬性 KPI ，即使这个岗位实际上不招人也得定时收集数据。boss 上的活人基本只剩外包了，我曾经问过在当中介 hr 的朋友，现在的情况是外包的简历也被塞满了，他们会优先选择曾经合作过的牛马，压一压工资和福利再推给要人的公司，只有等手上优质牛马消耗光了才会去 boss 再挑一批。现在中介压工资都是往死里压，因为不这样他们自己也会失业，很明显你的报价不符合他们的最低标准。

@buffzty #9 还不想切换到 biome ，lint 的性能目前对我来说并不重要，如果哪一天 biome 支持了 strictTypeChecked 、stylisticTypeChecked ，我会考虑迁移，目前还没有太大的吸引力，eslint 再慢又不会让 tsserver 暂停。