之前一直用的 https://github.com/cortesi/modd 建议参考核心需求：
pattern match 修改什么文件重启
多个进程一组管理（常见：前端+后端+反代）
配置导出文本格式 /导入

之前命令行的痛点主要是输出日志混在一起，然后就是只能整组启停不能临时 disable 导致经常不必要地重启 webpack

1.每次执行命令前把命令本身记录到一个 history 文件
2.cat abc history | sort | uniq -c | sort -n2k 后（按次数排序）再喂给 fzf
3. 得到的结果也会后面多个次数自己处理掉

并没有什么环，mac+android 接近十年了，在我看来苹果手机根本不值它的价格

补充第三点，因为我是笔记本开屏接一个外接屏幕+外置 trackpad 的，甚至直接双手各自用不同的 trackpad 也是可以的，一个就保持拖动状态另一个定位

1 、 “甩” 加速度是影响推动距离的。适合中距离但精度要求不高
2 、到触摸板边界了可以迅速抬起后三指再放下，拖动不会中断。适合拖到一半发现到头，或者较长距离精度又有要求
3 、三指触发拖动后，留两指保持状态，直接用另一个手的单指负责移动，适合距离超远定位要求又特别精确

https://github.com/go-proverbs/go-proverbs.github.io/issues/37
rob pike 并不 100%赞同这句话并拒绝将其加入 golang proverbs

截图时的 touchbar 交互是我印象深刻的少数几个我觉得 touchbar 好用的地方

1 有几个其他相关功能，一个是 bookmark，另一个是 navigate to last edit，尤其是后者，我自己的情况看了一圈想回去的时候大概率是要回之前修改的位置
2 在有请求数据的断点处走条件断点（右键红点配置 condition

别问，问就是共同责任

产品或研发甚至测试任意一边靠谱就不会出这种问题，反过来，出现这个问题说明链路上所有人都有待改进

Windows 的话小红点，Mac 的话 trackpad 都比鼠标割裂感小很多

因为 go 的风格是把接口放在调用侧而非实现侧的，所以多数情况接口和实现是在不同 package 中，可以直接用相同的名字

多个方法如果紧密相关可以放一起，起一个整体名字，如果并没有太大相关，可以分开多个接口，go proverb 如是说：

“The bigger the interface, the weaker the abstraction.”

go 语言厉害就厉害在朴素
1. 方法调用实参和形参类型要求是 assignable
https://golang.org/ref/spec#:~:text=arguments%20must%20be%20single-valued%20expressions%20assignable%20to%20the%20parameter%20types%20of%20F

2. assignable 规则
https://golang.org/ref/spec#Assignability
对于两边都是 func 来说这啊那啊的都不适用，就是要求 identical

3. type identical 规则
3.1 func 要 identical 必须出入参对应位置 identical
https://golang.org/ref/spec#:~:text=corresponding%20parameter%20and%20result%20types%20are%20identical%2C

3.2 interface 和*Obj 不 identical，因为一个是 interface type 另一个是 pointer type


ref/spec 虽然有点拗口，但又短又精髓，查起来非常容易

我做过不少次关于这个话题的分享，也列过类似的提纲，但这些都是不太重要的“结论”而不是核心的“理论”

理论很简单，想明白你的这个{技术,发布,架构, anything}方案 /文档的目标读者是谁，他（们）经常关注的重点 /痛点是什么，你们作为研发要同步给他们的信息是什么，把这些信息分门别类记录下来（因为你不会准备 10 份文档给 10 个部门看），就是一份好的技术文档。

另外别忘了目标读者还有一个是同一个需求的其他开发，同一个项目下一个需求的开发，也很可能包括 2 个月后的自己

基于这个理论和各个公司、部门、系统的不同情况，好的文档并没有一个统一的结构写法

对钱追求不高家里又没有帮助凭什么要房要车，生活成本高说明你的生活水平高于你的赚钱能力了而已，总有更穷的日子过法

要么吃苦赚钱满足自己的需求，要么躺平把乱七八糟的想法也扔了，没钱就不花钱

做这种人肉 v8 题做不出来也无所谓
如果给结果要求解释讲不清楚就不行了
但基本上很多人是能够讲个大概的，没什么区分度

所以我不太喜欢面试被问到这类，也不会自己在面试中问这类问题

你认为你优秀的逻辑没一条是对的。

面试表现不是你感觉的，是以面试官为准，面试题流程顺利可能是表现不错也一样有可能是面试官认为已经摸清楚你的底了快速结束

base 高=优秀最多只是平均倾向，对个案没有参考意义，另外即使只考虑经济回报，也是看总包和包的分布方式的，base 只是公式里的一个参数

面试通过率高说明面试沟通方面技巧好，岗位投递匹配程度高，就算是有个人优秀的因素，也是“在给你的评级范围内”优秀，甚至反而说明职级低，岗位数量多能干活就行的低级别职位当然容易匹配。
有个人考虑一百个公司可能只面十家最后只有一两个 offer，这个人完全可能是个 CTO 、行业顶尖专家

hr 和你谈薪时的说法根本不重要，尤其是大厂或者薪酬体系严谨的中小公司，面试官和技术主管有一个评级以后，hr 就是拿着对应的区间和你谈的，谈判技巧最多帮你在区间里尽量不要拿偏下的位置罢了

你已经面了很多了的话，那么基本上能谈下来的 offer 就是你的实际水平了，不满意的话建议好好加强技术，别整那些有的没的歪路

@xuanbg 巨石也有正常的巨石，不讲研发质量拆服务只能得到分布式屎山，拆微服务那就是拉稀了