以下文字是 2024 年上半年记录在其他地方的文字，担心没有备份，没有版本管理，所以挪到这里来。
病入膏肓者，须用一味猛药，如旧中国，如我，如他人，如烂代码。
不良修复体
那些曾经困扰过你的问题和焦虑，如果你不正面冲撞它，击破它，它们就会在你30岁、35岁、40岁、45岁的时候，卷土重来。并且一次比一次凶狠，而你却一次比一次无力。
我就没见过几个，真心为你好的，亲戚，朋友，同学。
你欠的债，总会在某一天，以意想不到的方式，还给你。
不要指望别人认可你的工作，认可你的能力，认可你的成果。
凶狠的眼神是为了对抗更凶狠的人。
什么都要靠自己，父母亲戚朋友都靠不住。
【永远不要寄希望在其他人身上】 别人给你多少星是不可靠的，要追求技术沉淀，项目经验。（做菜不要指望别人，自己会才是硬道理）
要点强，争口气，长点志气？
不要拖延，已经因为拖延错过太多了。
挺直腰板，挺胸抬头，心里舒服。
不要交心。
听亲人无力的抱怨，自己却无动于衷，无能。
谨防乐极生悲。
有没有过殚精竭虑，有没有过苦思冥想，有没有如数家珍，有没有吃饭睡觉都在想同一件事。
⚠️ 远离打击你、给你泼冷水的人。
[拳头] 要能吃苦。
🙅🏻♂️ 学会拒绝。
[闭嘴] 话太多。
🗡 没出息，没骨气。
🌿 反复无常。
🌿 记住 兔子不吃窝边草。
📖 及时复盘，及时总结，学到了什么知识，做了什么项目，遇到哪些问题，怎么解决的，项目有哪些难点。
⚡ 要收拾整齐，要挺胸抬头，这样效率才高。代码同理，要干净、精简，函数要短小。
🚶🏻 不要在工位久坐着，出去转转再回来，效率会更高。
👨🏻💻 一开始要设计好，否则一开始乱了，后面就没法收拾了。
🤔 要时常思考做这个有没有什么技术难点。
🏃🏻 一鼓作气。
🤔 思考离职的时候能带走什么。
👊🏻 简单的都做完了，剩下的都是难的。
🏃🏻 不要停下来，一停下来就会越来越懒。
🤔 经常反思，经常思考、对比、总结。
🤫 对工作环境的要求，安静，无人打扰。
📱 巨没出息，小富即安。
💪🏻 性格决定命运，要强的性格。
张一鸣：有时候大家的认知和事实会差很远很远，比如，2012年的时候没人看好移动互联网。
无底洞/吸血鬼/永远都在疯狂贬低你
做啥都磨叽，却还找无数个理由。
但凡靠谱点，我也不会这么憔悴。
时常记住做减法，没用的通通扔掉。
干啥啥不行，不知道我要多做多少才能追上同龄人。
教育别人前先教育好自己。
悲观者正确，乐观者前行。我既不是完全的悲观者，也不是完全的乐观者。
技术垃圾，偏偏是骨干，写的💩一样的代码，拿着你做的东西来汇报。
一天到晚搁那演啥呢？！
代码不会背叛你，运动、肌肉也不会背叛你，但是打游戏会。
你越强，却给你匹配更强的对手和更菜的队友，感觉像是遭到了背叛。
简单不等于容易，把复杂的东西做简单，不代表它就容易。
仔细观察，耐心发现，努力分析。
让人讨厌的是，把别人的付出当做理所应当。
懒得一匹，贪得无厌，笨的一匹，自以为是。
别人给你加油、呐喊，你也不可能真的变快，别人质疑你、诋毁你，你也不可能真的变慢。
组件库 demo 是有讲究的，让别人能一下子就能看到组件，比如弹窗一开始就展示，不要等着别人点。
- 不要演戏，演的没有别人好
- 该说就说，该同步的就同步，不管别人怎么回应，甚至没人回应也无所谓
干个啥都阻力重重。
- 抢功、争着抢着表现自己
- 甩锅
- 代码写的像屎
简单点？简单点。简单点！
环境可能会限制人的成长，但只是某一方面，无法限制所有，因为总有些东西是自由的 🏃🏻➡️。
总是把别人逼疯。
孩子情绪不稳定，就会难带，也不爱学习。
看看她周围的人，哪个不是被她逼得情绪不稳定的？
不尊重别人，也不会反思。被人说了，也不往心里去。周围人难受，她一点事没有，第二天还是改不了。
记孩子哭闹于深夜。
你如果深刻理解它，你就会把代码写的又简单、又直接、又没有bug、性能又好，如果你不理解它，你就会把代码写的又臭又长，bug又多，又难维护、难理解。
能力守下限，运气冲上限。
只屏蔽发广告的人，没任何营养，没任何价值。
过于温和的人是不是少了些凶狠，狼性，攻击性，血性。
有钱的人生是享受，没钱的人生是受罪。
老实人吃亏。
老实人的本质，胆小懦弱，或没能力、不自信，或是纯粹一种性格。
引导子女独立思考，婚姻大事不要过分征求父母意见，父母不插手干预。
《东京奏鸣曲》失业
制定目标，最重要的一点是跳一跳，够得着。
赛事时间轴
待开赛（去对局（去备战房准备））
进行中（可拉起游戏、分组建房中、游戏中、未出战）
已结束
时间管理的本质是精力管理，了解自身精力曲线在精力充沛的时候完成最重要的事。
一个没有技术含量卖人头的部门而且还没底线，能走多远？
赛事工具：稳定、好用、用完即走。
时刻要想着沉淀，想着走的时候能带走什么，想着最近有什么提升。
永远不要改变原始数据，比如赛程中改变 state。
新出海项目部署：
- 新建 nginx 的命名空间，新建 nginx-html-yaml 的模板集，里面建一些 manifest 的占位
camelize: ab-cd-ef=> abCdEf
hyphenate: AbCd => ab-cd
写代码有两个维度：正确性和可维护性，不要只关注正确性。
能把代码写对，是每个程序员的必备技能，但能够把代码写得更具可维护性，这是一个程序员从业余迈向职业的第一步。
中国电影不会分级，原因是分级就有了标准，就不能想限哪个就限哪个了。
开发阶段尽量多自测，交给测试人员，bug会被放大，再交给产品，又会被放大一层。
分手的人不要想，为什么之前那么亲密，突然就变得冷淡。
其实人跟人本来就是独立的个体，能够曾经在一起其实已经突破常态了。每个人都有独特的价值观、经历、想法、感情、感受。
两面三刀
某产品经理，今天还对你客客气气，明天就对你颐指气使，甚至过来投诉你。不是把你当合作伙伴，而是把你当成他的黑工，当成他完成kpi、向上邀功的工具。
专业技术奇差，一个简单的页面天天改，翻来覆去的改。没有创造性，永远是抄别人的，今天抄一点，明天抄一点。
某虚线，派活、邀功、表现自己的一把好手。能力低、技术差，只想着管理，又不是管理岗位。
打游戏，没出息。
卸掉是最简单的解决办法。
《毒液》，一个好的地球人和一个好的外星人，打败了一个坏的地球人和一个坏的外星人。
运动好处：
- 放松
- 精力充沛，思维活跃
- 增强免疫力，强壮
经验在能力之上，没有总结归纳、沉淀的能力，怎么会获取经验。
hooks 中不应该改变不属于这个 hooks 的变量，比如
function useA(operation) {
operation.value.show = false;
}这种太难追踪，不易维护。
可以封装 operation.value.show 的 set 方法，更易追踪。
- 页面（组件中）中
const closeOperation = () => {
operation.value.show = false;
}hooks中
function useA(closeOperation) {
closeOperation();
}小程序 swiper 组件抽搐，原因是 change 事件中改变了 current，陷入了循环
小程序上传图片，会触发 onHide 和 onShow 生命周期。
与其想着怎么做舔狗，不如想着怎么提升自己，更靠谱、有效、实际、快。
工作、生活都是如此。
理解比背诵更加重要，看死记硬背能背多少呢？能背多久呢？
能力守下限，运气冲上限。
程序员20%的时间处理80%的事，即简单繁琐的日常事务，80%的时间处理20%的难题。
在使用 value && <Component {...props}/> 之前确保 value 值是布尔值，以防止显示意外的值。
不好的写法: 当列表的长度为 0，则有可能显示 0。
const DataList = ({ data }) => {
return <Container>{data.length && <List data={data} />}</Container>;
};推荐写法: 当列表没有数据时，则不会渲染任何东西。
const DataList = ({ data }) => {
return <Container>{data.length > 0 && <List data={data} />}</Container>;
};朋友圈里大部分人是不希望你过得好的，所以什么也不要表露。
忙忙碌碌，勾心斗角，无非是名和利。
身体状态不好？
【男人的不可能三角】
一个男人不可能同时满足帅、有钱、感情专一这三个特点。
如果有个男人同时满足这三个条件，还喜欢上了你，很可能是爱情诈骗。
穷则思变
追涨杀跌是人的天性。
软件设计中，多想几个方案，进行对比。
羡慕说走就走的大佬。
究竟是害怕谁，记下来，想想为什么。
再也不打游戏了，真是越菜瘾越大。
就这么点东西
大厦将倾之感
田野里的村庄 高楼大厦灯光璀璨
陌生与熟悉
人在囧途
2024.2
三角洲行动的英文名是叫做“delta force”，直译过来就是三角洲部队，中文名则是采用了“三角洲行动”。
像是被吸走了灵感和创造力。
一直逃避的事情，突然发现不用做了。一时间有些恍惚。说离职也很快，说走就走。
【怂不拉几】
驼个背，弓个腰，怂不拉几，傻不拉几的。
他们技术太烂，还总想邀功。
要把核心代码抽离，他们接触的、了解的越少越好。
不要再给别人做嫁衣了。
不同人眼里的好代码是不同的，但有一点是确定的，那就是自洽。
自己定的规范自己遵守，不要出现飘红、报错，命名等全局统一。
本质是缺少尊重，所以才如此叛逆。
怂的性格，怂的形体，和成长环境密不可分。村里指指点点，长辈吆五喝六、唯唯诺诺。
如有需要，他一定会毫不犹豫的把你踩在脚下，这会是“朋友”吗？
好项目和烂项目的区别是，一个需求前者10分钟做完，后者一天做完。
布达佩斯之恋，东食西宿而已。
要想改变现状，得有权利才行。
喊着人人平等，却权贵当道的社会。他们像蝼蚁一样渺小。
眼高手低。
功夫在平时。
校招生素质
| 方面 | 素质项 | 典型行为 |
|---|---|---|
| 学习能力 | 聪明度 | 具有好奇心和领悟力，能持续学习并设法学以致用 |
| 学习能力 | 分析洞察 | 对事物有深入的看法与理解，能逻辑、系统地分析问题，考虑到未来趋势和全局 |
| 自驱力 | 成就导向 | 在工作中精力充沛，总是主动设定挑战性目标并设法达成，享受不断突破的过程 |
| 自驱力 | 责任心 | 在工作中认真负责，不推诿、不懈怠，积极高效地采取行动 |
| 擅协作 | 沟通能力 | 沟通中能悉心倾听、清晰表达，善于采取各种方法说服他人 |
| 擅协作 | 合作共赢 | 乐于与人合作，积极支持伙伴，也善于创造共赢局面、整合资源，使合作效益最大化 |
| 好心态 | 长期主义 | 看待问题时能够将眼光放得更长远，而非局限于眼前利益 |
| 好心态 | 自我认知 | 重视自我总结和反省，对着机身的优劣势和自我定位有合理认知 |
| 好心态 | 抗压能力 | 具有正能量，能乐观积极地看待环境和自己;不轻易被挫折打倒，能快速恢复 |
玩游戏是进入心流最快的方式。
组件库很重要的一个特性是稳定性，所以 module 组件库是伪组件库，因为它不具备稳定性。
- 饼图，强调比例
- 柱状图，强调数量
- 折线图，强调趋势
成长最快的方式，就是硬着头皮上，一边恐惧，一边想办法。
朋友圈，能展示给亲人、仇人、路人，上级、下级、平级看的，经过时间考验的。
主要是做了什么，而不是说了什么。
一图胜千言。所以留的只有图片，而没有文字。
不是敲打你这，就是敲打你那。不用心存妄想，让他满意。
置顶就是留痕，管别人怎么看呢，只要不暴露个人隐私就行。
一图胜千言，语言太单薄。发朋友圈不必带文字。
留痕，而不要怕出卖什么。
需要你时疯狂艾特你，电话你，不需要你时对你爱答不理。
外包，不是同事，是使用的服务，措辞为 使用外包。
找之前要求低，是因为饿一段时间了。找到之后又觉得不好看了，是因为吃饱想吃好了[狗头]。
因为赛马，领导最轻松，而且领导稳赢。
同时发生3件事，让人觉得绝望。
- 嫡系做了功能一样的东西出来邀功，领导笑嘻嘻，把你的成果当空气。
- 你转发文章到群里，同事转头取消 star。
- 你想做的事情，别人也要来抢。
这就是优秀 UI 设计的奥秘：避免多个操作入口，避免让用户做选择，所有设置尽量提供默认值。这样才不会让人迷惑，可以一路回车。
肯定有很多高级用户不赞同，提出一大堆置疑。
•为什么要放弃 Handbrake 的强大功能？ •如果有人想要不同的设置呢？ •你考虑过特殊需求和极端情况吗？
解决方法很简单，就是再做一个专业版界面，也许就是 Handbrake 现在的样子。用户想要更多功能和个性化设置，那就自行切换。
跟常规 API 不同，MCP 作为接口有一个好处。
常规 API 是对开发者的一种承诺，发布后不能轻易改变。但是，MCP 接口只供大模型调用，而大模型每次都会动态读取使用规范，因此我们能够随时更改 MCP 服务器，不会有任何问题。
数据模型不仅是程序的核心，也是新产品的核心。
他认为，数据结构决定了产品的形态，只要改变一下数据模型，往往就是一种新产品。
文章举了很多例子，非常有启发，我跟大家分享。
（1）
最初的聊天软件，都是以人为中心，两人或两人以上组成一个聊天。
它的数据模型就是围绕人建模，要是成员全部退出，聊天就结束。
后来，新的群聊软件 Slack 诞生了。
它的数据模型变了，核心不是人，而是话题。一个话题就是一个容器，所有相关的聊天都在里面，又叫做频道（channel）。
即使成员全部退出，没人聊天了，频道依然存在，话题的完整上下文也不会消失。新成员加入后，可以看到以前的所有讨论。
由于这个特点，Slack 特别受企业欢迎，是目前公司内网工作聊天软件的首选。
你看，就因为 Slack 的数据模型变了，哪怕其他都没变，它就成了一个全然不同的产品，杀出了聊天软件的重围，在企业市场大放异彩。
（2）
再看两个例子。Notion 和谷歌文档都是文档软件，都用来写文档，但是它们的数据模型不一样。
谷歌文档就是传统模型，以单篇文档为中心。
Notion 模型的核心其实不是文档，而是页面。一个页面就是一个容器，你可以组合多篇文档，呈现在一起。
Figma 和 Photoshop 都是设计软件。
PhotoShop 模型的核心是图像，所有编辑都归属于某张图像。
Figma 模型的核心，我觉得，是工作区。一个设计稿就是一个工作区，里面可以有多张图像，其他人可以参与进来，留言讨论。
（3）
总之，数据模型稍作变化，就会产生一种新产品。它跟现有的产品有区别，从而能够打开新的市场。
这启发我们，如果你的产品跟别人雷同，那么不妨思考一下，能否改变数据模型。
沉浸感是我们谈到游戏、电影、表演、各种艺术形式经常提到的词。但沉浸究竟是什么呢？沉浸在现代汉语的释义为比喻“完全处于某种境界或思想活动中，全神贯注于某种事物”；美国心理学家米哈里（Csikszentmihalyi）提出了著名的心流（Flow）理论，“心流”是指当一个人全神贯注的投入到某件事情当中，专注进行某种行为表现出的心理状态，是一个人将自己全身心的精神都集中于某种活动上的感觉，会产生高度的满足感、兴奋和充实感。构成心流的主要特征有目标明确、反馈及时、所遇挑战与自身能力的平衡、控制感、精神的完全集中等。这些特性在电子游戏内均能体验到。
电子游戏就具备明确的目标，比如游戏的任务系统，排行系统等系统存在的价值都是给予玩家奋斗的目标，让玩家知道游戏中各个阶段需要干什么，并且认知到当下与目标之间的差距；玩家操控游戏内角色进行游戏内行为时，会获得即时的反馈感，在一些FPS（第一人称射击游戏）、MOBA（多人在线战术竞技游戏）中体验尤为明显，若网络延迟导致反馈慢了零点几秒，就会对结果产生影响。在电子游戏中，玩家需要具备能够通过其在游戏内遇到的挑战的能力，这种能力可能是游戏内角色数值、玩家操作水平等，当所具备的能力与挑战达到高度平衡时，玩家会获得极其强烈的游戏体验，达到完全“沉浸”的地步。控制感是指某个活动完全在自己的掌控之下进行，活动会随着自己的操作或想法的改变而改变，玩家在电子游戏中的行为也能获得控制感，其通过操作游戏内角色进行游戏内行为获取的反馈来获得控制感，反馈的及时、且反馈需要与玩家的预期保持一致，才能形成控制的感觉。玩家体验游戏时常常是全神贯注的，很多即时对战类的游戏注重的是单局体验，其就需要玩家每一秒钟的注意力都集中到游戏内需要做的事情上去。
因而，米哈里所提出的“心流”理论十分适用于电子游戏，当玩家所有的注意力都集中到当前所做的事情之上，且能够获得反馈感、控制感，使自己所有的能量在游戏内获得了释放，达到了忘我的状态，这种状态即“心流”体验，也就是电子游戏的沉浸感，这种沉浸感需要玩家与游戏的交互才能形成。这就是我要谈的电子游戏的第五点特性——交互性。
自己蠢得一批，还不自知，说这个不行，那个笨蛋，骂我女儿笨蛋。就这样的教育，自己女儿能有出息才是奇迹。
不要看数据，看内容，对抗内心看数据的冲动。
回顾我曾经写过的各种系统代码，按代码的作用，大概都可以分为如下三类：
- 功能
- 控制
- 运维
如果你想提高编程水平，写出优雅的代码，那么就必须要清晰地认识清楚这三类代码。
功能代码，是实现需求的业务逻辑代码，反映真实业务场景，包含大量领域知识。
一个程序软件系统，拥有完备的功能性代码仅是基本要求。因为业务逻辑的复杂度决定了功能性代码的复杂度，所以要把功能代码写好，最难的不是编码本身，而是搞清楚功能背后的需求并得到正确的理解。之后的编码活动，就仅是一个“翻译”工作了：把需求“翻译”为代码。
控制代码，是控制业务功能逻辑代码执行的代码，即业务逻辑的执行策略。
编程领域熟悉的各类设计模式，都是在讲关于控制代码的逻辑。而如今，很多这些常用的设计模式基本都被各类开源框架固化了进去。比如，在 Java 中，Spring 框架提供的控制反转（IoC）、依赖注入（DI）就固化了工厂模式。
通用控制型代码由各种开源框架来提供，程序员就被解放出来专注写好功能业务逻辑。而现今分布式领域流行的微服务架构，各种架构模式和最佳实践也开始出现在各类开源组件中。比如微服务架构模式下关注的控制领域，包括：通信、负载、限流、隔离、熔断、异步、并行、重试、降级。
控制代码，都是与业务功能逻辑不直接相关的，但它们和程序运行的性能、稳定性、可用性直接相关。提供一项服务，功能代码满足了服务的功能需求，而控制代码则保障了服务的稳定可靠。
有了控制和功能代码，程序系统终于能正常且稳定可靠地运行了，但难保不出现异常，这时最后一类 “运维” 型代码便要登场了。
运维代码，就是方便程序检测、诊断和运行时处理的代码。它们的存在，才让系统具备了真正工业级的可运维性。
最常见的检测诊断性代码，应该就是日志了，打日志太过简单，因此我们通常也就疏于考虑。其实即使是打日志也需要有意识的设计，评估到底应该输出多少日志，在什么位置输出日志，以及输出什么级别的日志。
检测诊断代码有一个终极目标，就是让程序系统完成运行时的自检诊断。这是完美的理想状态，却很难在现实中完全做到。
组成视图
组成视图，表达了系统由哪些子系统、服务、组件部分构成。
每一类服务提供逻辑概念上比较相关的功能，而每一个微服务又按照如下两大原则进行了更细的划分：
- 单一化：每个服务提供单一内聚的功能集。
- 正交化：任何一个功能仅由一个服务提供，无提供多个类似功能的服务。
如上，就是我们系统的服务组成视图，用于帮助团队理解整体系统的宏观组成，以及个人的具体工作内容在整个系统中的位置。
交互视图，表达了系统或服务与外部系统或服务的协作关系，也即：依赖与被依赖。
部署视图，表达系统的部署结构与环境。
部署视图，从不同的人员角色出发，关注点其实不一样，不过从应用开发和架构的角度来看，会更关注应用服务实际部署的主机环境、网络结构和其他一些环境元素依赖。下面是一张强调服务部署的机房结构、网络和依赖元素的部署图示例。
流程视图，表达系统内部实现的功能和控制逻辑流程。
可能有人喜欢用常见的流程图来表达系统设计与实现的流程，但我更偏好使用 UML 的序列图，个人感觉更清晰些。
系统只要是活跃的，“熵”值就会在生命周期中不断波动。需求的增加和改变，就是在不断增加“熵”值（系统的混乱程度）。但软件系统的“熵”有个临界值，当达到并超过临界值后，软件系统的生命也基本到头了。这时，你可能将迫不得已采取一种行动：重写或对系统做架构升级。
如果你不关注、也不管理系统的“熵”值，它最终的发展趋势就如图中的蓝线，一直升高，达到临界点，届时你就不得不付出巨大的代价来进行系统架构升级。
而实现中重构与优化的动作则是在不断进行减“熵”，作出平衡，让系统的“熵”值在安全的范围内波动。
代数是构造一系列对象和一系列操作这些对象的规则。
所以你看，代数这个概念的核心就两点，对象和操作对象的规则，这样就很好理解了吧？那有了代数的定义，线性代数就很好定义了。我们类比来看，线性代数其实就是向量，以及操作这些向量的规则。
向量，也叫欧几里得向量（Euclidean Vector），其实就是能够互相相加、被标量乘的特殊对象。而标量也叫“无向量”，它只有数值大小，没有方向。
在这个平面中，每个线性方程都表达了一条直线。由于线性方程组的唯一解必须同时满足所有的等式，所以，线性方程组的唯一解其实就是线段的相交点，无穷解就是两线重合，而无解的情况，也就是两条线平行。
- 首先，你要站在领导角度思考，具体方法是拔高层级来看问题；
- 接下来，你如果光想不做，还是空谈，所以你还要行动起来，主动帮领导排忧解难；
- 最后，你还要明确领导到底需要什么样的部下？他需要有能力、有主见而且和自己一条心的部下。
发现很多技术的内容可能都随着时间变迁过时了，但关于成长的认知却依旧历久弥新，因此选了这个关于成长的主题。
而成长的本质，就是两个字：知行——始于知，终于行。
波士顿矩阵模型，把公司业务分成下面四类：
- 现金牛业务
- 明星业务
- 问题业务
- 瘦狗业务
就个人而言，行业在发展，技术也在进化，曾经你赖以为生的 “现金牛” 技能，可能过几年后就会落后，逐渐变成了 “瘦狗”，无法果断地放弃旧技能、开发新技能，可能就如诺基亚一般在新的时代被淘汰。固守瘦狗业务，那就是：活在过去。
业务模型构成了你的蓝图，而对你的各种业务进行与时俱进地布局与取舍，这就是战略。
“高” 是往宏观走，“精” 是往微观走，“尖” 是去突破边界。
这三条路，“高” 和 “精” 的方向在业界更常见，而 “尖” 不是工业界常规的路，毕竟业界拥有类似贝尔实验室这样机构的公司太罕见，所以 “尖” 的路线更多在学术界。
高
高的两条典型路线如下：
- 程序员—架构师—技术领导者
- 程序员—技术主管—管理者
往高处走，每一次角色的转变，都是断层。有时候，公司里到了一定级别的程序员就会被冠以架构师的称呼，但工作的实质内容依然是资深程序员平时做的事，如：一些关键系统的设计和实现，解决一些困难的技术问题。
这些工作中的确有一部分也算是架构师的内容，但如果不能认识到架构师工作内容的实质，再往高处走也就很难实现断层的跨越了。而架构工作的实质是创造一个模型，来连接、匹配关于业务、技术和团队之间的关系。
其中的 “业务” 属于架构师工作内容中的领域建模；“技术” 是匹配领域模型的技术实现模型；“团队” 是关于个体之间如何组合的结构，需要满足个体技术能力与技术实现模型的匹配。由这三个元素连接和匹配构成的模型中，“业务” 是变化最频繁的，其次是 “团队”，而变化频次最低的反倒是 “技术”。
每一项元素发生变化，都意味着架构模型需要去适应这种变化，适应不了变化的模型就需要升级。而常见的组织架构调整，也就意味着 “团队” 的沟通路径变化了，因为康威定律（系统设计的通信结构和设计系统的团队组织的沟通结构是一致的）的缘故，必然带来架构模型的适应性变化调整。
懒有两种，一种是行动上的，一种是思想上的。
越垂头丧气越容易感到累，越昂首挺胸越容易感到精力旺盛。
狐朋狗友不如独处，起反作用。
协助？
周知主要是为了防止后面背锅，而不是邀功。
- 变强，变强，变强。
- 多读多看多写，专注做事。
- 永远不要将希望寄托在别人身上，他给你多少都不是你能掌控的，全看他个人的想法，还是要多沉淀自己的东西。
- 想着走的时候能带走什么。
也不是说有代码洁癖，就是代码质量太差，就没有动手改的欲望。
- 代码水平仅停留在能跑就行的阶段，代码质量差，可维护性、扩展性没有，架构设计、系统设计能力为零，创造性为零。
- 总体而言，技术跟外包差不多，执行力还比外包差。
- 把活宁愿给外包，也不愿给他。
- 所谓的优化就是东抄抄，西抄抄。改改名字而已。也只是维护一小阵子，纯纯为了展示而做。
前端工程化的目标是通过自动化、标准化和最佳实践，解放开发者的双手来提高相关事务的实现效率，同时大幅降低因频繁人工干预而导致出现问题的可能性。
既没有技术实现能力，也没有技术判断力。看到别人发长长的文字、看起来高大上的架构图，就觉得了不起了。可扩展性、灵活性、可复用性呢？抓不住本质。
产出与沉淀，虚假的产出，不是沉淀。纯纯为了汇报和应付用的。
太多console其实会影响代码的可读性。
代码写的像屎一样，连及早返回都不知道。
不懂项目框架，不懂技术原理，遇到问题就会艾特人，不知道怎么做技术负责人。也不懂向下兼容，就瞎改。就知道抢着发言，搞得像懂很多一样。
- 想啥呢
- 理想的自己，想成为的人
- 人无远虑必有近忧
- 目标
- 有没有技术含量，有没有成长，有没有沉淀
人唯一的出路，就是自己厉害，就是有一技之长。
家无宁日
马云说，阿里巴巴可能会失败，但是走阿里巴巴这条路的人一定会成功。我们失败也许因为我们不够聪明，我们没有变化或者我们变化的错误。但是走这条路的人一定会成功，就是帮助无数的小企业。
你好，未必是大势好，大势好，未必是你好。
没有人认可你，从来没有，就像YZJ。
慢就是稳，稳就是快
曾经以为坚不可摧的嫡系也要走了，没有永远的嫡系。最菜的还留着。
再努力方向不对也没用，别人再问就说不知道。只做必须要做的，反正做再多也就这些钱。
有没有自己的坚持（固执），有没有自己的思考。
所以逃避的东西，最后都会在某个地方悄悄等你。
这是最终态吗？显然并不是。
打游戏和绩效都是别人控制的。
康雍乾，嘉道咸，同光宣。
被设计、被捉弄、被安排的人，永远是最后一个才知道的。
Clear Clear
干净，清爽。
Clear 就是扔掉无用的、重复的，跟消除 TODO 不是一样的吗？
一眼望到头
一鼓作气
三种事情
- 业务
- 业务相关的技术
- 业务无关的技术（至少暂时）
吸血鬼。xx 都是。
UE unreal engine
han （汉） s：simplified
han （汉） t：tradition
老家，山东老家，一直在被“强迫”，违背自己意愿。
这种环境只能培养出虚伪、“会来事”的墙头草、见风使舵的人。
这种环境长大的人怎么可能成大事？
强迫做什么呢？吃席，参与自己不喜欢不想去的场合，走没什么交集没任何感情的所谓亲戚，
你看我理不理他就完了。
一方感觉到舒服，另一方一定是付出的多。
- 夫妻
- 父子
- 顾客和服务员
- 小区居民和保安
- 点外卖的和送外卖的
- 写字楼白领和行政人员
- 乘客和司机
- 领导和牛马
- 组员和组长
- 用户和开发&客服
- 司机和交警
- 皇帝和大臣
- 老师和学生
- 医生和患者
- 同学之间
- 朋友之间
- 同事之间
- 合作伙伴之间
太高看自己了，啥也不是，啥成果也没有。
战胜拖延，立即开始，立即停止。
文字、图标、简略，steps，switch，tabbar。
写作的展现，是一种广度路线，产生间接、长尾效应；演讲的展现，是一种深度路线，产生直接、深度连接。
我对升级阶梯的定义也是 5 个：初级、中级、高级、资深和专家。
至于对不同级别的定义，我选择了三个相对容易判断的维度：
- 具备什么能力？
- 解决什么问题？
- 产生多大影响？
关于代码评审就是我从业多年来遇到的一个非常有意思的问题，大家都觉得它有用，也都说好，但很多时候就是执行不下去。因为它不是一个简单问题，而是一个系统问题。万维钢在《线性思维与系统思维》这篇文章里，给出了一些系统问题的典型特征，其中有两条是这样说的：
- 多次试图解决一个问题，却总是无效；
- 新人来了就发现问题，老人一笑了之。
我呆过的很多公司和团队，都想推行代码评审，最后都无果而终。反而是一些开源项目，还搞得有声有色。还是万维钢的那篇文章里，其对系统的定义：“所谓系统，就是一个由很多部分组成的整体，各个部分互相之间有联系，作为整体又有一个共同的目的。” 简单想想就会发现公司项目所在的 “系统” 和开源项目所在的 “系统” 其构成就完全不同，而且目的也不同。
1974 年，美国临床心理学家弗罗伊登贝格尔（Herbert J. Freudenberger）首次提出“职业倦怠”的概念，用来指人面对过度工作时产生的身体和情绪的极度疲劳。
一种是短期的倦怠感。它出现的状态，可以用两个英文单词来形象地表达：Burnout（燃尽，精疲力尽）和 Overwhelm（难以承受）。
另一种更可怕的倦怠感是长期的，它与你对当前工作的感受有关。
有些人把 “上班” 看作工作的全部，那么这样的人去上班一般都是被动的、勉强的。这样的人就是普遍存在的 “混日子” 的上班族，虽不情愿，但又没有别的办法，毕竟不能失去这份工作的收入。而这种 “混日子” 的状态，其实就是处在一种长期的职业倦怠期。
我把长视频和短视频当作 X 轴，把专业观众和大众观众当作 Y 轴，这样就有四个象限。我的目标是每个象限都有一个对应的账号，把这四个象限全部都吃透。
透明和保密是反义词。
吴军老师曾在文章里写过：“完成一件事，做到 50 分靠直觉和经验，做到 90 分要靠科学和技艺，而要做到 90 分以上则要靠艺术。”我是认同这个观点的，而且我们完成作品的目标应是 90 分以上，这是作品的特性决定的，因为创作就是艺术的核心所在。
正如世界上没有两片完全一样的树叶，也许也不会有两个认知视角完全重叠的人，这样相互进行代码评审也就弥补了个人单一视角和认知思考的盲点问题。除此之外，代码评审还有一个社会性功用，如果你在编程，而且知道一定会有同事将检查你的代码，那么你编程的姿势和心态就会完全不同。这之间的微妙差异正是在于会不会有人将对你的代码做出反馈与评价。
公司的核心团队成员如何？看看之前都有些什么样的人，你对这个团队的感觉契合么？价值观对味么？这个团队是合作融洽，还是各怀鬼胎？有些小公司，人虽不多，办公室政治比大公司还厉害。
桥水基金创始人雷·达里奥（Ray Dalio），也是近年畅销书《原则》的作者，制作过一个视频叫《三十分钟看清经济机器如何运转》，他在视频的末尾提出了三条建议：
- 不要让债务的增长速度超过收入。
- 不要让收入的增长速度超过生产率。
- 尽一切努力提高生产率。
这三条建议虽然是针对宏观经济的，但我理解转化一下用在个人身上也是无比正确啊。特别是第二条，现下多接外包提高了当下的收入，但长期可能会抑制你的生产率，让你失去竞争力。
生产率是一个宏观经济术语，用到程序员个人身上可不能直白地理解为产出代码的效率，正确的理解我认为是个人价值的产出率，即如下等式：
个人生产率 = 个人价值的产出率
本质是找对你好的人，而对你好的人和伤害你的人，是两类人。
顺其自然和用力是反义词，太过顺其自然不一定是褒义词，不一定是正确的。用力向上，用力维持体态，用力坚持，用力锻炼。
程序员生涯这么短，最重要不就是那几个开源项目吗，怎么能说清空star就清空呢？
关于 IM 类消息应用最核心的一个技术决策是：消息模型。微信的方式和我们并不一样。
微信的方式是基于消息版本的同步加存储转发机制，而我们则是基于用户终端状态的推送加缓存机制。微信的机制从交互结构上更简洁和优雅一些，在端层面的实现复杂度要求更低，符合其重后端、轻前端的设计思路和原则。
本杰明·富兰克林是这么说的：
要么写点值得读的东西，要么做点值得写的事情。
写作本身就是一个关于选择的活动，而值得写的东西，本来也是稀少的。选择少有人走的路，通常也意味着你要大量地尝试，考虑自己的长处加上刻意的练习，虽不能保证成功，但却在创造可能性。
我会采用计划清单来安排时间，每天其实早就做好了计划。计划得满满当当的，一件接一件地划去待办事项列表（TO-DO List）上的条目，成就感满满的。但执行了一段时间后就发现了问题，虽然有计划，但总是有变化，计划得太满，变化来了就总会让计划落空；计划得不到执行，就会产生懊恼与愧疚感。
一开始我以为是计划得太满，缺乏弹性，所以无法应对变化。如果在计划里留出弹性空间，那么这些空间就是空白的，但如果一天下来没有太多变化发生，那这些留出的空白空间我又该做什么呢？这么一想，我突然就明白了，原来所有的日常计划都应该是备用的 B 计划（ Plan B），而真正的 A 计划（Plan A）就是变化，那种让你产生 “哇～噢～” 的惊叹感觉的变化。
每个阶段会有每个阶段的生活目标。刚毕业时，对我来说合适的目标应该是：自力更生，好好生存下来并获得成长。再之后几年，生活目标会进化到：恋爱成家。再往后，目标也随之发展为：事业有成，家庭幸福。而我当时的症结在于，错把平衡当作了目标，而实际平衡更多是一种感受。有句话是这么说的：
人若没有目标，就只好盯着感受，没有平衡，只有妥协。
认清自己当前阶段的目标，定义清楚这个阶段的平衡点。一个阶段内，就不用太在意每一天生活与工作的平衡关系，应放到整个阶段中一个更长的周期来看，达到阶段的平衡即可。通过短期的逃避带来的平衡，只会让你在更长期的范围内失衡。
做什么事情会做完一身轻呢，舒畅，爽。整理？扔垃圾？
五种连接圈层，第一层次 “10” 的连接是强连接；其他的都是弱连接，弱连接的价值在于获取、传递与交换信息。强连接交流情感，弱连接共享信息。
而建立连接的关键在于：给予。也许并不需要物质上的给予，仅仅是心理上或是虚拟的给予。所以说为什么展现是扩大连接的基础，展现即创作表达，创作即给予。另外，建立连接得先提供价值，而且还得源源不断。
关于 PPC 个人发展理论的分享就到这里了，我们总结一下：
- 专业，建立价值内核；
- 展现，提供价值输出；
- 连接，完成价值交换。
十多年前，我以为程序员的成长终点是架构师，后来我知道了，程序员的自然连续成长终点是资深程序员，也许还有 “神” 级程序员。但架构师却是从某个点开始断裂分叉的另一条路，从程序员到架构师，就需要跨越非连续性断点，而转型到技术管理者也会面临同样的非连续性断点。
成长路上的三人行，此时的“三”不再是虚数，而是指代身边的三类人，它们是：
- 前辈
- 同辈
- 后辈
前辈的价值在于：他们走过的路，你不用再去摸索，只需快速顺着走下去
前辈的另一个价值在于塑造环境，而环境决定了整体的平均水平线，在这个环境中的个体很少有能大幅偏离的。
我所在中学的这个环境中，每一届高考学生都是下一届的前辈；每一年这些 “前辈” 们都在把学校的高考水平线抬高一点点，在前进道路的尽头继续探索走出长一点点的路来，而到我的下一届终于实现了零突破。
所以说在一个既定环境中，有强悍的前辈是我们的好运气。
技术主管的角色与架构师这一角色会产生一些职责上的重叠，事实上我认为在团队规模比较小的时候（十来人的规模），架构师和技术主管的职责几乎完全重叠，甚至技术主管还会代理一些团队主管的角色。
随着软件系统复杂度和规模的提升，团队也相应变大，那么一个架构师此时所处的职责位置就开始和技术主管区别开来。如果把技术主管想成是站在楼顶看整个系统，那么架构师此时就是需要飞到天上去看整个系统了。
如果你想要学习一门新技术或在项目中引入一项技术，就可以试试套用 “海尔迈耶系列问题” 来自省一番。
- 你学习这项技术的目标是什么？清晰地表述出来。
- 这项技术现在是怎么做的？有什么局限吗？
- 这项技术有什么创新之处？为什么它能够取得成功？要是在项目中引入这项技术，谁会关心？
- 如果这项技术能成功，会带来怎样的变化？
- 采用这项技术的成本、风险和收益比如何？你需要花费多少资源（时间、金钱）？如何去评估它的效果？
程序员有时粗浅地学习并了解了一点新技术，就想着如何应用到真实的项目中。这时用上面的问题来问问自己，如果有回答不上来的，说明你对这项技术掌握并不充分，那就还不足以应用到实际项目里。
除了技术领域，你成长路上的许多行动，都可以此为参考坐标来反思：“这项行动的目标清晰吗？行动的方法有可参考的吗，局限在哪？我能有何创新之处？完成这项行动，会给我带来怎样的变化？我要付出多少时间、金钱和精力？行动过程中我该如何评估？行动结束的标准是什么？”
这就是自省，从埋头做事，到旁观者视角的自我反思。
工作之余，你都在做什么？我猜有人会说，工作已经够忙碌了，业余时间就该好好休息和娱乐了。的确，有很多人是这样选择的，但也有不少人不是的。即使再忙，有些人就喜欢在业余时间做点事情，这可能是一种性格特质，拥有这种性格和热情的人，总是能在忙碌的工作之余安排点其他内容，比如：
- 看看程序设计相关的书、文章和博客；
- 参加一些技术主题论坛或会议；
- 写写技术博客；
- 创建自己的业余项目（Side Project）。
以上前两条是接收和学习知识，第 3 条是总结和提炼知识，最后第 4 条则是实践所学，获得新的技能或加强旧的技能经验。
特别是第 4 条“创建自己的业余项目”，我感觉这是每一个程序员都应该做的事，为什么呢？在现实中切换一次工作环境是有比较高的成本的，开启自己的业余项目能帮助你打破工作内容和环境的限制，让你去做一些你喜欢做，但在工作中还没机会做的事。另一方面，业余项目也是你练习新技术和新技能的最佳试验场，相比你直接用真实的项目去实验，承担的风险和压力都要小很多，这样你也就有了机会去接触你想要学会的新技术。
不断练习重构优化和维护自己的专属工具库，删减了很多冗余代码，又新增了不少，剩下几万行代码。这个过程大约持续了七年，基本每年重构优化一次。每一次重构，都是对以前自己的否定，而每一次否定又都是一次成长。
在做业余项目中最大的收获是：完整地经历一次创造。这样的经历，对于程序员来说可能在很多年的工作中都不会有太多机会。写程序，实现系统，发布交付，仅仅是创造的一个中间部分。而完整创造的第一步应是确定你要创造什么，明确它，规划它，找出创造它的方向和路径，做出决策，然后才是下定决心去实现它。
一方面，业余项目只能在业余时间做，而业余时间又是那么有限，这样的时间制约决定了你只能走极简路线，要么保持足够简单，要么就可能陷入膨胀的泥潭，从而失控导致失败。另一方面，正因为业余项目不会给你带来直接的金钱收益，所以你选择增加的每一个特性，要么让你感觉有意思，要么能磨练提升你的手艺，打磨你的深度。
沟通一般有两个目的：一是获取或同步信息；二是达成共识，得到承诺。前者需要的是清晰的表达和传递，后者就需要更深的技巧了。这些技巧说起来也很简单，核心就是换位思考、同理心，外加对自身情绪的控制，但知易行难在沟通这件事上体现得尤其明显。
每天 每周 每月 挺直腰背有多久呢，有没有统计呢？
“在资源和人脉面前，技术就是一坨屎”—--说出这种话的人，没有学会思考！对于一个中国软件企业，关系是充分条件，技术是必要条件。所有强调技术不重要的企业，都栽在关键时刻技术掉的链子下。成本，性能，需求，扩展性…⋯不是只懂堆代码的年轻人能搞定的。技术拉垮，然后得罪客户，进而拖累商务关系！这是所有认为技术不重要企业的宿命，也是唯一的归宿！
"技术是基础。"
-- 2025.12.7
幻想症。。。再牛逼的校招生第一年也不会是扛把子
看你打字不是个好惹的人，但怎么老板敢这么说你呢，现实中唯唯诺诺，网络上重拳出击？
能力太差的人，是没有办法正确评估工作内容的难度和重要性的
-- 2025.12.7
Debut”一词（发音为/der'bju:/或 day-BYOO） 指的是一个人在某个领域或角色中的首次亮相或表现，常见于娱乐、体育、文学、时尚等领域。 “Debut”的常见用法：
1.娱乐与艺术
- 歌手的 首张专辑（debut allbum）。
- 演员的 电影处女作（film debut）。
- 乐队的 首次登台演出（live debut）。
2.体育
- 运动员的 职业首秀（professional debut）。
3.文学与时尚
- 作家的 处女作小说（debut novel）。
- 设计师的 首场时装秀（fashion debut）。
-- 2025.12.7
什么是「创作者精神」
可以总结为三点：
- 原创精神
- 充满诚意执行力
- 实验性精神
先说说①原创精神。什么是原创？原创并不是凭空创造，而是一种经过思考的借鉴。比如《原神》，在玩之前可能都以为它是抄袭的《塞尔达》，而玩了之后发现它只是用了《塞尔达》大世界的想法，游戏本身的战斗机制「元素力」其实非常具有原创性与开拓性，同时「七国」的世界观、场景美术优秀表现力都十分的出色，甚至远远把《塞尔达》抛在了身后。国内能把原创IP做好的团队不多，「米哈游」绝对算一个。
和人一样，公司也有人设，有些公司给人的印象是抄抄抄或者买买买，有些公司给人的印象则是创新与品质。
这就很像“创作型歌手”和“翻唱型歌手”，
什么是张力？
「张力」一词来自于物理，物体受到拉扯后的牵引力。
「性张力」源自于角色本身的特质冲突而产生的魅力，从而产生对异性的吸引力，白话就是上头。
「性缩力」则相反，白话就是下头。
在性张力这块《绝区零》绝对拿捏的十分到位，我把它总结为以下几点：反差感、攻击性、克制力、距离感。
①反差感
如果只是漂亮当然没有问题，但如果除了漂亮之外还有一层「意外感」，才能吸引住对方，这是性张力的根本。看似霸道，却是意外得平易近人；明明看着不好说话，却意外得会关心人；看似严肃，却意外的嘴甜。
分类和聚类的定义与核心区别
分类（监督学习）
- 目标：根据已知标签的训练数据，构建模型来预测新样本的类别（离散标签）。
- 关键点：需要已标注的数据（即每个样本有明确的类别标签）。
- 示例：垃圾邮件分类（输入邮件文本，输出“垃圾”或“正常”）。
聚类（无监督学习）
- 目标：将无标签的数据按相似性自动分组，组内样本相似度高，组间差异大。
- 关键点：无需标注数据，算法自行发现数据中的潜在模式。
- 示例：客户分群（根据购买行为将用户分成不同群体，无预先定义的类别）。
什么是SRE?
SRE（Site Reliability Engineering，站点可靠性工程）是 Google 于 2003 年提出的一种工程实践和文化理念，旨在通过软件工程的方法来管理系统运维，提升系统的可靠性、可扩展性和效率。SRE 团队通常由具备开发和运维双重技能的工程师组成，他们通过自动化、监控、容量规划等手段，确保服务的高可用性和稳定性。
问问自己有核心竞争力吗
大部分人都没有，程序员的竞争力无非这几种
- 名校学历
- github 500star+项目作者
- 长期积累的博客
- 社区有知名度、影响力（掘金等）
- 项目有亮点、难度
- 大厂实习工作经历
- 竞赛奖牌
xxx，可以润了？垫底水平吧这是
- 出去可能连调薪都没有，这个泳池成绩不好换泳池也不解决根本问题
上市对美国的企业是起点 而对中国的企业是终点。
- With pump（充血状态）
- No pump（非充血状态）
职场四大生命周期
| 时期 | 主要特征 | 重点任务 | 关键挑战 |
|---|---|---|---|
| 黄金期 | 单身或两人世界，且无家庭负担 | 练实专业技能，培养职业素养 | 如何快速积累技能，确定职业目标与方向 |
| 平缓期 | 有了孩子，或有了家庭负担 | 精深职业素养精熟时间管理，磨炼心理弹韧性 | 工作与家庭的平衡，调整职业目标适应生活，抗压和适应能力 |
| 突破期 | 孩子上学，或（且）家庭负担变轻 | 寻求职业突破，最大化个人价值 | 加速职业发展，提升个人影响力 |
| 衰退期 | 体力与精力明显下降 | 传承经验与知识 | 对技术与变化的适应 |
遇到一点小问题，就紧张晞晞的，把压力下放，
（高绩效）轮着来看似公平其实不公平。
always make story
此处重温 goodhart's law：一项指标一旦变成了目标，它将不再是个好指标。
研发对自己使用的工具还是要有强掌控，对系统边界和隔离度有一定的基础认识，同时也要清楚哪些故障是自已力所不能及的。完全依赖某个平台或工具来保证逃生，不太现实。平台本身为了给用户提供便利，同时提供底座能力，就会做很多集成，天然会扩大爆炸半径，这是难以避免的。
长大后才发现，能留在老家发展的是父辈有本事的。
开店的千万记住他干让他干，千万别心软去跟他说，你休息一下吧，想吃什么自己去拿，今天没事早点走吧，等等之类的话，
小人畏威不畏德，这是人生的第一课，每个人都必须学会。人到中年，我见过各种人，体会很深。
verbatim - 逐字的 ［v3.r'beitim］
It was nothing but a verbatim translation.
这只不过是逐字的直译罢了。
esoteric - 深奥的
The quantum theory is not just an esoteric addendum.
量子理论并不只是一个深奥的附录。