sampeng

抱歉。我开地图炮了。我的锅。。是我表达偏激了。
我想表达的是。不会没关系。你倒是学啊。。这很难？就像 ls 的 @darkengine 这就是顺手的事啊，不说卷不卷，满足工作需要不是最基本的职业素养吗。我讨厌的是只知道喂嘴里的。不会就不看不学不了解，张嘴就是我不会搞不了。
二进制是个很难的东西么？任意一本编程语言开头就是二进制。瞄一眼很难？？ google 一下很难？哦。。。抱歉。这些人大概率是不用 google 的。百度没有就是不会。

我生气的时候最喜欢做的事就是别人问我的问题，我原话输到 google 里然后把第一条结果扔他脸上

太正常不过。前端不学二进制。前端不会二进制。前端不会串口通信。。就因为这三个不会，我司硬是整出来一个 golang 做中间件把串口转成 websocket 。喂到嘴里。
不排除有牛人。但 99%的。。抱歉。。。看不起。

不写单元测试就是这样了，单元测试的最大价值就是保证你改一处不会买一送一。你的担心是多余的，维护单元测试时间和你延长 release 时间没区别。而且吧，现有 ai 最大的辅助地点就是秒写几百行单元测试用例，改吧改吧就能用了。单元测试后补工作量巨大，我的建议是发现一个 bug ，把这个 bug 涉及的函数进行单元测试。但是，后加单元测试有个巨坑：你的代码大概率不适合单元测试，就要重构。从目前来看，可能最合适的就是 ui 的自动化集成测试比较适合。这样一来只需要对 ui 进行黑盒测试。只需要解决数据的先后关系就行了。比对虽有函数都单元测试工作量小多了。相当于你延长发布时间用来写 ui 的单元测试。相当于给自己请了个测试工程师

看看 niz 的键盘，我是相当满意的。机械键盘腻了。静电容相当可以

你们都没试过 vscode 的 copilot 的 editor 么？在我看起来完全够用了。

自己有境外机器的话自建一个 docker 镜像库。用啥拉啥。比 cf 稳定多了…

其实现阶段的基础设施，交叉编译没啥太大含义了。可能对一些 arm ，交叉编译还是要的。但是 linux ，windows ，mac 这些常见的。。其实无所谓。github 有 action 。自己可以虚拟机。这样反而是最干净的。