@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 暂停。

@zcf0508 #7 prettify 我也用过，算是个好玩的玩具。ts 原生支持的话未来就可以继续推出更好的特性，比如自动扩展简单类型，当前还要点一下有点麻烦。

@enchilada2020 #4 next 的话可以参考一下这个项目，了解一下设计理念
https://github.com/t3-oss/create-t3-app
它使用的是 tRPC ，如果你愿意折腾，可以在学习完相关知识后切换成 honojs/elysiajs 自己手搓一个。

@SingeeKing vsc 之前也有类似的插件，但没有 typescript 原生支持的好用，特别是性能差距，我试了下展开几万行十几层的深层次嵌套类型，不会卡顿。
目前在找自定义预览框的办法，默认样式的框太小了。

@Greendays #1
>难吃的话，怎么还在一直吃？
公园边卖气球一个十块甚至二十块，怎么一直有人买？
如果能理解卖气球的行为逻辑，也就能理解为什么西贝一直有人去吃，本质上是一样的。
麦当劳卖的是两块钱的气球，西贝看上了另一个战场，他要卖十块钱的。儿童餐厅这个赛道很麻烦，培训时间久，投入成本高，直到现在也没有第二家入场，于是垄断了这一赛道的商人就敢狮子大开口。我敢说至少一半人并不是心甘情愿付钱的，我趁着话题热度也问了周边不少人，都是又贵又难吃之类的，只是没办法谁叫小孩被绑架了。

@cloudzhou #2 他这个框架亮点就是一句话"designed for AI integration"，但是对 java 生态本身没有什么意义，没有解决问题。