我看代码都是记笔记的，而且是手写书面笔记（可能 ipad pro 记笔记也不错？）比如一个章节就是介绍某个函数或者某个类的，这个函数分成几个部分，又调用了哪几个函数，然后下钻的函数再分别记笔记……

如果理解的部分就不需要抄代码直接用自然语言描述下，不理解的部分就标注待后面回过头看，或者查资料（ gpt 、源码分析）来综合理解。

手写笔记有个好处可以翻到前面去和当前下钻的函数和新理解的代码做对照，可能之前不理解的部分看到后面结合一下一下子就理解了。

看完一个部分后可能会找网上的源码分析进行对照，看看自己还有没有什么疏漏的地方。

不记笔记的话还有种办法就是写博客，自己从头介绍一个功能、一个模块的源码分析，这样实际写博客要讲给别人的时候就会知道哪些概念自己还不明白。

当然这些都算是笨办法，效率不是很高，但从结果上来说是让我可以理解、看得进去代码的，而且这也是个热身的过程，随着对于代码理解得越深，很多笔记就会越简略。

不光是运维成本，微服务间调用本身也是开销（还要引入分布式追踪来保障可观测性），且如果拆分服务粒度有问题还会引入分布式事务等可能本不必要的复杂度。

IT 圈一直会一阵一阵过热地吹捧某个技术，但很多场景只有最合适的，没有最好的。

感觉这是目前 copilot 类应用的普遍问题：codebase 的上下文限制。
不过不知道是不是我们这边的错觉，感觉 github copilot 使用下来准确率下降了很多，而 cursor 在写小项目时还是挺理想的。

fastcache 的方案是 mmap 自己申请管理 kv 的内存，也绕过了 gc 。

但是它的 hash -> idx （ bucket.m ） 索引本质是个 int->int 值类型的 map ，如果特别关注 gc 的话可能还是有一点优化的空间。

重要的是对应岗位经验对口，现在的行情是八股全对但业务履历对不上的话一般也很难要。

@cloudfly 我也不大习惯类似很多 Java/C# 项目这样的复杂的抽象，也可能是自己脑子不好不大擅长设计这些 hhh
包括 Kubernetes 源码也有点这味，相比于阅读 VM 以及 Go runtime 的代码，会很不适应。

像 mmap ，作者在 18 年时候就提过 Golang 使用 mmap 的问题： https://valyala.medium.com/mmap-in-go-considered-harmful-d92a25cb161d
但我最近看源码发现其实现在 VM 还是会用到一点 mmap 的，并在注释中说明在实际生产环境中这么写还是 ok 的：
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/025eec2cb00381b5292d34601f96d7fcf7503191/lib/fs/reader_at.go#L81
具体情况如何后面我想写点 benchmark 梳理看下。

@cloudfly 是这样，老毛子做东西抛去了很多繁文缛节，同时没有过多封装和抽象，读的时候感觉应跳出一些思维定式和权威崇拜的桎梏，很多主流的方案未必没有优化的空间。

以及 VM 作者让我感觉 Go 的上限其实不低，即便不用 C++/Rust 也还是可以通过 Go 写出性能满足生产要求的代码（当然前提还是对于计算机系统、网络等有足够深刻的理解）

我应该会把 VM 系统性读完后去把记录的一些优化技巧和调参梳理下，自己写 benchmark 多进行验证（比如频繁使用 sync.Pool 以及序列化时将数据梳理在一个大 []byte 里带来的局部性…），然后再去看看 fasthttp 的部分……当然，更进一步来说，通过这种阅读也更进一步认知到自己对于系统、网络理解上的不足，后续还是要继续钻下去。

点赞，近期刚好在看 VictoriaMetrics 的源码，感觉受益匪浅，很多性能优化技巧可能自己也需要做些 benchmark 再思考验证。

翻译工作如果有需要的话我可以帮忙做一些。

笑了，我就是余姚人

B 站随便搜个作业用，如果有特别中意的可能会无脑循环，前段时间听黄宣还有陶喆的比较多

shake shack ，出差去虹桥机场会去吃。第一次吃的感觉挺惊艳的，多吃几次就有点腻了

还有人在用 Angular 吗 hhhh
一般前端的话正经开发应用我会用 Angular ，如果写点轻量的小东西会用 Vue ，毕竟上手快。

@hongyexiaoqing 其实我自己也不是那么坚定自己的想法（笑），不过什么事确实都要天赋和毅力的，可能还是要看自己适合什么，以及当下这个大环境下的投入回报比吧。

目前对于技术还是有相当的热情，可能也是过去些年在工作业务的事情上投入太多，现在想找补回来吧。

当下的环境不管是 OP 哪个选择，未来如何都不是显而易见的坦途，总要想办法熬过去。祝愿 OP 的努力与坚持都有所回报。

巧了本来我也打算之后去参与 Karmada 的社区，因为觉得目前 kubernetes cluster federation 确实还是个在发展的方向，毕竟 k8s 单集群管理有明确的上限，而 k8s 官方那边已经把具体的实现交给类似 karmada 这样的社区了，自己只管 API 。而 Karmada 社区不知道实际参与起来如何。

在这之前打算先把 kubernetes 的源码过一遍，不过感觉 kubernetes 的代码风格更接近 java/c# ，关乎 golang 技巧性注重性能的玩法相对较少，读起来没那么爽。也不知道在这些组件上去做类似 clickhouse & victoria metrics 那种偏极致的优化能不能带来一些价值。

不过这样的大环境导致不少有经验的工程师流入市场，不知道会不会倒逼工程师去更加精益自己的技术，去掌握一些可替代性不高的技能。毕竟熟悉 go runtime / go 标准库的人已经不稀奇，熟悉知名开源项目源码的人也不稀奇，但能写出好轮子的工程师放眼全球相对还是少数……而技术变强本身也会扩展变现的思路，可能这也是一个路径？

总之我这边这段时间思考之后会去做这方面的尝试，主要还是觉得自己太菜了，人生很短，看看自己剩下有限的精力时间能不能磨炼出进一步的技艺，然后带来更大的价值吧。