@JiuchangErguotou 第一份工作在大环境不好的时候，能找到什么就做什么，我建议你准备 2 份简历一起投，投哪家公司的时候搜下信息做一点针对性的改动和预习

几年前觉得 c#真的很式微，当时很想转行

但是现在真的还好了，你在这里问属于小马过河，很多人的印象还停留在以前。

现在 c#进可以去游戏卷 u3d ，退可以去外企相对养老。

况且毕业生第一份工作以语言架构上乘的 c#起也是很好理解很好深入的，转行也不会太困难。

我感觉你根本没有弄清楚瓶颈在哪，就想着重构。重构不是万能药，你如果对目前的困境没有认知，甚至不知道怎么解决当前的问题，重构是必然失败的。
个人建议
1. 找清楚当前时不时崩溃的原因，通过各种方式得出一个在当前局面增强稳定性的方案
2. 评估重构的代价，重中之重是从当前如何平滑过渡到重构的方案
3. 评估重构成功之后的优势，从业务角度和运维角度，评估 1 和 3 ，最终得出方向性结论

@zackwan95 你的理解能力真的有问题，建议你反思一下

@zackwan95
好笑，日本人根本分不清 /l/和 /r/，很多人也发不出 /θ/的音，印度人也是 LR 不分，/s/和 /z/更是极度混淆，sorry 这种词印度人和日本人读成 soli 太正常不过了，不过根本没人纠结这种事，又不是没有上下文。

所以我的观点很简单，自己纠正语法很正常，但是意识不到非母语系的客观局限，把它当成“悲剧”还在深度反思，那才是真的妄自菲薄的悲剧。

你把这个事情当做悲剧那才是真的悲剧

—外企老 B 留

重技术轻业务是小年轻的通病，业务技术是息息相关的

说实话真的蛮好笑的，一堆人对着被制裁供应链的伤筋动骨的菊厂员工大谈世界范围内的自由竞争，哈哈哈哈。
颇有古人何不食肉糜那味道了。

这概念其实不新了，没必要喷

据我所知微软应该用了很久了，他们的 SAAS 提供内嵌 react 组件的功能

github 的 repo 像 996.icu 那样的自救呢？动起来啊！怎么这么重的铁拳砸下来直接哑巴了？

按我理解，这个问题无论从哪方面解决都比用纯技术解决成本要低，所以就不用技术去解决了，就这么简单。

同样的接口返回不同的数据结构就得这么做，这样的设计不是很常见吗

说实话很多人喷过早焦虑

但是我现在 31 ，我发现没有在 20 多出头那会进行积累的人，到了 30 多基本没起色，也没有动力和能力去改变自己了

我还是比较庆幸几年前焦虑的工作，焦虑的提升自己过了

啥几把玩意总监？

没想到框架中包含了快 2000 张表，数百万的历史代码。

这你还能没想到？这不该立项的时候就得整清楚？最核心的要做的地方你都不知道大概怎么做，这项目就能定时间开始？

看完了我可以说项目失败这总监基本全锅

另外更不用说有可能是三方甚至多方参与的讨论了，每人复制一遍问题再写自己答案你会疯的

相反，大家按顺序编辑正文，可以把所有回复列在问题下面，一目了然

编辑邮件来进行 Q&A 回答是非常常见的邮件办公模式

考虑你说的情况，实际的邮件 loop 会是：

userB: 请看补充标注
userA: 请看补充问题
userB: 请看标注
userA: 请回答问题?
Q1: XXX
A1: YYY
Q2: ZZZ
A2: CCC
Q3: VVV

如果基于这种模式，大家只要找到这一个块就能迅速得到讨论过程和最终结论，而如果按你的想法，通过正文不断回复
那实际上邮件的 loop 会变成这样：

userB： 补充回答
Q1
A1
Q2
A2
Q3
A3

userA：补充问题？
Q1
A1
Q2
A2
Q3
userB: 回答
Q1
A1
Q2
A2
userA：问题？
Q1
Q2


整个邮件的可读性才会变得极差，容易误读，也难以追溯讨论过程。

type 的虚拟节点下的真实数据，也需要按父子关系把树构建出来，并且当前节点在树上到根节点也连带出来（向上时，如果节点数据不属于此 type ，也需要展示，此时加一个 readonly 标记）

==> 没太明白，如果节点 type 不属于这个 type 也要展示而不是裁剪，那岂不是 type 的树就和原始树一样吗？

B 既然依赖 A 的结果，那你定义 useFetchB 的时候给个入参就行了，这样所有用到 fetchB 的地方就必须传入 A 的结果

如果 A 的查询和每个页面内容无关，那直接把 A 写到 useFetchB 里面去