 |
superhotTTO: Tech Topics Only V2EX 第 702982 号会员，加入于 2024-07-28 17:49:59 +08:00今日活跃度排名 83 |
superhot 最近回复了
4 天前 回复了 Ketteiron 创建的主题 › 程序员 › 发现一个自动优化 js/ts 桶文件的工具 |
突然想起来另一点，如果 barrel modules 影响性能的理由是无法有效 tree shaking ，那 namespace import 也同样有这个缺点…？
4 天前 回复了 Ketteiron 创建的主题 › 程序员 › 发现一个自动优化 js/ts 桶文件的工具 |
性能和循环依赖确实是个大问题，但个人倒是觉得通过 barrel modules 封装起一个模块的内部实现细节，使用起来很简洁，比方说一个模块重构调整路径，但对外接口保持不变，用了 barrel modules 的话，对使用者是零影响的，显式使用路径则需要更改所有导入的地方。
12 天前 回复了 Kinnikuman 创建的主题 › 程序员 › 关于微服务架构想请教下 |
推荐看看周志明老师的《凤凰架构》，你的疑惑在里面有解释：
https://icyfenix.cn/
https://icyfenix.cn/
15 天前 回复了 superhot 创建的主题 › JavaScript › 分享一道 Node.js 的面试题，考察 JS 相关的最基本的掌握程度，代码完全来自官方文档 |
@GiantHard 我个人理解是，只要 AI 无法消除幻觉，做到 100% 准确，就始终需要使用者具备判断 AI 是否准确的能力，而非照单全收。在这个例子里面，能断定 AI 可以解释清楚的前提是，你能完全理解以上提及的知识点。否则 AI 自圆其说，也许会把你说服，但却是在扯谎，那就非常糟糕了。
> 我的一个感受是，现在 LLM 的知识广度已经远远超过人类了，考察一个人是否了解一项技术细节意义确实没以前那么重要。
说实话，确实如此，但还是会有所顾虑，无法做到完全信任。另一方面，在 AI 的知识深度与广度都远超人类的今天，我们这些技术人员应该把精力放在哪里呢？有些迷茫。
> 我的一个感受是，现在 LLM 的知识广度已经远远超过人类了，考察一个人是否了解一项技术细节意义确实没以前那么重要。
说实话，确实如此，但还是会有所顾虑，无法做到完全信任。另一方面，在 AI 的知识深度与广度都远超人类的今天，我们这些技术人员应该把精力放在哪里呢？有些迷茫。
15 天前 回复了 superhot 创建的主题 › JavaScript › 分享一道 Node.js 的面试题，考察 JS 相关的最基本的掌握程度，代码完全来自官方文档 |
@songray 看大家的说法，似乎现在没必要再去了解 EventEmitter 了？
15 天前 回复了 superhot 创建的主题 › JavaScript › 分享一道 Node.js 的面试题，考察 JS 相关的最基本的掌握程度，代码完全来自官方文档 |
@Zhuzhuchenyan 太可怕了……
@lqm
@tearnarry 只要 AI 不能做到 100% 准确，就需要最终由人来把关，前提是你真的有能力做到这点。
@wuxilaoshiren 确实没必要纠结八股，但基础还是要有的。
@ssssiiiirren 顺序也许好推，但解释原理呢？
@chenluo0429 也许有更好的方式考察这些基础，想问一下都有哪些“会引发典型的回调/异步等时序难以确定的场景”
@Ketteiron 为什么呢？我的理解是 Node 中的很多类都基于 EventEmitter ，比如 Stream ，所以是很有必要去了解的。
@woodytang 受教了，“用事件做控制流是反模式 是 anti pattern ，会把代码搞得很乱，不可追溯，一般采用 回调 来响应事件，更符合函数式编程”，可以再深入解释一下这段话吗？回调响应事件，不就是 emitter.on 吗？
@lqm
@tearnarry 只要 AI 不能做到 100% 准确，就需要最终由人来把关，前提是你真的有能力做到这点。
@wuxilaoshiren 确实没必要纠结八股，但基础还是要有的。
@ssssiiiirren 顺序也许好推，但解释原理呢？
@chenluo0429 也许有更好的方式考察这些基础，想问一下都有哪些“会引发典型的回调/异步等时序难以确定的场景”
@Ketteiron 为什么呢？我的理解是 Node 中的很多类都基于 EventEmitter ，比如 Stream ，所以是很有必要去了解的。
@woodytang 受教了，“用事件做控制流是反模式 是 anti pattern ，会把代码搞得很乱，不可追溯，一般采用 回调 来响应事件，更符合函数式编程”，可以再深入解释一下这段话吗？回调响应事件，不就是 emitter.on 吗？
26 天前 回复了 no13bus 创建的主题 › 分享发现 › 发现了个研究记忆的算法工程师，说明兴趣真的是最好的老师 |
@SuperDaniel313 原来如此 之前没刷新出来 #4 的回复 受教了
26 天前 回复了 no13bus 创建的主题 › 分享发现 › 发现了个研究记忆的算法工程师，说明兴趣真的是最好的老师 |
@SuperDaniel313 愿闻其详
2025 年 12 月 5 日 回复了 fpure 创建的主题 › 分享发现 › 分享一个简单有效的记工作笔记的方法 |
差不多，但我是按周来组织文件夹，里面除了 md 写的工作日志之外，还会存当时任务的证明，一些临时脚本，和 IM 的对话记录，尤其是关键决策部分，以便日后查证。
TODO 和 DONE 直接用 - [x] 不需要用 CTRL 上下键挪了。
这个文件夹不会上传到 GitHub ，而是直接 Onedrive 同步，换机器无缝迁移。
TODO 和 DONE 直接用 - [x] 不需要用 CTRL 上下键挪了。
这个文件夹不会上传到 GitHub ，而是直接 Onedrive 同步，换机器无缝迁移。
2025 年 12 月 3 日 回复了 autumnshine 创建的主题 › Node.js › 关于 Node.js 中的事件循环问题。 |
这里有解释：
> This is because the ES Module being loaded is wrapped as an asynchronous operation, and thus the entire script is actually already in the promises microtask queue. So when the promise is immediately resolved, its callback is appended to the microtask queue. Node.js will attempt to clear the queue until moving to any other queue, and hence you will see it outputs bar first.
https://nodejs.org/en/learn/asynchronous-work/understanding-setimmediate
> This is because the ES Module being loaded is wrapped as an asynchronous operation, and thus the entire script is actually already in the promises microtask queue. So when the promise is immediately resolved, its callback is appended to the microtask queue. Node.js will attempt to clear the queue until moving to any other queue, and hence you will see it outputs bar first.
https://nodejs.org/en/learn/asynchronous-work/understanding-setimmediate
Select Language