superhot

@luojiedev 我也觉得对于大部分码农来说，架构这条路不太容易走通。

一个是需要扎实的专业基础，对系统有全面的理解与判断力；一个是需要合适的成长路线，只有跟着一个项目从零到 N ，随着业务场景的增长，亲身经历架构的演进，并且从中踩坑，才能具有架构能力。

缺乏真实场景，就无从分析并演进现有架构，而没有实战经验，只以宽泛的架构一词作为方向来“学习”，一切都是纸上谈兵，那这点 AI 已经做得比人好多了。

@frlee 很相似的情形，我主要参考 Spec-Driven Development ；拿到一个任务，无论什么时候都让它先做深入调查，整理成三份文档：架构概述 + 现状与目标分析 + 开发规范；文档没到位之前绝不开工编码实现。目前体感是模型足够聪明 + 适当的 harness ，祖传屎山也没那么难铲了，合适的方法论和好用的工具缺一不可。

突然想起来另一点，如果 barrel modules 影响性能的理由是无法有效 tree shaking ，那 namespace import 也同样有这个缺点…？

性能和循环依赖确实是个大问题，但个人倒是觉得通过 barrel modules 封装起一个模块的内部实现细节，使用起来很简洁，比方说一个模块重构调整路径，但对外接口保持不变，用了 barrel modules 的话，对使用者是零影响的，显式使用路径则需要更改所有导入的地方。

推荐看看周志明老师的《凤凰架构》，你的疑惑在里面有解释：
https://icyfenix.cn/

@GiantHard 我个人理解是，只要 AI 无法消除幻觉，做到 100% 准确，就始终需要使用者具备判断 AI 是否准确的能力，而非照单全收。在这个例子里面，能断定 AI 可以解释清楚的前提是，你能完全理解以上提及的知识点。否则 AI 自圆其说，也许会把你说服，但却是在扯谎，那就非常糟糕了。

> 我的一个感受是，现在 LLM 的知识广度已经远远超过人类了，考察一个人是否了解一项技术细节意义确实没以前那么重要。

说实话，确实如此，但还是会有所顾虑，无法做到完全信任。另一方面，在 AI 的知识深度与广度都远超人类的今天，我们这些技术人员应该把精力放在哪里呢？有些迷茫。

@songray 看大家的说法，似乎现在没必要再去了解 EventEmitter 了？

@Zhuzhuchenyan 太可怕了……

@lqm
@tearnarry 只要 AI 不能做到 100% 准确，就需要最终由人来把关，前提是你真的有能力做到这点。

@wuxilaoshiren 确实没必要纠结八股，但基础还是要有的。

@ssssiiiirren 顺序也许好推，但解释原理呢？

@chenluo0429 也许有更好的方式考察这些基础，想问一下都有哪些“会引发典型的回调/异步等时序难以确定的场景”

@Ketteiron 为什么呢？我的理解是 Node 中的很多类都基于 EventEmitter ，比如 Stream ，所以是很有必要去了解的。

@woodytang 受教了，“用事件做控制流是反模式 是 anti pattern ，会把代码搞得很乱，不可追溯，一般采用 回调 来响应事件，更符合函数式编程”，可以再深入解释一下这段话吗？回调响应事件，不就是 emitter.on 吗？

@SuperDaniel313 原来如此 之前没刷新出来 #4 的回复 受教了