yixi RSS Feed

UI组件库思考

Tue, 18 Nov 2025 22:00:00 GMT

最近内外网不约而同又开启了一轮关于框架与组件的讨论。结合近期调研与团队实践，把“组件库选型”这件事梳理一下，附典型候选库与落地建议。

问题定义

组件库不止是“有现成控件可以用”，更是工程与体验的约束集合：

可访问性：键盘操作、ARIA、焦点管理是否开箱到位
可定制性：主题、Design Tokens、CSS 变量、Tailwind 的兼容程度
稳定性与生态：维护活跃度、版本节奏、周边社区是否健全
国际化与RTL：文案长度、日期/货币、布局是否天然支持
性能与SSR：Tree-shaking、服务端渲染兼容、样式体积

选型原则

原子化优先：优先选“可组合的无样式原子组件”，再按需叠样式
分层解耦：UI原子层、业务组件层、页面装配层分开
主题先行：先固化Design Tokens与主题机制，避免后期返工
生态互补：数据与路由用 TanStack，交互原子用 Radix/Headless UI
可退可进：允许在关键场景下自研或替换某些控件

候选库速览

Headless UI: 无样式、可访问性完备的原子组件，适合搭配 Tailwind 快速做表单与交互 https://headlessui.com/react/input
DaisyUI: Tailwind 插件式主题与样式集合，上手快、风格统一，但可定制性与无障碍需要二次审视 https://daisyui.com/docs/intro/
Radix UI: 可访问性的“基础原语”，组合性强、CSS 变量友好，偏长期可维护方向 https://www.radix-ui.com/
TanStack: Query/Router/Table 等工程基建，不是纯UI库，但和上面库组合能覆盖数据密集场景 https://tanstack.com/
MagicUI: 以动效和营销组件见长，适合落地官网/活动页的“视觉亮点” https://magicui.design/docs/components
Aceternity UI: 卡片与悬浮类的高视觉组件，适合局部点缀，不建议承载主流程 https://ui.aceternity.com/components/card-hover-effect
ReactBits: 一些场景化的组件片段（如 model-viewer），可按需取用 https://reactbits.dev/components/model-viewer

落地策略

先固化主题：定义颜色、字号、间距等 Design Tokens，输出 CSS 变量与 Tailwind 映射
建适配层：封一层 ui/atoms 与 ui/molecules，屏蔽底层库差异
渐进迁移：从低风险的输入、选择器、弹层开始替换，逐步到复杂的表格与树
国际化/RTL：同时校验文案长度溢出与布局翻转，避免二次返工
可访问性回归：焦点、快捷键、ARIA 定期自测，纳入发布检查清单

注意事项

样式优先级：Tailwind 与库内样式的覆盖策略要先约定
版本节奏：关注 Radix/TanStack 的破坏性更新与 SSR 兼容性
表格与数据密集页：优先用 TanStack Table，复杂交互（虚拟滚动、列拖拽）更稳

结论

面向中长期维护与复杂交互，首选 Radix UI + Tailwind + TanStack 的组合；需要快速产出且以表单为主，可用 Headless UI 走捷径；官网场景再叠加 MagicUI/Aceternity 做视觉。选型本质是工程能力与体验边界的平衡，先把“主题与适配层”打牢，后续扩展与替换都会更平滑。

AI开发助手-外置知识库思考

Wed, 16 Apr 2025 22:00:00 GMT

海外机房迁移的事情耽误了好久，中间陆陆续续做了一些尝试，使用Planning-execute 架构的Agent可以将Android Native代码(1500行左右)转MRN走通了。但是还是有几个问题

更复杂一些的代码处理就会有一些问题，一次通过率较低
小规模代码下也存在功能缺失的问题
部分样式缺失
在转化的过程中发现MCP起到了负向作用

1~3 可以通过优化planning来逐步解决，MCP这个还需要分析一下Why。

1.问题是目前项目中存在大量的组件库，集团的组件库，团队自己封装的通用组件库，业务组件库，框架内自带的，已有的MCP服务给出的信息没有优先级概念

2.意图识别较差，比如下图

返回的就完全没什么用

AI开发助手

Wed, 02 Apr 2025 22:00:00 GMT

22年chatgpt3.5 刚出来的时候，体验了一下，实现了一个PR审阅的工具，接入到代码仓库中，当时团队同学反响非常不错，但是继续往下研究的时候，发现模型的能力不太够，当时的结论是除了目标明确，耦合较少的任务(如：单元测试&类型文件转换)外，很难在研发流程上有较大的提升。

后续因为业务调整主要尝试将LLM在私域业务上的一些场景进行落地。年初组织调整到新成立的出海业务后，又有时间重新审视这个命题，尤其目前模型很多能力上都媲美研究生博士同时Agent框架与日俱进的情况，感觉研发助手这个命题应该是有一些出路的。

经过一段时间访谈在团队内找到几个场景，可以先搞以下三个，逐步验证模型

出海团队的同学都是从各个团队抽调的，对原来的代码都不熟悉，看代码耗时很长
国际化迁移过程中遗留了很多技术债，比如语言，货币，时间硬编码类，治理的量级非常大，耗时会很长
大仓PDA设备上所有的功能目前都是Native的，这块之前一直想重构成动态化，但是因为人效的原因一直都没成行，但是这块从整体效率&质量的角度还是有必要做迁移的

场景1

可行性还比较高，社区有 https://deepwiki.org/ 这个产品已经做出来了，花了两天时间，大致把我们Native项目跑起来了，可以看下图，基本流程，关键代码等准确率很高

场景2

这个比场景一还简单一些，因为规则都相对确定，同时上下文耦合很小。所以只需要实现工程能力遍历代码仓库就可以。

执行的时候遇到唯一的麻烦是不知道规则覆盖是否全面，所以提前让AI汇总出来分成几十类的问题，同时针对不确认归属的单独标注了出来，让RD来制定方案就行。

场景3

这里遇到一些问题，采用planning-execute架构，1500行左右的Activity项目可以较为丝滑的迁移，各种功能都没问题，不过UI样式上面需要进一步调整一下

继续尝试4000左右行的项目就遇到一些问题

功能存在丢失
样式存在有组件上有className，没有对应的style
一次通过率很低，人工介入成本高
组件库使用MCP的召回不准确

1&2功能和样式的问题可以在规划时对每个任务的规模做限制进行处理来解决

3需要规划时任务的拆分合理，并且有足够好的反馈机制

4属于复杂问题中Disorder类的问题，还需要进一步做分析判断才行

利雅得出差游记

Tue, 11 Feb 2025 22:00:00 GMT

业务准备在利雅得展业，系统还有很多问题需要去现场进行处理，春节前公司就帮忙申请了工作签，节后到北京当天就直飞利雅得。

本次工作上主要两个事情

第一次出海，大家对于实际网络环境不是很有底，所以还是要去探查一下当地网络情况，同时梳理下竞对体验对比。两周时间，基本上就要在利雅得四处跑。
由于各种原因，大老板想看下H5是否有承载对C业务的可能性。虽然我从直观上感觉就不太现实，毕竟国内PDD的H5做的最好，出海的temu还是用的Native动态化的方案，早期Facebook也是吃了很大的亏。

对于个人来说，因为疫情影响一直没出国玩过，这次还是有点不太放心的，所以提前找当地的小伙伴做了相关的攻略算是提前了解了一些情况，过去之后发现真如“小马过河”一般。

基建&环境

机场刚落地时感官还是很好的，标志都是中文，阿语，英文三国语言，还比较现代，出关很快。在Uber上打车后发现路上的车都挺破的，日系车比较多，和刻板印象中的完全不一样。因为测网速直接在机场办了电话卡，最后只办成了STC、Zain的也遇到小红书上提到的系统故障没办法办理了。

呆了两个酒店，感觉都不错，就是香水味太浓了，熏的鼻子不舒服，酒店行业标准化的服务整体和国内没有什么区别。

两周走遍利雅得，整体感受来说基建还挺好，大部分时间5G覆盖都很足，除了一些疑似“贫民窋”的区域，测网速路过也没有敢长时间停留。

这面商场不像国内好几层，普遍的只有一层，但是占地面积很大，期内的陈设店面也都很标准化。

生活习惯方面

因为我自己属于“食不厌精脍不厌细”那款，在这面是真绷不住了。

除了炸鸡就是汉堡，还有一些本地的类似快餐的小吃。带了两周把带过去的十几包泡面都吃光了，最后小红书上找攻略去温超吃了一顿 long火锅，人均400。又找到两个当地的中国饭馆其实也挺好，100%非预制，食材很新鲜就是很贵，一个蛋花汤就要40，正经的炒菜100起步。看到一个黑人小哥拿着大锅在那爆炒莫名的喜感。

所以从这个角度看帮大家吃的更好在这面是很有市场的。

因为宗教原因，这里是禁止售卖酒的，听local的同事说他们一般周末的时候去邻国旅游就是为了喝口酒，这也导致这面菜很多都是辣的。

娱乐的角度看还是比较匮乏的，女子不带头巾的还是少数，更不可能像中国一样夜市，广场舞之类的，这面的手机上用local账号登录后，推荐的内容也都比较保守，像国内那些擦边基本没看到。

这面确实会存在一夫多妻，但是确实都是生活水平比较好的家庭，而且由于要“平权”，所以对于两个老婆的必须要一碗水端平，比如给买项链必须给两个老婆都买才行。

家庭生活上他们会去超市一次屯够几天的食材，也接受上门服务需要配送费，甚至顺便会给骑手一些小费，这种客户在国内基本很少见。

人方面

这里对于中国人来说还是很有好感的，记得一个uber司机争取我们同意后还拍了一个tiktok，炫耀了一下我们这些来自北京的乘客。而且听local的同事说，他们学校是要学中文的，所以可能也有一些文化认同？

这面很多劳务人员大头是菲律宾的，还有一部分是周边小国的，但是普遍说英语都有一股咖喱味，对我来说理解起来着实头痛。

思考

中国企业出海的进程应该是和国家的战略息息相关的，当国力和国际地位上去了，很多时候企业出国就好办多了，这对于企业就是天时。

中东这面的生活习惯以及相对落后的商业场景算是地利。

tt的一波又一波的文化出海，底层人民对于中国产品与服务也不是很反感，同时会觉得给本地人提供了岗位，整体是友善阵营，这就是人和。

所以对于业务的发展我还是挺看好的，甚至按照这面的消费习惯可能海外小象会更早更快的跑通UE。

但是从个人饮食的角度，让我再来这面出差我可能不会想再来了，幸福指数太低。

知识管理-AI笔记(AI大脑)

Mon, 27 Jan 2025 22:00:00 GMT

让我时隔很多年重新思考笔记这个问题是源于一个“AI大脑”的灵光乍现

过去我有一个很大的痛点：人是会忘记的，这导致在做决策的时候有些信息之前虽然有接触，但是没办法有效召回导致决策质量较差。

现在AI的能力和工程能力绝对可以做到一个“虚拟的我”，祂是我过往所有经验的总和，当我有什么问题和他沟通的时候，一定会贴合我自己的想法给出更好的思考。甚至因为我有习惯做日报周报等，在季度总结年度总结的时候，AI都可以以我的常用习惯给出对应的文章，这基本上能很大的提升效率，做到真正的第二大脑。

最近希望通过AI来解决我的问题，但是体验了好几个AI类的Note但都不是很理想

我的工作习惯贯穿很多环节，所以最希望的是一个知识管理应用而不是一个单一的笔记软件，这个体系包含了几个重要的组成

稍后阅读(支持批注)
思考片段记录能力(类似flomo)
复盘能力(日报周报月报)
各领域的资料体系化沉淀(支持pdf等)
三方读书笔记汇总(微信读书，起点读书)
信息的主动触达能力(用作复习，历史今天，随机推送，猜喜等)
笔记系统(支持外发自有博客，按需多渠道外发)

以上最好是All in one的，这样能最大限度的保证效率，减少信息熵增，减少整体的复杂度

但是很遗憾，目前大部分还是使用专门的应用做管理，导致我目前所有的资料都是分散的，比如稍后阅读在cubox上，笔记&日报周报&读书笔记在Obsidian，思考片段在memo上，复习在anki上，pdf阅读笔记在marginNote上。

可以说每一个APP都很好用，但都是信息孤岛，没有协同效应。

在AI时代，数据是非常重要的一环，如果不能把信息都有效组织给模型，那这里的效果就会差很多。

所以后续周末如果有一些时间，我准备借助Cursor快速把这个应用搞出来，名字叫soil，暗喻是土壤承载一切，孕育一切。

langgraph思考

Wed, 01 Jan 2025 14:00:00 GMT

双向语序

Sat, 07 Dec 2024 22:00:00 GMT

什么是双向语序？

双向语序（Bidirectional Text）是指在同一文本段落中混合存在两种书写方向的现象：

RTL（Right-to-Left）：从右向左书写的语言（如阿拉伯语、希伯来语）
LTR（Left-to-Right）：从左向右书写的语言（如英语、中文）

当这两种方向的文字混合使用时，会出现复杂的文本方向嵌套问题。例如：

اللغة العربية (Arabic) 和 English 混合显示

1. Unicode双向算法（UBA）

Unicode标准通过逻辑顺序存储+视觉顺序渲染的机制实现双向支持：

逻辑顺序：按字符输入顺序存储（内存中的二进制序列）
视觉顺序：根据算法动态计算展示顺序（屏幕上的显示效果）

2. 字符类型分类

Unicode将字符分为一下四类，决定其在双向文本中的行为：

字符类型	算法逻辑	示例	Unicode 官方说明
强字符	强字符自带明确的 LTR 或 RTL 属性，不受上下问干扰	Hello 你好 مرحباً -	Strong characters are those with a definite direction. Examples of this type of character include most alphabetic characters, syllabic characters, Han ideographs, non-European or non-Arabic digits, and punctuation characters that are specific to only those scripts.
弱字符	弱字符会跟随上下文内容决定逻辑语序为RTL或LTR。在混排场景下容易出现语序展示异常问题	+-×÷ ￥$€ 1234567890	Weak characters are those with vague direction. Examples of this type of character include European digits, Eastern Arabic-Indic digits, arithmetic symbols, and currency symbols.
中性字符	中性字符没有方向属性	（tab）（空格）: , . \| 。	Neutral characters have direction indeterminable without context. Examples include paragraph separators, tabs, and most other whitespace characters. Punctuation symbols that are common to many scripts, such as the colon, comma, full-stop, and the no-break-space also fall within this category.
显式格式化	又称“假强字符”，在文本展示中没有符号显式，用户不可见，但是会占用2个字符长度。可以用来修正弱字符的展示顺序。	“\u202A \u202C”	Explicit formatting characters, also referred to as “directional formatting characters”, are special Unicode sequences that direct the algorithm to modify its default behavior. These characters are subdivided into “marks”, “embeddings”, “isolates”, and “overrides”. Their effects continue until the occurrence of either a paragraph separator, or a “pop” character.

3. 方向控制标记

一言蔽之：本质是通过Unicode符号显式分隔字符标记起始点，对字符的书写方向进行定义，使文本内容始终按照标记的方向进行展示，而不受段落上下文影响。

// 示例：包裹LTR文本使其在RTL环境中保持方向
const address = "\u202A15 Bay Street, Laurel, CA\u202C";

Unicode符号表

名称	方向	Unicode Code	HTML Code	模式
Left-To-Right Mark(LRM)	左->右	U+200E	‎‎(实体是‎)	隐性
Right-To-Left Mark(RLM)	右->左	U+200F	‏(实体是‏)	隐性
Left-To-Right Embedding(LRE)	左->右	U+202A	‪ordir =“ltr”	显性
Right-To-Left Embedding(RLE)	右->左	U+202B	‫ordir =“rtl”	显性
Left-To-Right Override(LRO)	左->右	U+202D	‭or	显性
Right-To-Left Override(RLO)	右->左	U+202E	‮or	显性
Left-To-Right Isolate(LRI)	左->右	U+2066	⁦or	显性
Right-To-Left Isolate(RLI)	右->左	U+2067	⁧or	显性
First Strong Isolate(FSI)		U+2068	⁨ordir =“auto”	显性
Pop Directional Formatting(PDF)	结束标记	U+202C	‬or	显性
Pop Directional Isolate(PDI)	结束标记	U+2069	⁩or	显性
## 常见问题与解决方案

1. 文字顺序混乱

典型场景：

原文："15 Bay Street" 插入阿拉伯语段落
错误显示："Street Bay 15"

根本原因：

数字(弱字符)与字母(强字符)混合
中性空格符继承主文方向

解决方案：

// 使用LRE+PDF包裹整个地址
const fixedAddress = "\u202A15 Bay Street\u202C";

2. 嵌套方向错乱

典型场景：

英文引用阿拉伯语句子中的英文术语

错误表现： Parent (RTL) -> Child (LTR) -> Grandchild (RTL) 嵌套失败

解决方案：

<!-- 使用隔离标记建立独立方向上下文 -->
<span dir="rtl">
  父文本
  <bdi dir="ltr">子文本 <bdi dir="rtl">孙文本</bdi></bdi>
</span>

3. 标点符号错位

典型场景：

阿拉伯语句尾的英文问号显示在左侧："ماذا حدث?‎"
正确显示应为："ماذا حدث؟‎"

解决方案：

使用语言专属标点（阿拉伯语问号؟）
添加RLM控制符：

const fixedText = "ماذا حدث" + "\u200F?\u200F";

4. 数字显示异常

典型场景：阿拉伯语中的欧洲数字”123”显示为”321”

解决方案：

// 使用阿拉伯-印度数字（٠١٢٣٤٥٦٧٨٩）
const arabicNumbers = "١٢٣"; 
// 或强制指定方向
const fixedNumbers = "\u202A123\u202C";

各技术栈能力

技术栈	API	方案说明	备注
Web	unicode-bidi	CSS unicode-bidi 属性，和 direction 属性，决定如何处理文档中的双书写方向文本（bidirectional text）。比如，如果一块内容同时包含有从左到右书写和从右到左书写的文本，那么用户代理（the user-agent）会使用复杂的 Unicode 算法来决定如何显示文本。unicode-bidi 属性会覆盖此算法，允许开发人员控制文本嵌入（text embedding）。 unicode-bidi 与 direction 是仅有的两个不受 all 简写影响的属性。 `<br>/* 关键字值 /<br>unicode-bidi: normal;<br>unicode-bidi: embed;<br>unicode-bidi: isolate;<br>unicode-bidi: bidi-override;<br>unicode-bidi: isolate-override;<br>unicode-bidi: plaintext;<br>/ 全局值 */<br>unicode-bidi: inherit;<br>unicode-bidi: initial;<br>unicode-bidi: unset;<br>`	默认情况下，浏览器会通过RTL标签自动识别文字和布局方向。对于识别异常的场景，需要通过特殊处理来进行修正。
Java	Bidi BreakIterator	- Bidi 是Java ICU工具包提供的能力，基于 Unicode Standard Annex #9. 算法封装。 - BreakIterator 用于设置字符边界	Java标准ICU工具包
iOS	NSString	iOS：SupportingRight-To-LeftLanguages setbasewritingdirection：文字方向为基础能力，无法彻底解决混排问题。 Unicode标记 `<br>// Wrap the plus (+) prefix and phone number in left-to-right directional markers<br>NSString phoneNumber = @"408-555-1212";<br>NSString localizedPhoneNumber = [NSString stringWithFormat:@"\u202A%@\u202C", phoneNumber];<br>`	手动控制
Android	BidiFormatter	根据文本中强字符的方向，为非强字符添加方向属性，避免文本占位嵌入时展示错乱。如：LTR文本中包含了数字、空格等非强字符，在将这段话插入到RTL文本中时，可能会导致LTR文本中的非强字符被上下文RTL强字符影响，导致展示错乱。	基于ICU能力封装

参考

Unicode Standards Annex #9

国际化-RTL

Sat, 07 Dec 2024 21:00:00 GMT

什么是RTL？

RTL是”Right-to-Left”的缩写，指的是从右向左的书写和阅读方向。与世界上大多数语言（如英语、中文等）采用的LTR（Left-to-Right，从左到右）方向不同，RTL语言有着独特的展示和交互方式。

典型的RTL语言包括：

阿拉伯语（Arabic）
波斯语（Persian/Farsi）
希伯来语（Hebrew）
乌尔都语（Urdu

这些语言覆盖了中东等地区约8亿人口，是国际化产品不可忽视的重要市场。

RTL适配的核心挑战

1. RTL交互设计

文本翻译只是第一步，整个UI交互逻辑都需要适配RTL习惯。这包括：

导航结构
内容流方向
手势交互
视觉层次

2. 文字混排（Bi-directional Text）

当RTL与LTR文字混合时（如阿拉伯语中包含英文单词或数字），会出现复杂的双向文本（Bidi）问题。Unicode虽然提供了基础支持，但实际应用中仍需特别注意。

3. 跨端容器适配

主流跨端框架如React Native、Flutter对RTL有良好支持，但自研框架可能需要改造

4. 自定义控件适配

标准组件通常有官方RTL支持，但自定义组件、动效和手势交互需要业务方自行适配，这是主要的开发成本所在。

RTL适配规范与方案

1. RTL切换机制

Locale识别：通过i18n SDK识别当前语言环境
界面刷新：语言切换后重新加载界面
推荐方案：i18n SDK提供RTL标识，业务代码据此适配

2. 文字处理

纯文本：RTL或LTR纯文本可自动识别，无需处理
混排场景：需要特别处理拼接、占位等可能出现混排的情况
解决方案：
- 布局方向：依赖系统能力
- 双向语序：使用i18n SDK提供的混排能力，见 Unicode双向算法 W3C RTL Script wikipedia:Bidi_text

3. 布局适配

基本原则：
- 支持双向布局，一套代码完成LTR/RTL切换
- 禁止使用left/right硬编码
- 特殊元素单独适配
技术栈方案：
- Web：postcss-rtlcss布局工具
- iOS：iOS-Right to left布局支持
- Android：Android 布局镜像
- React Native：官方RTL方案

4. 图标处理

对称图标：通过代码镜像反转，不增加包大小
非对称图标：可能需要设计两套资源
解决方案：业务层根据RTL标识控制图片显示方式

5. 动效与手势

方向性动效：需要对称反转播放方向
- 页面转场动画
- 轮播组件
- Lottie动画
- 下拉刷新指示器
手势交互：需要调整左右方向
- 页面侧滑退出
- Tab切换手势
- Banner滑动方向

主流跨端框架的RTL方案

1. React Native

Meta从v0.33.0-rc开始支持RTL
在Facebook等应用中经过充分验证
提供全面的RTL布局支持

2. Flutter

通过Directionality组件控制文本方向
支持RTL布局镜像
丰富的RTL感知组件

3. Web方案

CSS方案：使用direction和text-align属性
RTLCSS：通过PostCSS插件自动生成RTL样式
框架支持：主流框架如React、Vue都有RTL方案

国际化（i18n）和本地化（l10n）区别与联系

Fri, 06 Dec 2024 23:00:00 GMT

国际化（Internationalization，i18n） 和 本地化（Localization，l10n） 是软件开发中支持多语言、多地区的两个关键概念

1. 定义

国际化（i18n）

目标：设计软件，使其能轻松适配不同语言和地区，而无需修改代码逻辑。
关键任务：
- 使用 Unicode（如 UTF-8）处理文本。
- 分离代码与可翻译文本（如资源文件 .json/.properties）。
- 支持动态的日期、时间、货币、数字格式化（如 ICU 库）。
- 处理复数规则、性别敏感文本、文本方向（RTL/LTR）。
示例：

// 国际化代码（React-i18next）
<p>{t('welcome_message')}</p> // 根据用户语言动态加载文本

本地化（l10n）

目标：将已国际化的软件针对特定语言/地区进行适配，包括翻译、文化适配等。
关键任务：
- 翻译文本（如英文→中文）。
- 调整日期格式（如 MM/DD/YYYY → DD/MM/YYYY）。
- 本地化货币符号（如 $ → ¥）。
- 适配文化敏感内容（如颜色、图标、法律合规性）。
示例：
- 英文："Color: Red" → 中文："颜色: 红色"
- 美国日期："May 20, 2025" → 德国日期："20. Mai 2025"

2. 区别

特性	国际化（i18n）	本地化（l10n）
阶段	开发阶段（代码层）	发布阶段（内容层）
目标	使软件支持多语言	为特定地区定制内容
改动范围	代码架构、框架选择	翻译、格式调整、文化适配
技术依赖	需要 ICU 等库、Unicode 支持	依赖翻译团队、本地化工具（如 Crowdin）
示例	动态加载资源文件	将按钮文本从 “Submit” 改为 “提交”
## 3.联系

依赖关系：
- 必须先国际化（i18n），再本地化（l10n）。没有国际化的软件无法高效本地化。
- 例如：若代码硬编码了英文文本，本地化时需要修改代码，而非单纯替换翻译文件。
共同工具：
- 两者都依赖国际化库（如 ICU、i18next）和本地化平台（如 Transifex、Lokalise）。
完整流程：开发 → 国际化（i18n）→ 本地化（l10n）→ 发布

4. 一句话总结

国际化（i18n） 是技术准备，确保软件能支持多语言。
本地化（l10n） 是具体实施，为特定地区提供翻译和文化适配。

国际化项目中 ICU 是什么

Fri, 06 Dec 2024 20:00:00 GMT

在 国际化（i18n）和本地化（l10n） 开发中，ICU（International Components for Unicode） 是一个由 Unicode 联盟维护的开源库，提供了一套强大的工具来处理多语言文本、日期时间、数字格式化、复数规则、性别敏感文本等国际化需求。ICU 是许多操作系统（如 Android、iOS、Linux）和编程语言（如 Java、C/C++、Python）的底层国际化支持库。

ICU 的核心功能

ICU 的主要功能包括：

1. 文本格式化与解析

数字格式化（货币、百分比、科学计数法等）

    // 示例：格式化货币（美元）
    NumberFormat.getCurrencyInstance(Locale.US).format(1234.56) → "$1,234.56"

日期时间格式化（支持不同历法，如公历、农历、伊斯兰历等）

// 示例：格式化日期（法语）
    SimpleDateFormat("EEEE, d MMMM y", Locale.FRANCE).format(new Date()) → "lundi, 19 mai 2025"

2. 字符串比较与排序（排序规则）

支持语言敏感的字符串排序（如德语 ä 排序规则不同于英语 a）。
Unicode 规范化（Normalization），处理变音符号（如 é vs. é）。

3. 字符编码转换

支持 UTF-8、UTF-16、GB2312 等多种编码转换，确保文本在不同编码环境下的正确显示。

4. 复数规则（Plural Rules）

不同语言的复数形式不同（如英语 1 book vs. 2 books，俄语有更复杂的规则）。

// 示例：俄语复数规则
"You have {count, plural, one {# книга} few {# книги} many {# книг}}"

5. 性别敏感文本（Gender-aware Formatting）

某些语言（如法语、阿拉伯语）的文本会根据性别变化。

    // 示例：法语（"Vous êtes connecté(e)"）
    MessageFormat.format("Vous êtes connecté{0}", gender == FEMALE ? "(e)" : "");

6. 断行（Line Breaking）和文本边界检测

支持中文、日文等无空格语言的分词（Word Break）
换行规则（如 CJK 文本的换行策略）

7. 时区和国际化日历

支持全球时区转换（如 America/New_York vs. Asia/Shanghai）。
非公历日历（如希伯来历、伊斯兰历）的日期计算。

前端（Web）的 ICU 实现

i18next + 插件

GitHub: i18next Plugin
特点：
- 支持 ICU 消息格式（{count, plural, one {...} other {...}}）。
- 与 React/Vue/Angular 深度集成（react-i18next）。
- 扩展性强，支持后端动态加载翻译文件。
示例（React + ICU 复数规则）：

import i18next from 'i18next';
import ICU from 'i18next-icu';

// ICU 语言规则（可选，默认已内置常见语言）
import en from 'i18next-icu/locale-data/en';
import zh from 'i18next-icu/locale-data/zh';

i18next
  .use(new ICU({ localeData: [en, zh] })) // 加载 ICU 插件
  .init({
    lng: 'en', // 默认语言
    resources: {
      en: {
        translation: {
          // ICU 格式的翻译键值
          greeting: "Hello, {name}!",
          items: "{count, plural, one {# item} other {# items}}",
          date: "Today is {date, date, short}",
          gender: "{gender, select, male {He} female {She} other {They}} likes this."
        }
      },
      zh: {
        translation: {
          greeting: "你好，{name}！",
          items: "{count, plural, other {# 个物品}}",
          date: "今天是 {date, date, short}",
          gender: "{gender, select, male {他} female {她} other {他们}}喜欢这个。"
        }
      }
    }
  });

### **(1) 复数规则（Pluralization）**
// 英文：根据 count 返回不同复数形式
t('items', { count: 1 }); // "1 item"
t('items', { count: 5 }); // "5 items"
// 中文：中文复数通常只有一种形式
t('items', { count: 5 }); // "5 个物品"

### **(2) 性别敏感文本（Gender）**

t('gender', { gender: 'male' });   // "He likes this." / "他喜欢这个。"
t('gender', { gender: 'female' }); // "She likes this." / "她喜欢这个。"

### **(3) 日期/时间格式化**

t('date', { date: new Date() }); 
// 英文： "Today is 5/20/2025"
// 中文： "今天是 2025/5/20"

### **(4) 数字格式化（货币、百分比等）**

// 需要在翻译键值中定义格式
{
  price: "Price: {value, number, ::currency/USD}"
}

t('price', { value: 1234.56 }); // "Price: $1,234.56"

与普通 i18next 的区别

特性	普通 i18next	i18next + ICU
复数规则	仅基础（`_plural`）	完整 ICU 复数（`one/few/many`）
性别/选择语法	不支持	支持 `{gender, select, ...}`
日期/数字格式化	需手动处理	内置 `{date, date, short}`
灵活性	简单场景	复杂国际化需求

i18n要素

Thu, 05 Dec 2024 19:00:00 GMT

一、货币本地化

1. 货币符号

不同地区使用不同货币符号（如：¥/$/€/£）
示例：人民币(¥)、美元($)、欧元(€)

2. 货币精度

小数位数规范（日本円通常取整，人民币常用2位小数）
示例：100 JPY vs 100.00 CNY

3. 货币符号位置

前置或后置（€3.50 vs 3.50€）
与数字的间距规范

二、时间本地化

1. 时制系统

12小时制（AM/PM）vs 24小时制
示例：美国常用 2:30 PM，德国用 14:30

2. 时间格式

分隔符选择（: / . / 空格）
顺序差异（HH:mm:ss vs hh:mm:ss a）

3. 剩余时间表达

“还剩2天3小时” vs “2d 3h remaining”
相对时间表达（刚刚/now/刚才）

三、度量衡系统

1. 距离单位

单位制	常用地区	示例
公制	中国, 欧洲	5 km, 300 m
英制	美国	3 mi, 500 ft

2. 重量单位

公制：kg/g（中国、欧洲）
英制：lb/oz（美国）
传统单位：斤/两（华语区市场）

3. 体积单位

升/毫升（大多数国家）
加仑/液量盎司（美国）

四、数字格式

1. 数字分隔符

千分位符号：,（英语） vs .（德语） vs 空格（法语）

示例：
  英语：1,000,000
  德语：1.000.000
  法语：1 000 000

2. 小数点符号

点号（1.5）vs 逗号（1,5）

3. 特殊数字格式

手机号显示：中国：+86 138 0013 8000 美国：(650) 123-4567

微信私域思考

Wed, 01 May 2024 22:00:00 GMT

复杂小程序架构思考

Mon, 08 Apr 2024 08:00:00 GMT

私域灰黑玩法

Tue, 02 Jan 2024 01:00:00 GMT

如何阅读科学文献

Sun, 01 Oct 2023 22:00:00 GMT

为什么需要掌握科学文献阅读？

在AI快速发展的今天，每天都有大量的研究论文发布。以计算机视觉领域为例，仅arXiv每天就有50+篇新论文。面对如此庞大的信息流：

信息过载：无法判断哪些论文值得深入研究
效率低下：花费大量时间却抓不住重点
理解困难：不熟悉学术写作规范，难以快速定位关键信息

掌握科学文献阅读方法，能够帮助我们：

快速筛选：在海量论文中找到真正有价值的内容
高效理解：用最少时间掌握论文核心贡献
知识构建：将零散的研究串联成系统性认知

文献获取与分级

主要获取渠道

开放获取平台

arXiv：计算机科学预印本首选（CS类别下的AI、CV、CL等更新最快）
DBLP：计算机科学文献索引，可按作者/会议/关键词检索

核心学术平台

IEEE Xplore：计算机网络、AI、硬件领域顶会/期刊，覆盖80%计算机顶会
ACM Digital Library：软件工程、编程语言、计算机图形学权威平台
SpringerLink：包含LNCS系列会议论文集

辅助工具

Google Scholar：支持文献引用追踪
Semantic Scholar：AI驱动文献推荐
Connected Papers：可视化论文关系图

文献分级体系

等级	会议示例	期刊示例	接收率	特点
顶级	SIGCOMM, CVPR, NeurIPS	TPAMI, JACM	<20%	突破性创新，引用量高
A类	INFOCOM, ICCV, ICML	TOCS, TSE	20-30%	方法创新，实验充分
B类	GLOBECOM, AAAI	Computer Journal	>30%	应用创新，工程价值

分级判断方法：

CCF推荐列表：中国计算机学会官方分类
JCR分区：Q1-Q4影响因子排名
学者声誉：作者在领域内的影响力

论文结构解析

标准IMRaD结构

计算机领域论文基本遵循IMRaD结构，了解每部分作用有助于快速定位信息：

章节	作用	阅读策略	时间分配
Title	精确反映研究核心	判断相关性	10s
Abstract	四要素总结	决定是否继续	1min
Introduction	问题背景与贡献	理解动机	5-10min
Related Work	技术脉络梳理	建立知识图谱	略读
Methodology	核心技术方案	深度理解	20-30min
Experiments	验证与对比	评估可信度	10-15min
Results	量化结果展示	关注数据	5min
Discussion	局限性分析	批判思考	5min
Conclusion	总结与展望	把握全局	3min

特殊要求识别

理论证明：需包含Lemma/Theorem/Proof结构
系统论文：必须提供架构图与性能指标
数据集论文：要求数据可获取声明

实战案例：《Attention Is All You Need》解析

摘要（Abstract）

标准摘要包含四个核心要素：

研究问题（1句）

“The dominant sequence transduction models are based on complex…”
方法创新（1-2句）

“We propose a new simple network architecture, the Transformer, based solely on attention mechanisms…”
实验结果（量化数据）

“Experiments on two machine translation tasks show these models…”
理论价值（1句）

“We show that the Transformer generalizes well to other tasks…”

引言（Introduction）

1. Current State（现状梳理）

主流技术：RNN/LSTM/GRU主导序列建模
研究进展：encoder-decoder架构持续改进
文献支撑：引用8篇文献（占53%）

2. Research Gap（问题识别）

计算效率：序列长度↑ → 内存限制↑ → 批处理难度↑
硬件限制：GPU并行优势无法发挥
量化表述：长序列训练速度下降60%

3. Existing Solutions（现有方案）

技术路线：RNN + Attention机制
效果评估：BLEU提升1.5-2.0，训练时间减少30%

4. Limitations（方案缺陷）

缺陷类型	具体表现	引用支持
架构依赖	仍需RNN作为基础框架	[27]实验对比
并行限制	无法完全摆脱顺序计算	理论推导
效率天花板	模型规模扩展受限	[32]数据支撑

5. 本文贡献（分点列出）

架构革命：首个完全基于注意力的序列转导模型
效率突破：并行度提升8倍，训练成本降低75%
性能验证：BLEU提升2.0+，长序列速度提升7倍

方法论（Methodology）

模型架构（3.1节）

class Transformer(nn.Module):
    def __init__(self):
        self.encoder = EncoderStack(N=6, d_model=512)
        self.decoder = DecoderStack(N=6, d_model=512)
        
class EncoderLayer(nn.Module):
    def __init__(self):
        self.self_attn = MultiHeadAttention(h=8)
        self.ffn = PositionwiseFFN(d_ff=2048)

关键参数配置

参数	值	说明
编码器层数	6	N=6
注意力头数	8	h=8
前馈网络维度	2048	d_ff=2048
Dropout率	0.1	残差连接后应用

注意力机制（3.2节）

graph LR
    A[输入嵌入] --> B[位置编码]
    B --> C[多头注意力]
    C --> D[层归一化]
    D --> E[前馈网络]
    E --> F[输出]

关键技术点：

位置编码公式
多头注意力计算

实验设计分析（Experiments）

训练配置（4.1节）

参数	值	工具支持
优化器	Adam (β1=0.9, β2=0.98)	PyTorch
学习率调度	预热步数4000	自定义调度器
正则化	标签平滑(ε=0.1)	CrossEntropyLoss
硬件配置	8×P100 GPU	NCCL通信库

评估维度（4.2-4.3节）

六维度评估体系：

维度	评估指标	工具方法
翻译质量	BLEU	multi-bleu.perl
训练速度	每秒处理token数	NVIDIA DCGM监控
模型效率	FLOPs计算量	理论推导
泛化能力	不同语种对比	英德 vs 英法

结果解读（Results）

机器翻译结果（6.1节）

BLEU提升：+2.04（EN-DE），+0.51（EN-FR）
训练成本降低：70%（对比ConvS2S）

模型变体分析（6.2节）

graph LR
    A[注意力头数] --> B{8头最优}
    C[键值维度] --> D{d_k≥64保持性能}
    E[前馈维度] --> F{2048→4096提升0.4 BLEU}
    G[位置编码] --> H{正弦vs学习式差异<0.1 BLEU}

句法分析验证（6.3节）

仅用4层Transformer即超越BerkeleyParser
少样本学习能力：Acc=89.7% (Transformer)vs87.2% (RNN)Acc=89.7% (Transformer)vs87.2% (RNN)

讨论（Discussion）无

结论（Conclusion）

方法总结（Level-1 Conclusion）

核心创新声明：

原文定位：“the first sequence transduction model based entirely on attention” “replacing recurrent layers… with multi-headed self-attention”

技术特征：

架构革命：完全去循环化
核心组件：多头自注意力机制
设计理念：并行优先原则

对应章节：与引言中声明的贡献点1（3.1节方法论）形成闭环

成果重申（Level-2 Conclusion）

1. 效率突破

训练速度：比RNN/CNN架构快7倍（详见表4）
硬件利用率：8×P100 GPU实现线性加速

2. 性能突破

任务	BLEU提升	对比基准
WMT2014英德	+2.0	原SOTA模型
WMT2014英法	+1.8	集成模型

3. 里程碑意义

首次纯注意力模型超越集成系统
建立transformer架构新范式

未来方向（Level-3 Conclusion）

1. 技术扩展

A[多模态处理] --> B[图像] A --> C[音频] A --> D[视频]

2. 算法优化

3. 应用拓展

参考文献（References）

阅读策略与技巧

精读策略（2-4小时/篇）

准备阶段

工具准备：三色笔（红：重点，蓝：疑问，绿：延伸思考）
笔记模板：创建电子笔记模板

三遍阅读法

第一遍（结构把握）：

标注摘要四要素（问题/方法/结果/价值）
记录结论三层级（总结/成果/方向）
速览图表，标注理解难点

第二遍（细节理解）：

绘制引言逻辑图（现状→问题→方案→贡献）
复现方法章节的伪代码/公式推导
标注实验设置的baseline选择合理性

第三遍（批判思考）：

追溯参考文献中的关键理论依据
验证实验结果与假设的对应关系
完成”疑问记录”部分

输出产物

思维导图：总结技术路线
综述报告：500字总结（创新点/不足/应用场景）
等级标记：CCF-A/B/C分类

略读策略（≤60分钟/篇）

快速筛选流程

步骤	检查内容	时间分配	筛选标准
1	来源可信度	1min	CCF等级/影响因子/作者声誉
2	摘要要素	2min	创新动词（propose/design/introduce）
3	贡献声明	2min	引言结尾的”We contribute”
4	关键结果	3min	实验数据（SOTA对比）
5	未来方向	2min	结论部分的扩展性

可信度验证

技术可信度：

是否开源代码
数据是否可复现
结论是否被后续研究引用

相关性评估：

与当前研究主题契合度（高/中/低）
技术路线可借鉴性（架构/训练技巧）

分类归档

建立个人文献库分类体系：

核心参考：深度相关，需精读
方法借鉴：技术手段可参考
背景了解：扩展知识面
待定评估：需要更多信息判断

两种策略对比

评估维度	精读策略	略读策略	工具推荐
核心目标	深度理解	快速筛选	MarginNote/ReadCube
时间投入	2-4小时/篇	10-60分钟/篇	Pomodoro计时器
产出形式	技术报告+代码	文献地图+标签	Obsidian/Zotero
适用场景	核心参考文献	领域调研	Connected Papers
信息留存率	85%-90%	40%-50%	Anki记忆卡

实践建议与工具推荐

阅读流程标准化

日常阅读节奏

周一至周三：精读3-5篇核心论文
周四至周五：略读15-20篇相关论文
周末：整理笔记，构建知识图谱

笔记管理系统

文献管理：Zotero + 云同步
笔记组织：Obsidian 双向链接
代码复现：GitHub仓库管理
进度跟踪：Notion项目看板

常见问题与解决方案

阅读困难

问题：数学公式理解困难
解决：先看文字描述，再对照公式，最后查找相关教程

效率问题

问题：阅读速度慢，容易陷入细节
解决：设定时间限制，先抓主线再补细节

知识整合

问题：读过的论文容易忘记
解决：建立标签体系，定期回顾和总结

总结与展望

核心要点回顾

分级阅读：根据论文重要性选择精读或略读策略
结构化理解：掌握IMRaD结构，快速定位关键信息
工具赋能：利用现代工具提升阅读和管理效率
持续改进：建立个人知识库，形成学习闭环

能力提升路径

初级阶段：掌握基本阅读技巧，建立论文库
中级阶段：形成批判思维，能够独立评估论文质量
高级阶段：构建领域知识图谱，指导自己的研究方向

未来发展趋势

随着AI技术发展，文献阅读工具将更加智能化：

AI摘要生成：自动提取论文核心信息
智能推荐系统：基于兴趣的个性化推荐
跨语言理解：自动翻译和解释专业术语

掌握科学文献阅读技能，不仅是学术研究的基础，更是在快速变化的技术环境中保持竞争力的关键能力。

相关阅读：

架构整洁之道-阅读笔记

Fri, 28 Jul 2023 22:00:00 GMT

架构整洁之道，本书适用于架构入门的初学者，没有多少新知识点，而是对架构思想进行了提炼总结，推荐阅读。以下是提炼总结：

设计与架构究竟是什么：软件架构的终极目标，用最小的人力成本来满足构建和维护该系统的需求。
架构的两个价值维度：行为和架构架构是行为的基础，不打好基础，系统就乱套了，最终难以维护
三种编程范式（目的是限制）：
1. 结构化编程（structured programming），限制了goto语句。
2. 面向对象编程（object-oriented programming），限制了函数指针。
3. 函数式编程（functional programming），限制了赋值语句。
关于测试的2点认知
1. 科学方法论不需要证明某条结论是正确的，只需要想办法证明它是错误的。如果某个结论经过一定的努力无法证伪，我们则认为它在当下是足够正确的。
2. Dijkstra曾经说过”测试只能展示Bug的存在，并不能证明不存在Bug”，换句话说，一段程序可以由一个测试来证明其错误性，但是却不能被证明是100%正确的。测试的作用是让我们得出某段程序已经足够实现当前目标这一结论。
锁与变量的关系
1. 所有的竞争问题、死锁问题、并发更新问题都是由可变变量导致的。如果变量永远不会被更改，那就不可能产生竞争或者并发更新问题。如果锁状态是不可变的，那就永远不会产生死锁问题。
2. 软件架构师应该着力于将大部分处理逻辑都归于不可变组件中，可变状态组件的逻辑应该越少越好。
关于软件设计的5个原则
1. 单一职责：函数和类必须在某一维度职责单一，只对某一类行为者负责。避免边界不清晰，后期维护困难
2. 开闭原则：对扩展开放，对修改关闭；对客户端修改关闭，对服务端修改开放
3. 里氏替换选择，父类出现的地方子类可以进行替换，提升代码复用性、扩展性；同时又增加了父子类的耦合性
4. 接口隔离原则：接口、类的职责要单一，低耦合
5. 依赖反转原则：要依赖抽象/接口，不依赖具体实现（代码注释要更贴近业务语言，避免出现具体实现相关的描述，简称通用语言）。
关于组件组件是软件在部署过程中的最小单元。设计良好的组件都应该永远保持可被独立部署的特性，也意味着这些组件应该可以被单独开发，对应在Java里就是jar文件。
关于组件聚合
1. 软件开发者必须要能够知道这些组件的发布时间，以及每次发布带来了哪些变更
2. 对大部分应用程序来说，可维护性的重要性要远远高于可复用性。
3. 这些变更最好都体现在同一个组件中，而不是分布于很多个组件中
4. 将由于相同原因而修改，并且需要同时修改的东西放在一起。将由于不同原因而修改，并且不同时修改的东西分开。
5. 这种平衡本身也在不断变化。也就是说，当下适用的分割方式可能明年就不再适用了。所以，组件的构成安排应随着项目重心的不同，以及研发性与复用性的不同而不断演化。
关于组件耦合
1. 第一种是”每周构建”，第二种是”无依赖环原则（ADP）“。
2. 我们可以打破这些组件中的循环依赖，并将其依赖图转化为DAG。目前有以下两种主要机制可以做到这件事情
  1. 应用依赖反转原则（DIP）
  2. 创建一个新的组件
3. 我们不希望那些频繁变更的组件影响到其他本来应该很稳定的组件
4. 组件依赖关系是必须要随着项目的逻辑设计一起扩张和演进的。
5. 任何一个我们预期会经常变更的组件都不应该被一个难于修改的组件所依赖，否则这个多变的组件也将会变得非常难以被修改。
6. 让软件组件难于修改的一个最直接的办法就是让很多其他组件依赖于它。带有许多入向依赖关系的组件是非常稳定的，因为它的任何变更都需要应用到所有依赖它的组件上。
关于软件架构
1. 软件架构等同于设计架构，即要设计出易于理解，易于修改，易于维护的的软件。最大限度的释放开发人员的维护人力，减少软件运营成本
2. 软件架构设计的主要目标是支撑软件系统的全生命周期，设计良好的架构可以让系统便于理解、易于修改、方便维护，并且能轻松部署。软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本。
3. 对于一个因架构设计糟糕而效率低下的系统，我们通常只需要增加更多的存储器与服务器，就能够让它圆满地完成任务。另外，硬件也远比人力要便宜，这也是软件架构对系统运行的影响远没有它对开发、部署、维护的影响那么深远的一个原因。
4. 设计良好的系统架构应该可以使开发人员对系统的运行过程一目了然
5. 在软件系统的所有方面中，维护所需的成本是最高的。满足永不停歇的新功能需求，以及修改层出不穷的系统缺陷这些工作将会占去绝大部分的人力资源。
6. 系统维护的主要成本集中在”探秘”和”风险”这两件事上。其中，“探秘（spelunking）“的成本主要来自我们对于现有软件系统的挖掘，目的是确定新增功能或被修复问题的最佳位置和最佳方式。而”风险（risk）“，则是指当我们进行上述修改时，总是有可能衍生出新的问题，这种可能性就是风险成本。
7. 优秀的架构师会小心地将软件的高层策略与其底层实现隔离开
8. 优秀的架构师所设计的策略应该允许系统尽可能地推迟与实现细节相关的决策，越晚做决策越好。
关于独立性我们一定要小心避免陷入对任何重复都要立即消除的应激反应模式中。一定要确保这些消除动作只针对那些真正意义上的重复。
划分边界
1. 软件架构设计本身就是一门划分边界的艺术。边界的作用是将软件分割成各种元素，以便约束边界两侧之间的依赖关系。
2. 简单来说，通过划清边界，我们可以推迟和延后一些细节性的决策，这最终会为我们节省大量的时间、避免大量的问题。这就是一个设计良好的架构所应该带来的助益。
3. 边界线应该画在那些不相关的事情中间。GUI与业务逻辑无关，所以两者之间应该有一条边界线。数据库与GUI无关，这两者之间也应该有一条边界线。数据库又与业务逻辑无关，所以两者之间也应该有一条边界线。
4. 这其实就是单一职责原则（SRP）的具体实现，SRP的作用就是告诉我们应该在哪里画边界线。
边界剖析所谓划分边界，就是指在这些模块之间建立这种针对变更的防火墙。
策略与层次低层组件被设计为依赖于高层组件。一条策略距离系统的输入/输出越远，它所属的层次就越高。而直接管理输入/输出的策略在系统中的层次是最低的。
业务逻辑业务逻辑就是程序中那些真正用于赚钱或省钱的业务逻辑与过程。选择直接在数据结构中使用对业务实体对象的引用。毕竟，业务实体与请求/响应模型之间有很多相同的数据。但请一定不要这样做！这两个对象存在的意义是非常、非常不一样的。随着时间的推移，这两个对象会以不同的原因、不同的速率发生变更。
关于框架使用框架要衡量成本和产出，框架是工具而不是生活信条
整洁架构所有跨边界的依赖线都是指向内的，这很好地遵守了架构的依赖关系规则
层次与边界过度的工程设计往往比工程设计不足还要糟糕。但另一方面，如果我们发现自己在某个位置确实需要设置一个架构边界，却又没有事先准备的时候，再添加边界所需要的成本和风险往往是很高的。
软件构建发展的3个过程：
1. “先让代码工作起来”——如果代码不能工作，就不能产生价值。
2. “然后再试图将它变好”——通过对代码进行重构，让我们自己和其他人更好地理解代码，并能按照需求不断地修改代码。
3. “最后再试着让它运行得更快”——按照性能提升的”需求”来重构代码。
分层架构的理念是基于接口编程的理念来设计的。当模块之间能以接口形式交互时，我们就可以将一个服务替换成另外一个服务
数据库是实现细节数据存储只是一个实现细节，所以架构方案不应局限于数据存储系统架构应该对磁盘本身的存在完全不关心。
Web是实现细节业务规则应该与UI解耦，做到可插拔式，便于扩展
应用程序框架是实现细节程序框架只是实现细节，架构尽量避免依赖框架如果选择了框架，就要做好准备在整个生命周期里适应它
依赖关系方向所有跨越边界的依赖关系都应该是同一个方向只有外部代码能依赖内部代码，反之则不能

langchain思考

Sat, 01 Jul 2023 22:00:00 GMT

精读 Out of the Tar Pi(上)

Sun, 04 Jun 2023 23:55:00 GMT

原文地址：http://curtclifton.net/papers/MoseleyMarks06a.pdf 共12个章节，讨论复杂度性对编程的影响，论文包含66页，分三篇文章进行精读

1 Introduction

复杂性是成功开发大规模软件系统的主要困难。我们遵循布鲁克斯的观点，区分偶然和本质上的困难，但不同意他的前提：当代系统中大部分剩余复杂性都是本质上的。我们确定了复杂性的常见原因，并讨论了可以采取的通用方法来消除它们（如果它们是偶然产生）。为了使事情更具体化，我们接着给出一个基于函数式编程和科德数据关系模型潜在最小化复杂度方法的概述。

“software ware 危机”最早在1968年被发现，而在接下来的几十年里，它变得更加深刻而非消退。开发和维护大型软件系统中最大的问题是复杂性——大型系统很难理解。我们认为，在许多系统中导致这种复杂性的主要因素是状态处理以及在尝试分析和推理系统时增加的负担。其他密切相关的因素包括代码量以及对整个系统控制流程明确关注。

应对状态困难的传统方法包括面向对象编程（将状态与相关行为紧密耦合）和函数式编程（在其纯粹形式中完全避免了状态和副作用）。当应用于传统大规模系统时，这些方法各自都存在不同且各异的问题。

我们认为，可以从两者中获得有用的想法，并与关系数据库世界的一些想法相结合，这种方法具有显着的潜力来简化大规模软件系统的构建。

这篇论文分为两个部分:

在第一部分中，我们专注于复杂性。在第2节中，我们从总体上看待复杂性，并证明了它是危机的根源，然后在第3节中探讨了我们当前如何试图理解系统。在第4节中，我们研究了复杂性的原因（即使我们难以理解的因素），然后在第5节中讨论了处理这些复杂性原因的经典方法。在第6节中，我们定义了“偶然”和“本质”，然后在第7节中提出了对应复杂性原因的替代方法建议——强调避免问题而不是应对问题。

在论文的后半部分，我们更详细地考虑了一种可能的方法，该方法遵循我们推荐的策略。我们从第8节对关系模型进行回顾，并在第9节概述了潜在的方法。在第10节中，我们简要示例了该方法的使用方式。最后，在第11节中，我们将我们的方法与其他方法进行对比，然后在第12节中给出结论。

2 Complexity

在他的经典论文《没有银弹》中，布鲁克斯（Brooks）[Bro86l] 确定了软件系统的四个属性，这使得构建软件变得困难：复杂性、一致性、可变性和不可见性。其中我们认为复杂性是唯一重要的一个——其他可以被归类为复杂形式，或者仅因系统中的复杂而成问题。复杂性是当今软件中绝大多数问题的根源。不可靠性、延迟交付、缺乏安全性，甚至在大型系统中的性能不佳，这些问题都可以追溯到难以管理的复杂性。复杂性作为这些问题的主要原因，是因为理解一个系统是避免所有这些问题的先决条件，而复杂性恰恰破坏了这一点。复杂性的相关性已得到广泛认可。正如 Dijkstra 所说 [Dij97，EWD1243]》

“如果我们拒绝被我们自己制造的复杂性所压垮，我们就必须保持它的简明性、解缰性和简单性…”。

经济学家还专门发表了一篇关于软件复杂性的文章 [Eco04]，指出据估计软件问题每年在美国经济中造成590亿美元的损失。

能够思考和推理我们的系统（尤其是对系统变化的影响）至关重要。复杂性的危险以及简单性的重要性在这方面也是 ACM 图灵奖演讲的热门话题。在他1990年的演讲中，科尔巴托（Corbato）说道 [Cor91]：

“对于雄心勃勃的系统而言，复杂性是一个普遍的问题。”，“…强调简单和优雅的价值是很重要的，因为复杂性会使问题变得更加复杂。”

一系列的名人佐证最后结论是这是一个不幸的事实: Simplicity is Hard

最后一个要点是，我们在本文中讨论的复杂性类型是使大型系统难以理解的类型。正是这种复杂性导致我们在创建和维护此类系统时耗费了巨大的资源。这种复杂性类型与复杂性理论无关，复杂性理论是计算机科学的一个分支，研究计算机在执行程序时消耗的资源。这两者是完全无关的——编写几行代码的小程序可以非常简单（按照我们的定义），但在复杂性理论上属于最高复杂性类别。从此以后，我们只讨论第一类复杂性。在讨论我们通常如何尝试理解系统之后，我们将查看我们认为是复杂性的主要共同原因（使理解困难的因素）。

3 Approaches to Understanding

前面我们论述了复杂性的危险来自于其对我们理解系统的影响。因此，考虑常用于尝试理解系统的机制是很有帮助的。然后，我们可以进一步考虑潜在的复杂性原因对这些方法的影响。目前有两种广泛使用的方法来理解系统（或系统组件）：

测试（Testing）是从外部尝试理解系统的方法，将系统看作是一个“黑盒子”。根据对系统在特定情况下的行为观察，得出对系统的结论。测试可以由人类或机器执行。前者在整个系统测试中更常见，后者在单独组件测试中更常见。
非正式推理（Informal Reasoning）是通过从内部检查系统来尝试理解系统的方法。希望通过使用可用的额外信息，获得更准确的理解。

在这两种方法中，非正式推理远远比测试更为重要。这是因为正如我们将在下文中看到的，测试存在固有的限制，而非正式推理（作为开发过程的固有部分）始终被使用。另一个理由是，非正式推理的改进将减少错误的产生，而测试的改进只能导致更多错误被检测出来。正如 Dijkstra 在他的图灵奖演讲中所说[Dij72，EWD340]：

那些想要真正可靠的软件的人会发现，他们必须从一开始就找到避免大多数 bug 的方法。

测试的关键问题是，使用一组特定输入进行的任何测试都无法告诉您系统或组件在给定不同输入时的行为。巨大数量的可能输入通常排除了对其进行全面测试的可能性，因此对测试的不可避免关注始终是是否执行了正确的测试？对这个问题，只能得到一个否定的答案。

一堆大佬话讲依靠测试是很危险的。

由于所有这些方法的局限性，简单性才是至关重要的。在投资于测试和投资于简单性之间，后者往往是更好的选择，因为它将促进未来所有理解该系统的尝试。

4 Causes of Complexity

在任何非常规的系统中，问题本身都有一些复杂性需要解决。然而，在真正的大型系统中，我们经常遇到一些复杂性，其作为“问题固有的一部分”的地位可能存在一些疑问。现在，我们考虑一些导致复杂性的原因。

Complexity caused by State

任何曾经给 IT 打过电话，并被告知“再试一次”、“重新加载文档”、“重启程序”、“重新启动计算机”或“重新安装程序”、甚至“重新安装操作系统，然后程序”的人，都直接经历过由于编写可靠、易懂的软件而导致的问题。

这些话之所以会让很多人感到熟悉，是因为它们经常被使用，而且通常能够成功解决问题。它们之所以能够通常成功解决问题的原因是，许多系统在处理状态时存在错误，这些错误存在的原因是状态的存在使得程序难以理解，状态使程序变得复杂。

又是一些引用来佐证上面结论

Impact of State on Testing

Brooks 所指出的状态对测试的影响的严重性难以过分强调。状态影响着所有类型的测试——从系统级测试（在这种测试中，测试人员将受到与刚刚提到的倒霉用户相同的问题的束缚）到组件级或单元测试。关键问题在于，在处于特定状态的系统或组件上进行的任何类型的测试都无法告诉您有关该系统或组件在另一个状态下的行为的任何信息。

测试有状态系统（无论是在组件级别还是系统级别）的常见方法是启动系统，使其处于某种“干净”或“初始”（虽然大部分是隐藏的）状态，使用测试输入执行所需的测试，然后依赖于（通常情况下是基于错误的假设）系统会无论其隐藏的内部状态如何，每次使用相同的输入运行测试时都会以相同的方式运行。

本质上，这种方法只是把状态问题掩盖起来。当测试一个具有复杂内部隐藏状态的有状态系统时，实际上没有其他选择。

当然，困难在于并非总是能够“逃脱”——如果某个事件序列（输入）可以导致系统“进入糟糕的状态”（具体而言，是与进行测试时不同的内部隐藏状态），那么问题可能会发生。这正是在本节开头讨论的假设性支持服务台呼叫者所面临的情况。提出的解决方法都是试图将系统强制恢复到“良好的内部状态”。

这个问题（即在一个状态下的测试对于处于不同状态的系统毫无意义）直接对应了上面讨论的测试的一个根本性问题之一——即针对一组输入进行测试对于具有不同输入集的行为毫无意义。事实上，由状态引起的问题通常更糟糕——特别是在测试系统的大块内容时——因为即使可能的输入数量非常大，系统可能处于的可能状态数量通常更大。

这两个类似的问题——一个是测试本质上固有的，另一个是由状态引起的——可怕地结合在一起。每个问题都引入了巨大的不确定性，如果所审查的系统/组件具有状态性质，那么我们几乎没有什么可以确定的东西。

Impact of State on Informal Reasoning

除了给从外部理解系统带来问题外，状态也妨碍了开发人员试图从内部推理（通常是基于非正式的方式）系统的预期行为。

用于进行这种非正式推理的心理过程通常围绕着一种逐案例的行为模拟：「如果这个变量处于这个状态，那么这将发生——这是正确的——否则那将发生——这也是正确的」。随着状态的数量增加，因此必须考虑的可能情景的数量增加，这种心理方法的有效性几乎与测试一样迅速地崩溃（它通过对一组相似值的抽象实现了某种优势，这些值可以被视为以相同方式处理）。

除了在外部理解系统时造成问题外，状态还妨碍了开发人员试图从内部推断系统的预期行为（通常是以非正式方式）。

用于进行这种非正式推理的心理过程通常围绕着对行为 case by case 的心理模拟：“如果这个变量处于这个状态，那么这将发生——这是正确的——否则那将发生——这也是正确的”。随着状态数量的增加，因此必须考虑的可能情景数量的增加，这种心理方法的有效性几乎与测试同样迅速崩溃（它通过抽象相似值的集合来获得一定的优势，可以看到它们被同样对待）。

其中一个问题(既影响测试又影响推理)是可能状态数目增长的解指数速率ーー对于我们加上的每一个状态位，我们将可能状态总数增加一倍。另一个问题是污染，这是非正式推理的一个特殊问题。

考虑一个由一些有状态的过程和一些无状态的过程组成的系统。我们已经讨论了理解有状态部分的困难，但我们希望那些没有状态的过程本身会更容易理解。然而，很遗憾，情况很大程度上并非如此。如果涉及的过程（本身是无状态的）使用了任何其他有状态的过程，即使是间接地，那么一切都会不确定，我们的过程会被污染，我们只能在状态的背景下理解它。如果我们尝试做其他事情，我们将再次面临以上讨论的所有经典与状态相关的问题的风险。正如前面所说，状态的问题在于“一旦让骆驼的鼻子进了帐篷，它的其他部分就会跟随”。

由于上述所有原因，我们相信在大多数当代大型系统中，复杂性的最主要原因仍然是状态，我们在限制和管理状态方面所做的越多，效果就会越好。

Complexity caused by Control

控制基本上是关于事物发生的顺序。控制的问题在于我们经常不想去关心这个问题。显然，考虑到我们想要构建一个真正会发生事情的系统，某个时刻顺序将对某人具有相关性，但是不必要地关注这个问题存在着重大风险。大多数传统的编程语言确实需要关注顺序——通常情况下，事物发生的顺序由编程语言的语句在程序的文本形式中的书写顺序来控制。然后，该顺序会通过显式的分支指令进行修改（可能附带条件），并且通常会提供子程序，这些子程序将在隐式堆栈中被调用。当然，有多种评估顺序可供选择，但在广泛使用的语言中几乎没有差异。

问题在于当控制是语言的隐含部分时（几乎总是如此），那么每个程序的片段都必须在这个上下文中理解 —— 即使（通常情况下）程序员可能希望在这方面不表达任何内容。当程序员被迫（通过使用具有隐式控制流的语言）指定控制流时，他们被迫指定系统应该如何工作的一个方面，而不仅仅是简单地说明期望的结果。实际上，他们被迫过度指定了问题。考虑下面的简单伪代码：在这种情况下，很明显程序员对于这些事情最终发生的顺序（即如何发生）没有任何关注。程序员只关心在某些值之间指定一种关系，但由于选择了任意的控制流程，他们被迫说得更多。通常在这种情况下，编译器会努力确立这样一个要求（顺序）可以被安全地忽略的事实，而这个要求是由于语言的语义而被程序员强制提出的。在像上面这样简单的情况下，往往很少考虑这个问题，但重要的是要意识到两件完全不必要的事情正在发生——首先是人为地强加了一个顺序，然后又进行了进一步的工作来消除它。

这个看似无关紧要的情况实际上会显著复杂化非正式推理的过程。这是因为阅读上面的代码的人必须有效地复制假设编译器的工作 —— 他们必须（根据语言语义的定义）从一个假设开始，即指定的顺序是重要的，然后通过进一步的检查确定它并不重要（在比上述情况不那么琐碎的情况下，确定这一点可能非常困难）。问题在于，对这种确定的错误可能导致引入非常微妙和难以发现的错误。

需要注意的是，问题不在上面程序的文字表达方式上 —— 毕竟，它必须按照某种顺序书写 —— 而完全在于我们假设的命令式语言的语义。可以将完全相同的程序文本视为在一个语义上不基于程序内文本顺序定义运行时顺序的语言中的有效程序。

在考虑了控制对非正式推理的影响后，我们现在来看看与控制相关的第二个问题，即并发，它也会影响测试。并发涉及基本的控制，如分支，但与顺序执行相反，大多数语言通常会显式地指定并发。最常见的模型是“共享状态并发”，其中提供了显式同步的规范。这对非正式推理的影响是众所周知的，困难之处在于随着阅读程序，必须进一步考虑的场景数量增加（在这方面，问题与上述状态问题相似，它也增加了需要进行心理考虑的场景数量）。

并发也影响测试，因为在这种情况下，即使我们以某种方式确保了一致的初始状态，在重复对系统进行测试时，也无法确保结果的一致性。在存在并发的情况下，以已知的初始状态和一组输入运行测试对于下一次以完全相同的输入和完全相同的初始状态运行相同的测试来说，并不能提供任何关于将会发生的信息…而事情确实无法变得更糟了。

Complexity caused by Code Volume

我们要详细考察的最后一个复杂性原因是庞大的代码量。

这个原因在很多方面基本上是一个次要效应——很多代码只是关注于状态管理或控制规范。因此，我们通常不会明确提到代码量。然而，它确实值得简要独立地关注，至少有两个原因——首先，因为它是最容易衡量的复杂性形式，其次，它与其他复杂性原因产生不良的互动，这是需要考虑的重要因素。

布鲁克斯（Brooks）在《人月神话》（Bro86）中指出：

“开发软件产品中的许多经典问题都源于这种固有复杂性以及它与规模的非线性增加。”

基本上，我们同意在大多数现有系统中，这是正确的（我们对“固有”一词持有异议，正如之前提到的 —— 即在大多数系统中，复杂性确实随着代码规模的增加呈非线性增长）。而这种非线性增长意味着将代码量减少到绝对最低限度至关重要。

我们还想提请大家注意 Dijkstra’s 关于这个问题的一个想法:

有人提出过一种自然法则，声称所需的智力努力量与程序长度的平方成正比。但是，谢天谢地，没有人能够证明这个法则。这是因为这个法则未必是真实的……我倾向于这样的假设——迄今为止，经验未能反驳——通过适当地运用我们的抽象能力，构思或理解一个程序所需的心智相比程序长度不会增长得更多。

我们同意这一观点，这也是我们在上面提到的。我们相信，通过有效地管理我们讨论过的两个主要复杂性原因，即状态和控制，复杂性随着代码量的增加以非线性方式增长的问题变得不那么明显。

Other causes of complexity

最后还有其他原因，例如: 重复的代码、从未实际使用过的代码(“死代码”)、不必要的抽象、没有抽象、模块性差、缺少文档…

所有这些其他原因都可归结为以下三个相互关联的原则：

复杂性滋生复杂性。复杂性的次级原因有很多。这涵盖了所有由于无法清楚地理解系统而引入的复杂性。重复是一个典型的例子 —— 如果（由于状态、控制或代码量）不清楚功能是否已经存在，或者很难判断已经存在的功能是否完全符合要求，就会倾向于重复。尤其是在时间紧迫的情况下，这一点尤为真实。
简单是困难的。这一点在前面已经提到过 —— 要实现简单可能需要付出相当大的努力。第一个解决方案往往不是最简单的，特别是如果存在现有的复杂性或时间压力。只有在认识到简单的重要性、追求简单并珍视简单时，才能达到简单。
权力导致滥用。我们所说的是，在没有语言强制保证（即对语言的能力进行限制）的情况下，错误（和滥用）就会发生。这就是为什么垃圾回收是好的 —— 它消除了手动内存管理的能力。同样的原则适用于状态 —— 另一种权力。在这种情况下，意味着我们需要非常警惕任何允许状态存在的语言，无论它对状态的使用有多么的限制（明显的例子是 MI 和 Scheme）。底线是，语言越强大（即在语言内实现的功能越多），理解构建在其中的系统就越困难。

其中一些原因是由人性导致的，其他原因则是由环境问题造成的，但我们相信，通过专注于对第4.1-4.3节中讨论的复杂性原因进行有效管理，可以大大减轻这些问题。

longChain 学习

Fri, 31 Mar 2023 21:50:00 GMT

最近了解 Open AI 的过程中发现这个框架，把中文文档整理如下

LangChain 是一个使用语言模型驱动应用程序开发的框架。最强大、最具差异化的应用程序不仅仅通过 API 调用语言模型，还将具备以下特点：

数据感知：将语言模型与其他数据源连接起来。
自主性：允许语言模型与其环境进行交互。

该框架旨在遵循上述原则。本文档的重点是针对 Python 的部分。如需了解关于 LangChain 的纯概念指南，请参见此处。如需 JavaScript 文档，请参见此处。 LangChain 框架提供了两个主要价值：

组件：LangChain 提供了模块化的抽象组件，用于与语言模型配合使用。LangChain 还提供了这些抽象的所有实现集合。这些组件旨在易于使用，无论您是否使用 LangChain 框架的其余部分都是如此
特定用例的链：链可以被视为以特定方式组装这些组件，以最好地完成特定用例。这些旨在成为通过它们，人们可以轻松地开始使用特定用例的更高级别的接口。这些链也被设计为可自定义的。

因此，我们将以下文档分为这两个主要价值。在本文档中，我们以高层次和与语言无关的方式概述组件和用例。有关使用这些组件和解决这些用例的特定语言方法，请参见页面顶部链接的特定语言部分。

Components

Schema：

Text：在使用语言模型时，与其互动的主要接口是文本。简单来说，许多模型是“输入文本，输出文本”。因此，LangChain 中的许多接口都是以文本为中心。
ChatMessages：最主要的用户接口是通过聊天界面进行互动。因此，一些模型提供者甚至开始以期望聊天消息的方式提供对底层 API 的访问。这些消息具有内容字段（通常是文本），并与用户相关联。目前支持的用户包括系统、人类和人工智能。
- SystemChatMessage：一条聊天消息，代表应该传达给人工智能系统的指令信息。
- HumanChatMessage：一条聊天消息，代表与人工智能系统互动时来自人类用户的信息。
- AIChatMessage：一条聊天消息，代表来自人工智能系统的信息。
Examples：示例是代表函数的输入和期望输出的输入/输出对。它们可以用于模型的训练和评估。这些示例可以是模型或链的输入/输出。两种类型的示例具有不同的用途。用于模型的示例可用于精细调节模型。用于链的示例可用于评估端到端链路，甚至可以训练模型以代替整个链路。
Document：一段非结构化数据，包括 page_content（数据内容）和 metadata（描述数据属性的辅助信息）

Models

本文档部分涉及LangChain中使用的不同类型模型。在本页面，我们将概述各种模型类型，但对于每种模型类型我们都有单独的页面。

LLMs

大型语言模型（LLMs）是我们介绍的第一种类型的模型。这些模型以文本字符串作为输入，并返回文本字符串作为输出。

聊天模型

聊天模型是我们介绍的第二种类型的模型。这些模型通常由语言模型支持，但它们的API更加结构化。具体而言，这些模型以聊天消息列表作为输入，并返回聊天消息。

文本 Embedding # Model

以文本为输入，并返回浮点数列表（向量）

Prompts

新的模型编程方式是通过提示（Prompts）的方式。“Prompt”是指模型输入，这个输入很少被硬编码，通常由多个组件组成。PromptTemplate负责构建此输入。LangChain提供了多个类和函数，使得构建和使用prompt变得容易。本文档分为四个部分：

Prompt Value：代表模型输入的类。
Prompt Templates：负责构建PromptValue的类。
Example Selectors：通常在提示中包含示例是很有用的。这些示例可以硬编码，但如果它们是动态选择的，则通常更加强大。
Output Parsers：语言模型（和聊天模型）输出文本。但是很多时候，您可能希望获得比纯文本更结构化的信息。这就是输出解析器发挥作用的地方。输出解析器负责
- （1）指示模型如何格式化输出
- （2）将输出解析为所需的格式（包括必要时进行重试）

Prompt Value

“提示”是指传递给底层模型的内容。LangChain中主要的抽象都是针对文本数据的提示。对于其他类型的数据（如图像、音频），我们正在努力添加抽象，但目前还没有实现。不同的模型可能需要不同的数据格式。如果可能的话，我们希望允许在不同的模型类型中使用相同的提示。因此，我们有一个PromptValue的概念。这是一个类，它公开了一些方法，用于将提示值转换为每个模型类型所期望的精确输入类型（目前为文本或聊天消息）。

Prompt Templates

Prompt Value是最终传递给模型的内容。大多数情况下，这个值不是硬编码的，而是根据用户输入、其他非静态信息（通常来自多个来源）和固定的模板字符串动态创建的。我们称负责创建Prompt Value的对象为Prompt Template。这个对象公开了一个方法，用于接收输入变量并返回PromptValue。

Example Selectors

在提示中包含prompt examples通常是很有用的。这些示例可以是硬编码的，但如果它们是动态选择的，通常会更有用。Example Selectors是接收用户输入并返回要使用的示例列表的对象

Output Parser

Output parser 是帮助构建语言模型响应结构的类。Output parser必须实现两个主要方法：

get_format_instructions() -> str：返回一个包含有关如何格式化语言模型输出的字符串的方法。
parse(str) -> Any：接受一个字符串（假定为语言模型的响应），并将其解析成某些结构的方法。

还有一个可选的方法： parse_with_prompt(str) -> Any：接受一个字符串（假定为语言模型的响应）和提示语（假定生成此响应的提示语），并将其解析成某些结构的方法。提示语通常在输出解析器想要重新尝试或以某种方式修复输出时提供，需要从提示语中获取信息来进行操作

Indexes

Indexes 是指对文档进行结构化处理，以便 LLMs 能够最好地与它们交互的方式。该模块包含用于处理文档、不同类型的索引的实用函数，以及在链中使用这些索引的示例。 indexes在链中最常见的用法是在“retrieval”步骤中。这一步骤指的是将用户的查询与最相关的文档匹配。我们之所以提出这个区别是因为

(1) indexe可以用于除retrieval以外的其他目的
(2) retrieval可以使用除index以外的其他逻辑来查找相关文档。因此我们有一个“Retriever”接口的概念，这是大多数链所使用的接口。

当我们谈论索引和检索时，大多数情况下我们是在谈论索引和检索非结构化数据(例如文本文档)的情况。对于与结构化数据(SQL 表等)或 API 交互，请参见相应的用例部分，以获取相关功能的链接。LangChain 支持的主要索引和检索类型目前集中在向量数据库上，因此我们在这些主题上深入探讨了很多功能。

Document Loaders

文档加载器负责加载文档对象列表。

Text Splitters

通常，您希望将大型文本文档分割成较小的块，以便更好地使用语言模型。TextSplitter 负责将文档分割成更小的文档。

Retriever

一种存储数据的方法，以便可以通过语言模型进行查询。此对象必须公开的惟一接口是get_relevant_texts方法，该方法接受字符串并返回 Document 列表。

Vectorstore

最常见的索引类型是创建每个文档的数值嵌入numerical embeddings（使用嵌入模型Embedding Model）。向量存储器存储文档及其相关的嵌入，并提供通过嵌入查找相关文档的快速方法。

Memory

Memory是在对话过程中存储和检索数据的概念。主要有两种方法：

基于输入，获取任何相关的数据
基于输入和输出，相应地更新状态

记忆主要分为短期和长期两种类型。短期记忆通常指如何在单个对话的上下文中传递数据（通常是前面的聊天消息或其摘要）。长期记忆涉及如何在对话之间获取和更新信息。

Chat Message History

当前与语言模型的主要接口是通过聊天接口实现的。ChatMessageHistory 类负责记住所有以前的聊天交互。然后可以将其直接传递回模型中，以某种方式进行总结，或进行某些组合。 ChatMessageHistory 公开了两种方法和一个属性。它公开的两个方法是 add_user_message 和 add_ai_message，用于相应地存储来自用户的消息和来自 AI 的响应。它公开的属性是 messages 属性，用于访问所有以前的消息。

Chains

Chains是一个非常通用的概念，它返回一个由模块化组件（或其他链）按特定方式组合而成，以完成常见用例。最常用的链类型是LLMChain，它将PromptTemplate、Model和Guardrails组合在一起，以获取用户输入，相应地进行格式化，将其传递给模型并获得响应，然后验证并修复（如果需要）模型输出。

Chain

链只是围绕多个单独Component的端到端包装器

LLMChain

一个 LLMChain 是最常用的链式结构。它由 PromptTemplate、模型（LLM或ChatModel）和可选的输出解析器组成。这个链式结构接受多个输入变量，使用 PromptTemplate 将它们格式化成一个提示，然后将它传递给模型。最后，如果提供了 OutputParser，则使用它将LLM的输出解析成最终格式。

这类链用于与索引交互。其目的是将您自己的数据（存储在索引中）与LLMs结合使用。其中最好的例子是在自己的文档上进行问答。其中很重要的一部分是了解如何将多个文档传递给语言模型。有几种不同的方法或链，可以实现这一点。LangChain支持其中四种比较常见的方法，我们正在积极寻求更多的方法，如果您有任何想法，请联系我们！请注意，并没有一种最好的方法——选择使用哪种方法通常非常具体于上下文。

Stuffing

Stuffing是最简单的方法，你只需要将所有相关的数据作为上下文填充到prompt中，然后传递给语言模型。在LangChain中，这是通过StuffDocumentsChain来实现的。优点：只需要对LLM进行一次调用。在生成文本时，LLM可以同时访问所有数据。缺点：大多数LLM都有上下文长度限制，对于大型文档（或多个文档），这种方法将无法正常工作，因为它会导致一个大于上下文长度的prompt。这种方法的主要缺点是，它只适用于较小的数据。一旦你处理大量的数据，这种方法就不再可行。接下来的两种方法旨在帮助解决这个问题。

Map Reduce

这种方法涉及对每个数据块运行初始提示（对于摘要任务，这可以是该块的摘要；对于问答任务，它可以是仅基于该块的答案）。然后运行一个不同的提示来组合所有初始输出。这在LangChain中实现为MapReduceDocumentsChain。优点：可以扩展到比StuffDocumentsChain更大的文档（和更多文档）。对单个文档进行的LLM调用是独立的，因此可以并行化。缺点：需要比StuffDocumentsChain更多的LLM调用。在最终的组合调用中会丢失一些信息。

Refine

这种方法是在第一个数据块上运行初始提示，生成一些输出。对于剩余的文档，将该输出与下一个文档一起传递，要求LLM基于新文档对输出进行细化。优点：可以引入更相关的上下文，并且可能比MapReduceDocumentsChain损失更少。缺点：需要比StuffDocumentsChain更多的LLM调用。这些调用也不是独立的，意味着它们不能像MapReduceDocumentsChain一样并行执行。还可能存在一些依赖于文档顺序的潜在依赖关系。

Map-Rerank

这种方法涉及在每个数据块上运行一个初始提示，不仅试图完成任务，而且还会给出它回答的可信度分数。然后根据这个分数对响应进行排名，并返回最高分数的响应。优点：与MapReduceDocumentsChain类似的优点。与MapReduceDocumentsChain相比，需要更少的调用。缺点：无法在文档之间合并信息。这意味着它在您预计单个文档中有一个简单答案时最有用。

Prompt Selector

LangChain 中链的一个目标是尽快让用户开始使用特定的用例，其中一个重要的部分是有一个好的prompts。问题在于，一个适用于一个模型的prompt可能对于另一个模型不太适用。我们希望让链在所有类型的模型上都能够很好地工作。因此，我们没有在链中硬编码默认提示信息，而是引入了 PromptSelector 的概念。这个 PromptSelector 负责根据传入的模型选择一个默认提示信息。 PromptSelectors 最常见的用例是为 LLMs 和 Chat Models 设置不同的默认提示信息。但是，如果需要，也可以用它来为不同的模型提供商设置不同的默认提示信息。

Agents

有些应用程序不仅需要预先确定的对LLMs/其他工具的调用链，还可能需要依赖于用户输入的未知链。在这些类型的链中，有一个“Agent”，该Agent可以访问一套工具。根据用户输入，Agent可以决定是否调用其中的任何一个工具。我们将Document分为以下几个部分：

Tools：语言模型与其他资源的交互方式：一个特定的抽象概念，用于使语言模型与其交互变得容易。具体来说，一个工具的接口具有一个文本输入和一个文本输出。
Agents：驱动决策的语言模型：代理是模型的封装，它接收用户输入并返回相应的“动作”以及相应的“动作输入”。
Toolkits：一组工具，当它们一起使用时可以完成特定的任务。
Agent Executor：运行代理与工具的逻辑：Agent Executor 是一个 Agent 和一组Tools。Agent Executor 负责调用 Agent，得到对应的“行动”和“行动输入”，使用行动指示的工具和相应的输入调用该工具，得到工具的输出，然后将所有这些信息传递回 Agent，以获取它应该采取的下一个行动。

Use Cases

本节重点介绍 LangChain 可以帮助解决的不同端到端用例。对于每个用例，我们不仅激发了用例，而且还讨论了哪些组件对于解决该用例最有帮助。

Personal Assistants

个人助理是LangChain的两个核心价值主张（动作执行和个性化数据）的完美应用。为了构建个人助理，您应该了解以下概念： PromptTemplate-这将指导您的个人助理的行为。它们是俏皮还是有帮助的？这些可以用来给您的个人助理一些个性。 Memory-您的个人助理应该记住某些事情。他们肯定应该能够进行交谈（短期记忆），并且他们可能还需要一些长期记忆的概念。 Tools-通过给它提供工具，您的个人助理将会与众不同。它应该知道如何做什么？ Agent-您的个人助理将不得不理解它应该采取哪些行动。构建最佳代理人将是重要的。 Agent Executor-在您拥有工具和代理人之后，为了将其付诸实践，您需要设置一个代理人使用这些工具的环境。这就是代理人执行者发挥作用的地方。

Question Answering Over Documents

LLMs虽然功能强大，但它们并不知道它们没有接受过培训的信息。如果您想使用LLM回答与其未接受培训的文档有关的问题，则必须向其提供有关这些文档的信息。最常见的方法是通过“检索增强生成”。

检索增强生成的思想是，当提出问题时，首先进行检索步骤以获取任何相关文档。然后将这些文档与原始问题一起传递给语言模型，并让它生成响应。但是，为了做到这一点，您首先必须以可查询的方式将文档格式化。本页面概述了这两个步骤的高级想法：（1）将文档导入可查询格式，然后（2）检索增强生成链。

导入

为了使用语言模型与您的数据进行交互，您首先必须将其转换为适当的格式。该格式将是索引。将数据放入索引中可使任何下游步骤轻松地与之交互。有几种类型的索引，但迄今为止最常见的是向量存储。将文档导入向量存储可以通过以下步骤完成：

加载文档（使用Document Loader）
分割文档（使用Text Splitter）
为文档创建嵌入（使用Text Embedding Model）
将文档和嵌入存储在向量存储中

生成现在我们有了索引，如何使用它来生成响应呢？这可以分解为以下步骤：

接收用户问题
在索引中查找与问题相关的文档
使用PromptTemplate从问题和任何相关文档构造PromptValue。
将PromptValue传递给模型
获取结果并返回给用户。

Chatbots

ChatGPT通过提供一个新的界面——聊天界面，将一个强大的语言模型引入了世界。构建聊天机器人需要几个组件。

模型 - 你可以从普通的语言模型或者Chat Model构建一个聊天机器人。重要的是要记住，即使你使用的是Chat Model，API本身也是无状态的，这意味着它不会记住以前的交互 - 你必须传递它们
PromptTemplate - 这将指导您的聊天机器人如何表现。他们是率真的还是乐于助人的？这些可以用来赋予您的聊天机器人一些个性
Memory - 如上所述，模型本身是无状态的。Memory带来了某种状态的概念，使它可以记住以前的交互。

聊天机器人通常与其他数据源结合使用时会更加强大和具有差异化。与“文档问答”背后的技术相同，也可以用于此处，以便让聊天机器人可以访问这些数据。

Querying Tabular Data

大量的数据和信息以表格形式存储，无论是CSV、Excel表格还是SQL表。本页面介绍了LangChain可用于处理此类数据的所有资源。

文档加载

如果您有以表格形式存储的文本数据，可能希望将数据加载到文档中，然后像处理其他文本/非结构化数据一样进行索引。为此，应使用CSVLoader等文档加载程序，然后创建一个索引来查询数据。

查询

如果您有更多的数字表格数据，或者有大量数据并且不想对其进行索引，您也可以直接使用语言模型与其交互。

Chains

如果您刚开始使用，且拥有相对较小/简单的表格数据，则应从链开始。链是一系列预定步骤，因此它们很适合入门，因为它们给予您更多控制权，让您更好地理解正在发生的情况。

Agents

代理更为复杂，涉及多次查询LMM以了解要执行的操作。代理的缺点是您的控制权更少。优点是它们更强大，使您能够在更大的数据库和更复杂的模式上使用它们。

Interacting with APIs

APIs的强大之处在于它们既可以通过它们执行操作，还可以通过它们查询数据。本页面介绍LangChain中可用于处理API的所有资源。

Chains

如果您刚开始使用，且您有一个相对较小/简单的API，则应该从链开始。链是一系列预定步骤，因此它们很适合入门，因为它们给予您更多的控制，并让您更好地了解发生的情况。

Agents

代理更为复杂，涉及多次查询LMM以了解要执行的操作。优点是它们更加强大，可以在更大或更复杂的API上使用。

Extraction

语言模型实际上非常擅长从非结构化文本中提取结构化信息。这很有用，因为许多信息以文本形式存储，但为了使其在下游使用起来更加方便，通常需要将其转换为结构化格式。在这里最有用的概念是“OutputParsers”（输出解析器）。OutputParser 负责指定语言模型应该响应的模式，然后将其原始文本输出解析为该结构化格式。。使用它们进行提取的方法是定义要在 OutputParser 中提取的信息的模式。然后，您将创建一个接收原始文本 blob 的 PromptTemplate，其中包含以指定格式提取信息的说明。

Evaluation

LangChain评估部分的文档涵盖了我们在LangChain中如何处理和思考评估的方法。这包括对内部chains/agents进行评估的方法，以及我们建议在LangChain上构建的人如何进行评估的方法。

问题评估LangChain chains/agents可能会很困难。这主要有两个原因：

1：缺乏数据

在开始一个项目之前，通常你没有太多的数据可以评估你的chains/agents。这通常是因为大型语言模型（大多数chains/agents的核心）是非常好的few-shot和zero-shot学习者，这意味着你几乎总是能够开始执行特定的任务（文本到SQL、问答等），而不需要大量的样本数据。这与传统的机器学习形成了鲜明的对比，在传统机器学习中，你必须先收集一堆数据点，然后才能开始使用模型。

2：缺乏指标

大多数chains/agents执行的任务没有很好的指标来评估性能。例如，最常见的用例之一是生成某种形式的文本。评估生成的文本要比评估分类预测或数值预测复杂得多。解决方案 LangChain试图解决这两个问题。目前我们的解决方案是初步的，我们认为还没有完美的解决方案。因此，我们非常欢迎反馈、贡献、集成和关于此的想法。

对于每个问题，我们目前的解决方案如下：

1：缺乏数据

我们已经开始使用Hugging Face社区空间中的LangChainDatasets收集开源数据集，用于评估常见的chains和agents。我们已经为此贡献了五个数据集，但我们高度希望这是一个社区的努力。要贡献数据集，你只需加入社区，然后你就可以上传数据集。我们还致力于让人们尽可能容易地创建自己的数据集。作为第一步，我们添加了一个 QAGenerationChain，它为文档提供了问答对，这些问答对可以用来评估文档中的问答任务。

2：缺乏指标

我们有两个解决方案来解决缺乏指标的问题。第一种解决方案是不使用度量，而是仅仅依靠肉眼观察结果来了解链条/代理的表现。为了帮助解决这个问题，我们已经开发了(并将继续开发)跟踪，一个基于 UI 的链和代理运行的可视化工具。我们推荐的第二种解决方案是使用语言模型本身来评估输出。为此，我们有一些不同的链条和提示，旨在解决这一问题。

Summarization

一个常见的应用场景是想要对长文档进行摘要。这自然而然地遇到了上下文窗口的限制。与问答不同的是，你不能仅仅通过一些语义搜索技巧选择最相关的文本块（因为在这种情况下，没有特定的问题 - 你想要总结所有内容）。那么你该怎么办呢？

最常见的方法是将文档分成块，然后以递归的方式进行摘要。这意味着你首先单独总结每个块，然后将摘要分组成块，并总结每个摘要块，直到只剩下一个。

MBTI学习与理解

Thu, 02 Jun 2022 23:00:00 GMT

总览公式

MBTI = 4个我更偏向怎样做选择的问题

每一个维度，本质上都在回答一句话

能量从哪里来
信息怎么进脑，怎么观察世界
决策靠什么
生活怎么安排

四维度分析

E / I 能量的来源

Extraversion / Introversion

获取能量是靠外界还是靠自己，本质是精力的恢复或者获取的方式

E人，和人互动说出来才想清楚
I人，独处，想清楚再说

误区

外向 ≠ 爱说话
内向 ≠ 社恐

S / N 信息获取的方式

Sensing / Intuition

更相信看到的还是想到的，S是现实世界，N是概念世界

S 实感：相信事实、细节、当下、经验
N 直觉：相信抽象，模式，未来，可能性

快速区分

S常问：具体怎么做？
N常问：这意味着什么？

T / F 决策依据

Thinking / Feeling

做决定时，我优先考虑什么？这是决策权重，T = 对不对 | F = 好不好受

T 思考：逻辑、原则、对不对
F 情感：感受、关系、合不合适

误区

F ≠ 情绪化
T ≠ 冷血

J / P 对待生活的态度

Judging / Perceiving

我更需要确定，还是弹性

J 判断：计划，掌控，先定下来
P 知觉：灵活、探索、看情况

例子

J：出去玩定好计划
P：到了再说

TS实现基于字节码的JS 虚拟机

Thu, 12 May 2022 22:00:00 GMT

再之前我们实现了一套基于 jsvm2 的

如何给予有效的反馈意见

Tue, 02 Nov 2021 22:00:00 GMT

步骤

确认给予反馈意见的必需性。这一问题会影响工作吗？会对工作关系造成不利影响吗？如果答案是否定的，暂时无需提供反馈意见。
在给出反馈意见前，需做好准备工作。收集近期这一问题的详细例子。注意需针对行为或者结果。
想好什么是你想要得到的结果。做好提供纠正错误的反馈信息，或者进行指导的准备。
在私下给予反馈意见。
如果你想要某一特定行动或者结果，需表达清楚。
确定你将如何跟进这项工作。

准则

要详细具体。没有人能够按照线索或者模糊的反馈意见行事。如果你告诉某人“这份报告非常出色”，这句话可以表达你的赞许，但对方并不知道报告出色的地方在哪里。
在事件发生后，第一时间给出反馈意见。等到年终考核才给出反馈意见起不到任何作用。即使等到季度考核，也是无济于事。
不要针对人进行反馈，应描述某一行为或者结果。不要说“你在工作中非常粗心”，可以说“我发现在最后一组产品的交付记录中有很多打印和拼写错误”。
不要责怪员工，说话不要太绝对。不要说“你从来都不测试你的编码”，可以说“你在检查最后三处改变时没有对这些改变进行测试”。
倾听对方的意见。要确定对方同意你的描述，认为它是正确的。
保留所有反馈谈话的记录。要保留所有与工作表现相关的谈话的非正式笔记，比如，保留所有你与员工进行的一对一谈话笔记。如果等到问题严重了，你才开始做文字性的报告，那么对方很可能会声称受到了不公的指责。所以，应该将你为改善状况付出的持续努力记录下来。

如何分析问题

Fri, 01 Oct 2021 22:00:00 GMT

美团的汇报文档一般有以下几部分组成

背景(现状)
分析
问题
目标
解决方案
预计结果

这一个很结构化的汇报方式，可以帮助大家更聚焦，减少沟通损耗，不过通常情况下大家只能拿到海量的背景和现状，但是没办法进一步分析并提炼出问题，所以有人说好的问题就提供了一半的解决方案。美团四大名著之一的《金字塔原理》其实就是在尝试帮助大家解决这个问题，不过这本书写的太啰嗦了，作者的同事也在批评说她在水字数赚稿费[😄]，其实金字塔原理最核心的两个东西就是：MECE法则和SCQA结构。

MECE法则

金字塔原理的本质就是提倡一种结构化的思考方式和习惯，核心就是从上到下逐层展开，从下到上逐层支撑，具体做法就是不重不漏(穷举)。

这里可以看MECE/金字塔原理

SCQA结构

这个就是如何结构化表达，就是上面提到的美团汇报风格的几部分，原始的结构化表达如下：

S：情景
C：冲突
Q：问题
A：答案

所以其实很明显SCQA是考验写作基本功的，核心还是在MECE上，但是MECE并不是一个很容易理解和操作的东西，针对研发领域我有一些具体的操作方式：

首先明确一个问题解决方案链：大问题 <-> 方案 <-> 小问题 <-> 方案 <-> 更小的问题

**从上到下逐层展开：**每个大的问题都会有一系列的方案，每个方案都会产生更多的小问题
**从下到上逐层支撑：**每个小问题都是一个更大问题的解决方案的一部分

这样做的好处能帮助我们加深思考的深度，也就是对某个问题，看得更具体。

思考框架

在已有的**问题解决方案链(因果链)**上找一个合适的层级(切入点)
评估现状为什么我们认为它不够好
找到衡量“好的”指标，并用它说明为什么这是一个值得解决的问题
穷举已知问题的拆解方案，通过指标衡量一个最合适的视角
在这个最合适的视角下展开具体的解决方案

误区：

不要把所有问题都当成问题，明确问题是 why how what 具体哪个层面的，一般来讲要从why的角度作为最大的问题做分解拆分
明确什么是现象什么是问题，不要搞混
区分好什么是手段什么是目的，不能混淆

工具

结构化框架的最好表达方式就是思维导图：

推荐：gitmind https://gitmind.cn/ PC Web 移动端都有就是不确定以后是否收费
web版可以使用我参与开发的https://naotu.baidu.com/home
pc版可以用xmind(收费)

如何设计一个大型小程序

Thu, 06 May 2021 21:33:30 GMT

过去三年里，我的全部精力都用在了小程序研发上面，先后完成了大概20多个小程序，目前最大规模的有两个电商类的小程序，都有很大规模的研发团队在协作开发。我们做的很多前端项目主要还是在性能，质量，效率三者上做一定的协调。如果有多端同构的诉求我们更希望有一个开发框架来屏蔽容器上的一些差异。首先针对性能，这里的性能好坏并不是狭义上的一些性能指标数据，而是一种类似体感的指标。比如一个基于raf的方案去计算FPS就算指标上没问题，但是实际用户使用的时候还是会卡顿，这和小程序双进程架构有关；比如FMP的指标是和用户感觉上的首屏是不一样的，我们使用了类似LVC的指标。通过一系列的指标约束，我们可以对很多方案做和横向的对齐，实际实践了三种不同的方案，原生小程序的就不谈，还有类似taro的编译时方案，类似remax的运行时方案。在这个过程中很明显就能感受到性能P，质量Q，效率E 三者基本上如同 CAP理论一样不能同时都满足。

前两年主要精力都在交付效率上，业务毕竟是一个探索期的业务，团队规模也不是很大，但是要尝试的东西很多，所以希望有一套移动端架构方案可以跨端来支撑整个业务发展，这个过程中，我们摸索出了类似现在remax的一套方案，跨端设计上和taro比较接近，但是整体实现方案和remax很像，都是使用了 react-reconciler 实现了一个小程序端的渲染器。所以基本上支持所有react的能力，不受限。同时又很好的能支持H5。这个就是我们第一代的跨端框架雏形，很好的解决了我们交付效率的问题，但是业务变化开始主打下沉的市场，这时候遇到了很大的问题，下沉市场的手机非常非常差，网络情况也不好，导致很多在中高端手机上能接受的体验完全被击穿。在系统层面又降回到了ios9和android4，这导致很多高级的能力不可用，同时小程序包体积的限制polyfill也不可用，同时低版本的系统限制了小程序基础库版本，我们要兼容到2.0.0，基本上就限制住了一些高级框架能力。

大规模协作还会带来高频冲突的问题，如果没有合适的方式来隔离每个人的更改，按照小程序原生的 index.js、index.wxml、index.wxss 这种模式就很难很好的做好。

并发请求

Fri, 01 Jan 2021 22:00:00 GMT

系统可维护到底指的是什么

Fri, 01 Jan 2021 22:00:00 GMT

在美团一些大型业务开发中，经常会出现大家觉得系统维护不下去了，一个反复被提及的词就是代码复杂度高。但是后台业务确很少有类似的声音，其实后台业务的复杂度也不低，但是为什么会有类似的情况发生呢，其实我认为对是否可维护不完全是客观的，比如考虑以下几个 case

有人接手前人的项目后，会觉得可维护性差，然后进行重构工作，但是在上一任维护人上并没有类似的想法
很多人会说 react 项目太复杂，不好开发维护，但是 react core team 的人没觉得不好维护
架构师走了之后，团队成员换了一批会觉得之前的东西很难维护
业务支持多个业态，或者业务干脆换了一个方向，各种原因下系统还是局部复用的，整个系统会让人感觉不可维护

可维护性和什么有关

我将上面提到的情况大致的划分成了下面的表格的四个维度(链接为我对应的具体的思考)：

客观情况	人相关
业务复杂度：《🐣系统中复杂度体现在哪些方面》《🐣为什么复杂的业务不好做》	技能：拥有一定深度和广度《✅如何看待技术深度与广度》
代码与架构：《🐣如何做好前端架构》	熟悉程度：(时间 +意愿)*理解力/频次

在这四个维度中，业务复杂度是无法改变的，对项目熟悉程度也需要精力(时间+意愿)，所以回到优选项目我们说它难以维护的原因可以如下分析：

熟悉程度低：为了赶排期，经常协调人协助开发一些本来不是他负责的业务功能，导致大家对项目平均熟悉度都偏低
架构不合理：过去每周2大迭代+3迭代，同时排查很多线上问题导致大家没精力进行周全的技术设计
业务复杂度：团长，用户，新人，老客，促销，活动等等聚集到一起业务case相对复杂
技能：低职级的同学主力开发，KP精力更多在排查线上问题，高职级的事务性工作多，导致项目技能平均投入偏低

整体形成了如下图红色部分的负向循环:

如何提高可维护性

(1) 业务复杂度

业务变复杂是技术没办法解决的，是客观的商业行为导致的。业务本身越复杂，所包含的信息量就会越大，复杂度就会很高，而系统架构设计是无法消除业务整体复杂度的，它只能让复杂度可以被拆分，让团队不同的人可以面对一个被切分后的相对可控的业务难度，但架构师(系统主R)还需要将所有被切分的信息聚合起来，这些工程方法客观上降低了人类理解复杂度，但实际增加了系统实体复杂度。不过降低理解复杂度可以客观提高系统可维护性，所以我们还是要对业务有一个很好的认识从而进行对应的代码与架构的设计。

(2) 代码与架构

2.1. 如何做好架构

首先要明确的一点是不要在开发过程中教条的应用一些设计模式和架构模型，所有的架构都是为了合理的将业务抽象成对应的技术实现，抽象好的表现是适应度函数的曲线比较贴合业务真实复杂度，抽象的不好，一个简单的页面也会让人难以理解。《🐣如何做好前端架构》

架构另一个作用主要在业务拆分，我们需要通过确定模块开发所需了解的最小知识给实际业务开发同学做减法，不需要理解的模块就不要轻易展示出来，最大程度减少开发者的心智负担。

前端项目中一般分层做的相对较好，比如常规做法我们会把一个业务中的前端项目分为容器层，基础能力层(网络，日志，安全)，物料层，业务能力层(登录，支付，购物车)等等，但是具体到每个业务模块对业务的抽象可能做的还不够，目前集中讨论的都是数据流和框架(React/Vue)，但是这些只是手段，并不能帮我们很好的抽象业务逻辑。服务端在这些事情上有很多的抽象比如六边形架构，DDD 等等，前端需要在这件事情上有更深入的探索。

另外一个合理的架构还需要包含文档，测试等帮助人理解业务&代码的配套设施。

2.2.如何衡量代码是否可维护

因为前端再过去的复杂度一直不是很高，通过框架可以很好的解决维护的问题，所以前端在这件事情上面关注的还是比较少。直到最近几年出现很多巨石应用，才在一些业务团队中被反复提及，但是目前主要衡量的可维护的方法是通过质量指标和主观感受来进行衡量，这很显然没太多的说服力。我们实际期望的获得一个适应度函数(Fitness Function)Fi，公式为：Maintainable = Fi(Feature) ，其中业务功能变化的时候我们得到的可维护性也尽可能的贴合，这里尽可能的贴合是指我在《🐣系统中复杂度体现在哪些方面》中提到三点：

不要修改放大 (Change Amplification)

减轻认知负担 (Cognitive Load)

减少未知的未知 (Unknown Unknown)

如何衡量是否贴合比较难的地方在于Feature的变化是多种多样的，业务的逻辑就是没有逻辑，我们没办法正面求得Fi，只能通过一些侧面的指标来衡量。业界上有很多理论(见备注)，从两个方面的指标来说明：

源码方面

指标：LLOC 相比于传统的 LOC，明显LLOC更稳定

// LOC 1 
// LLOC2 
if(true) console.log('hello'); 
// LOC 3或4 
// LLOC 2 
if(true) {
  console.log('hello');
}

指标：Halstead Complexity(HV) GitHub - aametwally/Halstead-Complexity-Measures: Calculate Halstead complexity software measures using ASTParser. These metrics are computed statically, without program execution.

指标：Cognitive Complexity (CC) 认知复杂度下面的两种方法有着相同的圈复杂度，但是在可理解性方面有着显著的不同圈复杂度的数学模型赋予了这两种方法同等的权重，但是直观上很明显 sumOfPrimes 的控制流比 getWords 更难理解。这就是为什么认知复杂性放弃了使用数学模型来评估控制流，转而使用一套简单的规则来将程序员的直觉转化为数字。我们代码中的一个 bad case 用认知复杂度可以很好地衡量出来如下：

a && b //圈复杂度：2 ，认知复杂度：2 
a && b && c && d // 圈复杂度：4 ，认知复杂度：2 
a || b && c || d // 圈复杂度：4 ，认知复杂度：4

架构方面

内聚性共生性(耦合) 后续会写一篇文章单独展开讲

指标函数

Maintainability Index：由 Paul Oman and Jack Hagemeister 在1992年提出，它是若干种度量的混合，包括 HV, CC 以及 LLOC 三个不同指标，原始公式为：MI=171−5.2lnV−0.23G−16.2lnL SEI 的衍生版本 MI=171−5.2log2 V−0.23G−16.2log2 L+50sin(2.4C) 还有 Visual Studio 衍生版本， Radon 衍生版本等等通过以上的任意一个函数都可以近似求得适应度指标，我们就可以观测业务代码在迭代过程中的指标变化，从而得到是向好还是向坏的一些衡量标准，达到卡控代码的目标

(3) 熟悉程度

这块主要通过流程规范来解决，比如锁定主R，减低迭代频次，提高系统设计细节要求等方法提高团队对代码的平均熟悉水平

(4) 技能

这块主要就是看岗位胜任度了，选用育励汰等方法论

余弦相似度匹配(适用于openai的向量数据库底层实现)

Fri, 01 Jan 2021 22:00:00 GMT

小程序工程化思考

Fri, 25 Dec 2020 22:00:00 GMT

和传统工程化对比

先看下传统前端工程化关注的事情 (from umi)

小程序可做的就相对很少，源于技术本身的约束性，我们做一个对比：

框架角度：目前市面上有 kbone，taro，remax/r2m，mpvue，mpx等等选择，从优选业务场景覆盖的移动设备角度看均有明显的体验问题或不再维护，所以目前还是基于原生框架进行开发，从小程序不提供操作视图的底层api，不提供组件层级管理关系，不提供模板递归，限定包大小，固定的路由模型等等的约束性看，这也可能是微信比较推荐的做法。
TS：目前是一个问题，没有最佳的TS规范，小程序原生的TS方式并不能很好的适应复杂场景的开发
样式(css)：因为没有视图层的接口，所以没有过多的选择，微信本身提供了 @import等模块化管理的能力，为了包大小，只能使用postcss+变量插件(或css变量)的方式进行样式管理
JS编译/模块打包/压缩: 这是一个可以做的事情，webpack并不适用于小程序，这部分需要自研传统基于babel的有mpbuild或者现代的基于esbuild/swc的mpe
路由管理/请求库：均强制限制在小程序框架提供的方案，灵活性低
资源加载方式：固化为小程序主包，子包的形式，最新版基础库提供了动态加载的能力，有两个问题
1. 对基础库有要求的小程序都无法使用
2. 是一个比较限制的方案，并做传统微前端架构那样从远端加载代码
数据流：可能是一个可以做的事情，不过小程序本身不具备context的能力，实现出来的对比传统前端的易用性不是很好
代码风格：eslint prettier 等最佳实践
文档能力/通用组件开发能力：需要做的事情
测试：可能需要做，不过一般在业务团队因为ROI不高，所以不被重视

这样对比下来，就明显能感受到，我们在传统工程化上能做的事情比较少，更多的是要关注业务集成&业务领域的一些能力的建设。

小程序框架对比传统前端框架缺少什么

小程序	前端	问题	能否对齐	是否必要
启动流程	固定的 app → page 生命周期同步调用	任意编排	小程序在启动阶段有异步的依赖关系时时处理会很复杂	不能
code split	包维度	任意切分	不能	否
加载能力	支持分包异步化，且必须提前构建到一起，支持2.17.3及以上	支持从网络加载包	微应用拆分无法绕过集成构建	不能
编排能力	page+component	任意编排	不能	是
组件能力	缺失 slot能力	~	不能	是
组件间通讯	props+父节点中转	props和context能力	能	是
视图介入	不可以直接操作视图	可以直接操作dom	小程序底层能力缺失导致动态能力很难有性能保障	性能考虑不能
动态执行JS	不支持	eval等	能	是
路由	固化 page → page + tabbar	任意自定义	无法做到贴合业务场景做编排	不能

演进视角看小程序当下成熟度对比

2021 增补

	第一阶段：14年~17年	第二阶段：18年~21年	第三阶段：21年后	核心	小程序能力
框架	范式转移，vdom 提出代表：react vue2	范式转移，编译时代替运行时 vdom 代表：svelte solidjs	范式转移，去除 JS 运行时开销代表：qwik	更好的性能	还处于第一阶段
框架理念	class+声明式框架+TS 支持代表：react<0.14，vue2	function 代表：react>15	hooks 代表：react 16，vue3	增强框架对内聚性的表达带来更强的可维护性	不到第一阶段，可做工
样式理念	样式预处理代表：less scss	样式后处理代表：postcss	样式框架代表：tailwindcss	增强框架对内聚性的表达带来更强的可维护性	不到第一阶段，可做工
状态管理	单向数据流+单store，中心化代表：flux，redux，vuex，mobx	增强ts+多store，去中心化代表：mobx，pinia，recoil	元数据，惰性更新等尝试代表：zustand、jotai、valtio	更好的DX，更好的性能，配合框架理念	不到第一阶段，可做工
工具链	范式转移，依赖分析，打包部署代表：webpack	微创新代表：rollup	效率大幅度提升代表：vite	效率的提升	不到第一阶段，可做工
架构	SPA，SSR 代表：umi	微前端，SSR 流式，SSG，ESR 代表：qiankun	服务端组件等代表：react18	大规模协同问题算力转移提高性能	不到第一阶段

使用TS 开发 JS 虚拟机

Tue, 21 Jul 2020 22:30:00 GMT

背景

在我们的小程序&低代码平台中，有需要执行动态下发代码的诉求。世面上已知的一些 vm 没有完整通过 es5 或 es2015 测试用例的，无法在生产环境使用。因此需要自研一个 JSVM 引擎。

目前已放到 github 上：jsvm 2 传送门。

目前除了 WithStatement 语句外，其他 es5 特性均支持，单测覆盖 91%

原理

其实基于语法树的 JSVM 思路很简单, 不断的前序遍历 AST 即可，我们只需要将 Babel 中的 Program VariableDeclaration 等节点均实现对应的方法即可，一个简单的 VM 如下

const babelParser = require("@babel/parser");
const babelTraverse = require("@babel/traverse").default;

// 执行引擎
class ExecutionEngine {
  constructor() {
    this.globalScope = {}; // 全局作用域
  }

  // 执行语法树
  execute(ast) {
    babelTraverse(ast, {
      enter: (path) => {
        const node = path.node;
        switch (node.type) {
          case 'Program':
            this.executeProgram(node);
            break;
          case 'VariableDeclaration':
            this.executeVariableDeclaration(node);
            break;
          case 'Identifier':
            return this.executeIdentifier(node);
          case 'NumericLiteral':
            return this.executeNumericLiteral(node);
          case 'BinaryExpression':
            return this.executeBinaryExpression(node);
          // 处理其他类型的语法树节点
          // ...
        }
      }
    });
  }

  // 执行 Program 节点
  executeProgram(node) {
    for (const statement of node.body) {
      this.execute(statement);
    }
  }

  // 执行 VariableDeclaration 节点
  executeVariableDeclaration(node) {
    const variableName = node.declarations[0].id.name;
    const variableValue = this.execute(node.declarations[0].init);
    this.globalScope[variableName] = variableValue;
  }

  // 执行 Identifier 节点
  executeIdentifier(node) {
    const variableName = node.name;
    return this.globalScope[variableName];
  }

  // 执行 NumericLiteral 节点
  executeNumericLiteral(node) {
    return node.value;
  }

  // 执行 BinaryExpression 节点
  executeBinaryExpression(node) {
    const leftValue = this.execute(node.left);
    const operator = node.operator;
    const rightValue = this.execute(node.right);

    // 执行二元运算
    switch (operator) {
      case '+':
        return leftValue + rightValue;
      case '-':
        return leftValue - rightValue;
      case '*':
        return leftValue * rightValue;
      case '/':
        return leftValue / rightValue;
      // 处理其他运算符
      // ...
    }
  }
}

// 输入 JavaScript 代码
const code = `
  let x = 5;
  x + 10;
`;

// 使用 Babel 解析代码为 AST
const ast = babelParser.parse(code, {
  sourceType: "module",
});

// 创建执行引擎并执行语法树
const engine = new ExecutionEngine();
engine.execute(ast);
console.log(engine.globalScope['x']); // 输出：5

完整实现步骤

词法分析（Lexical Analysis）和语法分析（Syntax Analysis）：将输入的 JavaScript 代码转换为抽象语法树（Abstract Syntax Tree，AST）。这里直接使用 Babel 来完成
作用域分析（Scope Analysis）：在语法树中进行作用域分析，确定变量的定义和引用所在的作用域。这可以通过构建作用域链（scope chain）来实现，每个作用域都有一个指向父级作用域的引用。参考 scope.ts
变量和函数声明（Variable and Function Declaration）：在作用域分析的基础上，将变量和函数声明添加到适当的作用域中。这可以在作用域中创建变量和函数的绑定，并为后续的执行做准备。参考 declare
执行引擎（Execution Engine）：遍历语法树，并执行相应的操作。执行引擎根据语法树节点的类型执行不同的操作，例如变量赋值、函数调用、条件判断等。引擎使用作用域链来解析变量和函数的引用，并根据运行时上下文执行相应的操作。参考 visitor 以及 standard
作用域和上下文管理：在执行过程中，需要管理作用域和运行时上下文。每次进入一个函数时，会创建一个新的函数执行上下文，包括函数的作用域、参数和局部变量。在函数执行完成后，上下文会被销毁。参考 Function
值的计算和存储：执行引擎根据需要计算表达式的值，并将结果存储在适当的位置，例如变量、对象属性或函数返回值。参考 statement. ts，object
控制流管理：执行引擎处理控制流语句，例如条件语句、循环语句和异常处理。根据条件的结果，执行引擎决定执行的路径，并更新程序计数器以指向下一条要执行的语句。参考 conditional
内建函数和对象：实现一些内建的 JavaScript 函数和对象，例如 console、Array、Object 等。这些函数和对象可以通过在执行引擎中添加相应的逻辑来实现。参考 context

效果

在 react-case 中我们可以看到 JSVM 2 可以完整的将 React 跑起来。事实上在我们自己的业务上，已经运行了很久没有出现任何问题。

性能

主要的开销在不断的创建上下文上，所以在存在大量 for 循环等场景时，性能相比未开启 JIT 的 v8 来说差了 2 个数量级。因此不适合大量数据计算。但是在常规业务场景用户实际体感不到。我们在移动端的低端机上对分类页这类有复杂交互场景进行录屏测试，没有明显差异。

压缩&混淆

我们实现的这版基于 babel 生成的 AST 有一个比较大的问题，如下图可以看到一个正常的 comsole. log 语句的原始 AST 会膨胀很大，因此使用了类似 AOT 的技术，我们在上生产环境之前做了一次 AST 等价的压缩处理，压缩后为下图所示，虽然比原始语句还要大一些，但是已经可以接受了。同时为了防止在端上解压缩带来的性能损耗，我们将之前基于 babel 的 AST 协议的 JSVM 直接重写成了基于我们压缩后的 AST (这部分没有开源，但是基本原理没有变化)。

线上问题排查

为了解决线上遇到动态后代码的报错无法定位的问题，我们基于压缩的 AST 自定义了一套 sourcemap 协议，并提供了对应的后台调试工具，直接输入报错的 ID，就可以反解析到对应的行列，如下图：

系统可维护到底指的是什么

Mon, 01 Jun 2020 23:00:00 GMT

引言：可维护性是主观的还是客观的？

在大型业务开发中，经常听到这样的声音：“系统维护不下去了，代码复杂度太高了！”

但有趣的是，后台业务很少有类似抱怨，尽管它们的复杂度也不低。这让我开始思考：可维护性到底是主观感受还是客观标准？

考虑以下几个常见场景：

接手他人项目：新人觉得前任代码不可维护，要重构；但前任开发者当时并无此感
框架认知差异：一线开发同学说 React 项目复杂难维护，但能力强的同学觉得挺好
人员变动影响：架构师离职后，新团队成员觉得之前的设计难以理解
业务方向变化：多业态支持或业务转向时，原系统复用困难

这些场景说明：可维护性不完全是客观的，它与人、时间、上下文密切相关。

可维护性的四个维度

通过分析上述场景，我将影响可维护性的因素归纳为四个维度：

维度类型	客观因素	主观因素
系统层面	业务复杂度（商业逻辑的客观复杂性）	代码与架构（设计质量的主观评价）
人员层面	技能水平（拥有一定深度和广度）	熟悉程度（时间+意愿）×理解力÷频次

维度分析

业务复杂度：无法改变的客观事实，来源于商业需求
代码与架构：可以优化的技术实现，体现工程能力
技能水平：团队成员的技术能力，可通过培养提升
熟悉程度：对系统的了解程度，需要时间和精力投入

案例分析：优选项目的维护困境

以优选项目为例，分析其”难以维护”的根本原因：

问题诊断

熟悉程度低
- 为赶排期，频繁协调人员支援开发
- 团队对项目平均熟悉度偏低
架构不合理
- 每周2大迭代+3小迭代的高频发布
- 忙于排查线上问题，缺乏技术设计时间
业务复杂度高
- 团长、用户、新人、老客等多角色
- 促销、活动等多业务场景聚集
技能投入不足
- 低职级同学主力开发
- 高职级同学事务性工作多，技术投入少

负向循环

这四个问题相互影响，形成恶性循环：

![image (3)](../../assets/image (3).png)

负向循环链路：业务复杂 → 开发压力大 → 设计时间不足 → 架构质量下降 → 维护成本上升 → 熟悉程度要求更高 → 开发效率降低 → 业务压力更大

提升可维护性的系统性方法

1. 业务复杂度：拆分与抽象

核心原则：复杂度无法消除，只能合理分配

理论基础

业务复杂度是客观存在的，系统架构设计的作用是：

降低理解复杂度：让团队成员面对可控的业务难度
增加系统实体复杂度：通过引入更多抽象层来实现分离

这是一种复杂度的空间转移：从人的认知负担转移到系统结构中。

实践方法

业务领域拆分：按业务边界划分模块
分层架构设计：容器层、基础能力层、业务能力层
确定最小知识集：每个模块只需了解必要的依赖

2. 代码与架构：可衡量的质量标准

架构设计原则

核心思想：架构是业务在技术域的合理抽象

适应度函数：架构设计应该贴合业务真实复杂度
心智负担最小化：隐藏不必要的实现细节
模块化边界清晰：明确模块职责和接口

可维护性度量标准

期望目标：找到适应度函数 Maintainable = Fi(Feature)

当业务功能变化时，可维护性指标能够合理反映变化成本。

评估原则：

不要修改放大（Change Amplification）：小改动不应引起大范围修改
减轻认知负担（Cognitive Load）：开发者理解成本可控
减少未知的未知（Unknown Unknown）：避免隐藏的依赖关系

具体度量指标

源码层面：

LLOC（Logical Lines of Code）

// LOC 1, LLOC 2 - 不稳定
if (true) console.log("hello")

// LOC 3, LLOC 2 - 更稳定
if (true) {
  console.log("hello")
}

Halstead Complexity (HV)
- 基于操作符和操作数的复杂度计算
- 参考：Halstead Complexity Measures

认知复杂度（Cognitive Complexity）

a && b // 圈复杂度：2，认知复杂度：2
a && b && c && d // 圈复杂度：4，认知复杂度：2
a || (b && c) || d // 圈复杂度：4，认知复杂度：4

架构层面 什么是耦合(共生)，什么是内聚：

内聚性：模块内部的相关性
耦合度：模块间的依赖程度

综合指标：

可维护性指数（Maintainability Index）

由 Paul Oman 和 Jack Hagemeister 在1992年提出
综合 HV、CC、LLOC 三个指标
有多个工具版本：SEI、Visual Studio、Radon 等

3. 熟悉程度：流程与规范保障

关键措施

主R锁定制：减少核心开发人员变动
降低迭代频次：给充分的熟悉和设计时间
提升设计要求：强化技术方案评审
文档完善：代码注释、架构文档、业务文档

知识传承机制

Code Review 制度：提升代码质量，传播最佳实践
技术分享：定期分享架构设计和业务理解
Pair Programming：新人与老员工结对开发

4. 技能水平：岗位胜任力建设

能力模型

技术深度：框架原理、算法数据结构、系统设计
技术广度：跨端能力、全栈理解、工程化实践
业务理解：领域知识、用户需求、商业逻辑

提升路径

选：招聘匹配岗位要求的人才
用：合理分配任务，人岗匹配
育：技术培训、业务培训、最佳实践分享
励：技术成长激励、业务贡献激励
汰：不适应者调整或淘汰

监控与持续改进

建立监控体系

代码质量监控
- 定期计算 Maintainability Index
- 跟踪复杂度指标变化趋势
- 设置质量红线和预警机制
团队能力评估
- 定期评估团队技能水平
- 跟踪项目熟悉程度
- 收集主观维护感受
业务影响分析
- 需求变更的开发成本
- Bug 修复的影响范围
- 新功能的开发效率

持续改进循环

建立正向循环： 合理架构 → 开发效率提升 → 更多设计时间 → 质量持续优化 → 维护成本降低 → 团队满意度提升 → 人才稳定性增强

总结与思考

核心观点

可维护性是多维度的：不仅仅是代码质量，还涉及人员、流程、业务等因素
客观标准与主观感受并重：既要有可量化的指标，也要关注开发者体验
系统性解决方案：四个维度需要协同优化，而非单点突破

实践建议

建立度量体系：用数据说话，避免纯主观判断
注重人的因素：技能培养和团队稳定性同样重要
渐进式改进：避免大规模重构，通过持续优化提升质量
业务理解优先：深入理解业务是做好架构设计的前提

最终目标

在业务复杂度不可避免增长的前提下，通过合理的技术手段和管理方式，让系统的可维护性与业务价值保持正相关，实现技术与业务的良性循环。

相关阅读：

参考资料：

关于基建工作的思考

Mon, 01 Jun 2020 22:00:00 GMT

基建工作本身

业务中做基建很难，美团现在对技术的态度基本就是做事必先谈收益，但是这个以客户为中心的思想其实对于做基建的同学来讲来说并不是那么合适。这样做事情会有以下的问题：

从归纳出发建设：在业务上线后我们根据已有的情况进行归纳，然后提炼出来一套方案其实这时候已经太晚了，基建同学会成为一个为业务腐败的代码擦屁股的人，而且不容易控制影响
从演绎出发建设：在业务还没想到的时候，我们通过演绎发现这事情可能要搞但是现在没有业务需求，所以很难讲清楚收益，所以公司文化不支持你做，况且大概率你还有优先级更高的（问题1）要解决，所以你根本没机会做这个事情。
边做边用：如果在业务刚提了需求，我们发现这个事情是可以沉淀到基础能力上的，但是由于做基建是需要时间的，业务根本等不起，往往就是先绕过去，后面再迭代(就是在也不迭代)，这会导致项目腐化很快，同时也会得到基建能力不行的评价

这三条就组成了目前美团基建上同学工作逻辑上的完整闭环。按照美团文化的惯例，抛出问题后要给解决方案，

增加时间，我觉得管理上需要给出一定可以“浪费”的时间，另外自己也需要为爱发电。
增加洞察力，因为(问题2)上，如果真的具备洞察问题的能力，那么还是有机会争取到资源来做你认为应该做的事情的，只不过在美团尤其是在业务团队这特别的难。(毕竟沧海横流,方显出英雄本色[😄])

基建建设过程中的困境

如果业务基建能力一旦上线，会存在另一个关键问题任何底层系统的建设过程中都会存在遗漏可变性的可能性。这在我之前见过的无数项目中都发生过，这样导致底层建设人员刚走，后面一线的工程师就在吐槽架构的能力不行，设计出来的东西满足不了新需求，很难用。尤其是在创新业务中**，可能无时无刻不在做一些颠覆性的东西**，易变性分析一旦有所遗漏，做出稳定的架构还是挺难的。而且也暂时没有想到非常具备可行性的解法。

基建能带来技术深度的提升吗

另外一个事情在技术深度上，往往做业务的同学会认为基建的工作很好，会认为技术深度===技术栈的深度，这显然是不对的，背后真实的问题其实是在问你的竞争力在哪里。这里有两点：

为什么在这个点上，我做过的工作证明了比其他同事要更强
为什么这个能力是当前公司需要的，也就是所谓的收益。你能从0开始写浏览器，但是团队不需要也是没有用的“技术深度”(人事不匹配，要考虑自己的工作内容是不是符合职业发展的预期了)

什么是耦合(共生)，什么是内聚

Sat, 30 May 2020 21:30:00 GMT

为什么需要理解耦合和内聚？

在架构设计讨论中，“高内聚，低耦合”几乎是所有人的共识。但在实际项目中，我发现很多同学对这两个概念的理解还停留在朴素认知层面：

对耦合的误解：认为任何依赖都是不好的，要尽量避免
对内聚的模糊：知道要”高内聚”，但不知道如何衡量
实践中的困惑：不知道什么是合理的耦合，什么是不合理的耦合

最近在给老板汇报小程序架构演进时，我们一直在讨论”逻辑内聚”的设计，这让我意识到需要对这两个概念有更系统的理解。

核心概念定义

基础定义对比

概念	定义	关键理解
耦合（Coupling）共生（Connascence）	有A、B两个模块，当修改A时，必须修改B，我们称之为B耦合A	• 没有包含关系：耦合是模块间的，不是父子间的 • 编译约束：静态类型语言中可理解为编译器报错的”连接约束” • 与业务无关：不是业务上经常同时修改就叫耦合
内聚（Cohesion）	若干个模块因为某种关系被包含在一起的紧密程度	• 包含关系：具有父子层级关系 • 耦合占比：内聚 = 子模块间耦合数量 ÷ 子模块总数 • 代码维护视角：关注的是代码组织，不是业务逻辑

关系本质

核心理解：内聚是依赖耦合的，都属于模块化的度量指标。我们要防止的不是耦合本身，而是不合理的耦合。

内聚性详解：从弱到强的7个层次

根据《软件架构：架构模式、特征及实践指南》，内聚性有7个层次（按强度从弱到强）：

内聚性层次表

层次	类型	定义	特征	示例
1	偶然内聚	模块内元素间没有任何联系	最低内聚度，巧合组合	工具类大杂烩
2	逻辑内聚	相关功能组合，通过参数选择	功能相关但实现独立	各种验证函数放在一起
3	时间内聚	需要同时执行的动作组合	时间相关性	初始化模块
4	过程内聚	按特定顺序执行的处理元素	顺序相关但无数据传递	操作流程步骤
5	通信内聚	操作同一数据结构的元素	数据相关性	用户信息CRUD
6	顺序内聚	前一个输出是后一个输入	数据流相关性	数据处理管道
7	功能内聚	所有元素为完成同一功能存在	最高内聚度，单一职责	计算水费模块

内聚性改进示例

低内聚的代码：

class Module {
  a = 1;
  b = 2;
  
  fn1() {
    this.a = 1;
  }
  
  fn2() {
    return this.b;
  }
  
  fn3() {
    console.log('fn');
  }
}

改进后的高内聚代码：

class ModuleA {
  a = 1;
  
  fn1() {
    this.a = 1;
  }
}

class ModuleB {
  b = 3;
  
  fn2() {
    return this.b;
  }
}

class ModuleC {
  fn3() {
    console.log('fn');
  }
}

共生性（Connascence）：耦合的精确度量

1996年 Meilir Page-Jones 在《What Every Programmer Should Know About Object-Oriented Design》中完善了耦合的度量，命名为”Connascence”：

如果一个组件的改变会要求另一个组件进行修改，才能保持系统的整体正确性，那么这两个组件就是共生的。

静态共生性（Static Connascence）

1. 名称共生性（Connascence of Name, CoN）

特征：引用相同的名称

class Customer {
  Age = 25; // 第3行
}

const customer = new Customer();
console.log(customer.Age); // 第8行 - 如果第3行改名，这里必须同步修改

评价：最理想的共生类型，现代IDE可以自动处理重命名。

2. 类型共生性（Connascence of Type, CoT）

特征：必须就数据类型达成一致

function sayHello(name: string): string {
  return `Hello ${name}`;
}

sayHello(123); // 错误：类型不匹配

3. 意义共生性（Connascence of Meaning, CoM）

特征：必须就特定值的含义达成一致（Magic Number）

// 不好的例子
if (status === 1) { /* 激活 */ }
if (status === 2) { /* 禁用 */ }

// 改进
const STATUS = {
  ACTIVE: 1,
  DISABLED: 2
};
if (status === STATUS.ACTIVE) { /* 激活 */ }

4. 位置共生性（Connascence of Position, CoP）

特征：必须就顺序达成一致

// 位置耦合
function createUser(firstName, lastName, address) {
  // ...
}
createUser("Bob", "Marley", "Jamaica");

// 改进：名称耦合
function createUser(userInfo) {
  const { firstName, lastName, address } = userInfo;
  // ...
}
createUser({
  firstName: "Bob",
  lastName: "Marley", 
  address: "Jamaica"
});

5. 算法共生性（Connascence of Algorithm, CoA）

特征：必须就算法达成一致

// 客户端和服务端必须使用相同的加密算法
const clientHash = md5(password + salt);
const serverHash = md5(password + salt); // 必须保持一致

动态共生性（Dynamic Connascence）

1. 执行共生性（Connascence of Execution, CoE）

特征：代码执行顺序的耦合

// 错误的顺序
email = new Email();
email.setRecipient("foo@example.com");
email.setSender("me@me.com");
email.send(); // 先发送了
email.setSubject("whoops"); // 后设置主题

// 正确的顺序
email = new Email();
email.setRecipient("foo@example.com");
email.setSender("me@me.com");
email.setSubject("Important Message");
email.send();

2. 时间共生性（Connascence of Timing, CoT）

特征：执行时间上的耦合

// Bootstrap Modal 的时间耦合问题
$(element).modal('hide');
$(element).modal('show'); // 错误！动画未完成

// 正确的做法
$(element).modal('hide');
$(element).on('hidden.bs.modal', () => {
  $(element).modal('show'); // 等待动画完成
});

3. 值共生性（Connascence of Values, CoV）

特征：必须同时更改多个值

// 测试中的值耦合
function calculateTotal() {
  return 50; // 函数返回值
}

// 测试代码
expect(calculateTotal()).toBe(50); // 必须保持一致

4. 身份共生性（Connascence of Identity, CoI）

特征：必须引用同一个对象实例

// 问题代码：对象副本导致的身份耦合
function changeMovieTitle(movie, newTitle) {
  const updatedMovie = { ...movie, title: newTitle };
  return updatedMovie; // 返回新对象
}

function displayMovie(movie) {
  console.log(movie.title); // 显示旧标题
}

// 解决方案：返回对象ID而不是对象本身
function changeMovieTitle(movieId, newTitle) {
  // 直接修改数据库
  database.updateMovie(movieId, { title: newTitle });
  return movieId;
}

共生性的三个属性

1. 强度（Strength）

原则：倾向于静态共生性，避免动态共生性

静态共生性：可以通过IDE工具检测和处理
动态共生性：需要运行时分析，更难管理

2. 局部性（Locality）

原则：距离越近，允许的共生性越强

同一模块内：可以有较强的共生性
跨模块：应该使用较弱的共生性

3. 程度（Degree）

原则：影响范围越小越好

影响几个类：可接受
影响几十个类：需要重构

实践指南

Page-Jones 的三个指导原则

通过模块化拆分，使整体共生性达到最弱
最小化跨越模块边界的共生性
最大化模块内部的共生性

Jim Weirich 的简化建议

程度法则：将强共生性转化为弱共生性
局部性法则：距离增加时，使用更弱的共生性

实际操作建议

设计阶段

模块边界设计
- 明确模块职责边界
- 最小化跨模块依赖
- 优先使用名称共生性
接口设计
- 避免位置耦合，使用命名参数
- 减少算法耦合，抽象通用接口
- 控制类型耦合的传播范围

开发阶段

代码组织
- 相关功能聚集在同一模块
- 避免循环依赖
- 清晰的模块导入/导出
重构策略
- 识别高耦合点
- 逐步降低共生性强度
- 提高模块内聚性

维护阶段

监控指标
- 模块间依赖数量
- 共生性强度分布
- 变更影响范围
持续改进
- 定期重构高耦合模块
- 优化模块边界划分
- 提升代码可读性

在前端项目中的应用

组件设计

// 低内聚：功能混杂
class UserComponent {
  renderProfile() { /* 渲染用户信息 */ }
  validateForm() { /* 表单验证 */ }
  sendEmail() { /* 发送邮件 */ }
  calculateAge() { /* 计算年龄 */ }
}

// 高内聚：单一职责
class UserProfile {
  renderProfile() { /* 只负责渲染 */ }
}

class UserValidator {
  validateForm() { /* 只负责验证 */ }
}

class EmailService {
  sendEmail() { /* 只负责邮件 */ }
}

状态管理

// 强耦合：直接修改全局状态
function updateUser(userId, data) {
  window.globalState.users[userId] = data; // 位置耦合
  window.globalState.lastUpdate = Date.now(); // 值耦合
}

// 弱耦合：通过接口操作
function updateUser(userId, data) {
  userStore.update(userId, data); // 名称耦合
  eventBus.emit('user:updated', { userId, data }); // 名称耦合
}

总结与思考

核心要点

耦合不是敌人：合理的耦合是必要的，关键是控制耦合的类型和强度
内聚需要耦合：高内聚依赖于合理的内部耦合
动态优于静态：静态共生性更容易管理和重构
局部性原则：距离决定允许的耦合强度

实践建议

优先级排序：名称耦合 > 类型耦合 > 其他形式的耦合
模块化设计：明确边界，减少跨模块强耦合
工具支持：利用IDE和静态分析工具检测耦合问题
持续重构：定期审视和优化模块结构

思考方向

在复杂系统设计中，完全消除耦合是不可能的，也是不必要的。关键是：

识别：能够识别不同类型的耦合
度量：能够评估耦合的合理性
优化：能够有针对性地改进模块结构

最终目标是构建松散耦合、高度内聚的模块化系统，既保证功能的完整性，又维持良好的可维护性。

相关阅读：

参考资料：

关于基建工作的思考

Wed, 20 May 2020 13:00:00 GMT

技术债务评估

对于技术债务，它的利息表现为系统的不稳定性，以及由于临时性手段和缺乏合适的设计、文档工作和测试带来的不断攀升的维护成本。 —— 《架构师应该知道的 97 件事》

如 Robert Nord 提出的 “技术债务全景图”（Tech Debt Landscape）所示：

技术债对于软件的影响：可维护性（Maintainability）、可演进性（Evolvability），而这些技术债对于非技术人员来说都是不可见的。它们源于生活，藏于黑暗中。

技术债头脑风暴

团队一起列出潜在的技术债
归纳、分类技术债
优先级排序
物理板可视化

可视化工具

技术债看板

技术债看板（比如我之前在大象做的任务看板管理应用）

![image (1)](../../assets/image (1).png)

技术债热力图

服务级别热力图

技术债墙

![image (2)](../../assets/image (2).png)

技术债务管理

技术债治理的四条原则（《技术债治理的四条原则》）：

核心领域优于其他子域
可演进性优于可维护性
明确清晰的责任定义优于松散无序的任务分配
主动预防优于被动响应

避免技术债

童子军规则

童子军有一条规则：“永远保持离开时的露营地比你发现它时更整洁”。

提交的代码要比检出的更好

避免破窗效应

破窗效应：及时矫正和补救正在发生的问题。

以一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。又或想像一条人行道有些许纸屑，如果无人清理，不久后就会有更多垃圾，最终人们会视若理所当然地将垃圾顺手丢弃在地上。因此破窗理论强调着力打击轻微罪行有助减少更严重罪案，应该以“零容忍”的态度面对罪案。

此理论描述了社区失序的五个阶段：

社区开始出现失序的情形，部分居民迁出社区。
未能迁离社区的居民因担心自身安全，对区内的事务漠不关心。
地区的监察力下降，社区的治安进一步恶化。
区内更多的居民迁走，仍然留在区内的居民则更加退缩，减少外出时间。
外来的犯罪份子入侵社区，令犯罪数字持续上升。

对应的软件开发失序：

少部分开发人员不关注代码质量。如测试的编写
开发人员关注于交付速度，不关心代码质量。
项目代码质量进一度恶化
改一个 bug，出现更多的 bug
项目无法维护，只能重写

可维护性

代码可以快速无副作用的删除掉，可维护性最强。这对系统架构的要求最高

一般项目中具有可维护性的代码大多都有以下特征：

代码风格是与团队代码风格一致的，这个可以通过eslint做约束
代码是模块化的，不应该一个文件包含所有业务逻辑，必须做物理拆分
逻辑是分层的，Service是一层，View是一层，核心业务逻辑是一层，可以参考MV*，每一层不应该掺杂其他层的职能
视图是组件化的，将通用视图交互逻辑层层抽象封装，进一步简化核心视图复杂度

《Defects 的启示》

关于跨团队沟通与合作

Mon, 04 May 2020 22:55:00 GMT

话有三说，巧说为妙。跨团队沟通中，说的话肯定是有目的的，只要对达成这个目的有利，沟通方式方法都可以妥协。

要讨论利益，而不是立场。

在谈话前，你可能已经想好了某种解决方案。但不要在谈话一开始就向对方阐明你的解决方案，要首先向对方说明解决此问题后，会给你们双方带来什么利益。

一种解决方案代表一种立场，你的目的->你想要实现的目标->只能代表你的利益。应该找到双方的共识，这样你就可以谈论你们的利益。反过来也是一样。通过对利益进行讨论，可以找到双方的共识。做好双方共同寻找解决方案的准备。问题的讨论过程中，你可能会发现新的解决方案，这一方案符合双方的利益。

状态管理

Fri, 20 Mar 2020 22:26:30 GMT

swr

https://github.com/zeit/swr

数据更新上比较麻烦

https://stook-cn.now.sh/docs/rest/share-state

使用rest范式约束后端来达到同样的目的

不需要ssr，没有路由诉求

stream

return stream

Type Inference 类型推断
Framework extensions are fully typed 框架扩展是完全类型化的
The initial state is fully typed 初始状态是完全类型化的
Jump to definition works seamlessly 跳转到定义工作无缝

状态有几种

纯静态的
组件内部的
从数据源中获取的，而且组件生命周期内只需要获取一次
需要进行动态管理的，比如列表数据中某一项更新

从整个架构上看，希望所有的东西都是可插拔的，业务高内聚的，也就是插件式的，整个分形，所以状态也要这样。

我们需要在最上层使用统一的架构来处理相关依赖

app.config.js

业务少写代码主要集中在几个地方一个是在状态管理的时候，一个是在发请求的时候，

@rsjs/core

Introduction 👋
Installation 💿
Everyday Usage 😎
Advanced Usage :nerd_face:
- Adding side effects
API Summary 📖
Examples with live demos 📺
Articles 📢
Performance 🚀
Platform support 💻

Introduction 👋

一个好的状态管理工具至少有以下几个必要的特性

更符合人类直觉认识
框架扩展是完全类型化的
自动类型推断，且初始状态是完全类型化的
无缝跳转到定义

/*
最简单的 demo
*/
import React from 'react';
import { useObserverState, view } from '@rsjs/core';

export default view(() => {
    const counter = useObserverState({
      num: 0,
      increment: () => counter.num++
    });
    return <button onClick={counter.increment}>{counter.num}</button>
});

点击这里查看详细Demo TodoMVC codesandbox

Installation 💿

npm install @rsjs/core

Setting up a quick project

@rsjs/core不需要额外的配置就支持 Create React App，和react-native

npx create-react-app my-app
cd my-app
npm install @rsjs/core
npm run start

npx需要npm 5.2+以上版本

Usage 😎

创建service

CountService

import { Service, Injectable } from '@rsjs/core';

@Injectable()
class CountService extends Service{
  // 初始值有状态，类型自动推断
  num = 0;
  profile = {
    firstName: 'Bob',
    lastName: 'Smith',
    get name() {
      return `${this.profile.firstName} ${this.profile.lastName}`;
    }
  }
	async add(n: number){
    await sleep(1000);
    this.num+=n;
  }
}

State stores may have arbitrary structure and they may be mutated in any syntactically valid way.

import { store } from '@rsjs/core';

// stores can include any valid JS structure
// including nested data, arrays, Maps, Sets, getters, setters, inheritance, ...
const user = store({
  profile: {
    firstName: 'Bob',
    lastName: 'Smith',
    get name() {
      return `${user.profile.firstName} ${user.profile.lastName}`;
    }
  },
  hobbies: ['programming', 'sports'],
  friends: new Map()
});

// stores may be mutated in any syntactically valid way
user.profile.firstName = 'Bob';
delete user.profile.lastName;
user.hobbies.push('reading');
user.friends.set('id', otherUser);

Async operations can be expressed with the standard async/await syntax.

import { store } from '@rsjs/core';

const userStore = store({
  user: {},
  async fetchUser() {
    userStore.user = await fetch('/user');
  }
});

export default userStore;

State stores may import and use other state stores in their methods.

userStore.js

import { store } from '@rsjs/core';

const userStore = store({
  user: {},
  async fetchUser() {
    userStore.user = await fetch('/user');
  }
});

export default userStore;

recipesStore.js

import { store } from '@rsjs/core';
import userStore from './userStore';

const recipesStore = store({
  recipes: [],
  async fetchRecipes() {
    recipesStore.recipes = await fetch(`/recipes?user=${userStore.user.id}`);
  }
});

export default recipesStore;

Wrap your state stores with store as early as possible.

// DON'T DO THIS
const person = { name: 'Bob' };
person.name = 'Ann';

export default store(person);

// DO THIS INSTEAD
const person = store({ name: 'Bob' });
person.name = 'Ann';

export default person;

The first example wouldn’t trigger re-renders on the person.name = 'Ann' mutation, because it is targeted at the raw object. Mutating the raw - none store-wrapped object - won’t schedule renders.

Avoid using the this keyword in the methods of your state stores.

import { store, view } from '@rsjs/core';

const counter = store({
  num: 0,
  increment() {
    // DON'T DO THIS
    this.num++;
    // DO THIS INSTEAD
    counter.num++;
  }
});

export default view(() => <div onClick={counter.increment}>{counter.num}</div>);

this.num++ won’t work, because increment is passed as a callback and loses its this. You should use the direct object reference - counter - instead of this.

Creating reactive views

Wrapping your components with view turns them into reactive views. A reactive view re-renders whenever a piece of store - used inside its render - changes.

import React from 'react';
import { view, store } from '@rsjs/core';

// this is a global state store
const user = store({ name: 'Bob' });

// this is re-rendered whenever user.name changes
export default view(() => (
  <div>
    <input value={user.name} onChange={(ev) => (user.name = ev.target.value)} />
    <div>Hello {user.name}!</div>
  </div>
));

Wrap ALL of your components with view - including class and function ones - even if they don't seem to directly use a store.

Every component that is using a store or part of a store inside its render must be wrapped with view. Sometimes store usage is not so explicit and easy to to miss.

import { view, store } from '@rsjs/core';

const appStore = store({
  user: { name: 'Ann' }
});

const App = view(() => (
  <div>
    <h1>My App</h1>
    <Profile user={appStore.user} />
  </div>
));

// DO THIS
const Profile = view(({ user }) => <p>Name: {user.name}</p>);

// DON'T DO THIS
// This won't re-render on appStore.user.name = 'newName' like mutations
const Profile = ({ user }) => <p>Name: {user.name}</p>;

If you are 100% sure that your component is not using any stores you can skip the view wrapper.

import React from 'react';

// you don't have to wrap this component with `view`
export default () => <p>This is just plain text</p>;

view wrapping is advised even in these cases though.

It saves you from future headaches as your project grows and you start to use stores inside these components.
view is pretty much equivalent to memo if you don’t use any stores. That is nearly always nice to have.

A single reactive component may use multiple stores inside its render.

import React from 'react';
import { view, store } from '@rsjs/core';

const user = store({ name: 'Bob' });
const timeline = store({ posts: ['react-easy-state'] });

// this is re-rendered whenever user.name or timeline.posts[0] changes
export default view(() => (
  <div>
    <div>Hello {user.name}!</div>
    <div>Your first post is: {timeline.posts[0]}</div>
  </div>
));

view implements an optimal shouldComponentUpdate (or memo) for your components.

Using PureComponent or memo will provide no additional performance benefits.
Defining a custom shouldComponentUpdate may rarely provide performance benefits when you apply some use case specific heuristics inside it.

Reactive renders are batched. Multiple synchronous store mutations won't result in multiple re-renders of the same component.

import React from 'react';
import { view, store } from '@rsjs/core';

const user = store({ name: 'Bob', age: 30 });

function mutateUser() {
  user.name = 'Ann';
  user.age = 32;
}

// calling `mutateUser` will only trigger a single re-render of the below component
// even though it mutates the store two times in quick succession
export default view(() => (
  <div onClick={mutateUser}>
    name: {user.name}, age: {user.age}
  </div>
));

If you mutate your stores multiple times synchronously from exotic task sources, multiple renders may rarely happen. If you experience performance issues you can batch changes manually with the batch function. batch(fn) executes the passed function immediately and batches any subsequent re-renders until the function execution finishes.

import React from 'react';
import { view, store, batch } from '@rsjs/core';

const user = store({ name: 'Bob', age: 30 });

function mutateUser() {
  // this makes sure the state changes will cause maximum one re-render,
  // no matter where this function is getting invoked from
  batch(() => {
    user.name = 'Ann';
    user.age = 32;
  });
}

export default view(() => (
  <div>
    name: {user.name}, age: {user.age}
  </div>
));

NOTE: The React team plans to improve render batching in the future. The batch function and built-in batching may be deprecated and removed in the future in favor of React’s own batching.

Always apply view as the latest (innermost) wrapper when you combine it with other Higher Order Components.

import { view } from '@rsjs/core';
import { withRouter } from 'react-router-dom';
import { withTheme } from 'styled-components';

const Comp = () => <div>A reactive component</div>;

// DO THIS
withRouter(view(Comp));
withTheme(view(Comp));

// DON'T DO THIS
view(withRouter(Comp));
view(withTheme(Comp));

Usage with (pre v4.4) React Router.

If routing is not updated properly, wrap your view(Comp) - with the Routes inside - in withRouter(view(Comp)). This lets react-router know when to update.
The order of the HOCs matter, always use withRouter(view(Comp)).

This is not necessary if you use React Router 4.4+. You can find more details and some reasoning about this in this react-router docs page.

Usage with React Developer Tools.

If you want React Developer Tools to recognize your reactive view components’ names, you have to pass either a named function or an anonymous function with name inference to the view wrapper.

import React from 'react';
import { view, store } from '@rsjs/core';

const user = store({
  name: 'Rick'
});

const componentName = () => <div>{user.name}</div>;

export default view(componentName);

Passing nested data to third party components.

Third party helpers - like data grids - may consist of many internal components which can not be wrapped by view, but sometimes you would like them to re-render when the passed data mutates. Traditional React components re-render when their props change by reference, so mutating the passed reactive data won’t work in these cases. You can solve this issue by deep cloning the observable data before passing it to the component. This creates a new reference for the consuming component on every store mutation.

import React from 'react';
import { view, store } from '@rsjs/core';
import Table from 'rc-table';
import cloneDeep from 'lodash/cloneDeep';

const dataStore = store({
  items: [
    {
      product: 'Car',
      value: 12
    }
  ]
});

export default view(() => <Table data={cloneDeep(dataStore.items)} />);

Creating local stores

A singleton global store is perfect for something like the current user, but sometimes having local component states is a better fit. Just create a store inside a function component or as a class component property in these cases.

Local stores in function components

import React from 'react'
import { view, store } from '@rsjs/core'

export default view(() => {
  const counter = store({ num: 0 })
  const increment = () => counter.num++
  return <button={increment}>{counter.num}</div>
})

Local stores in functions rely on React hooks. They require React and React DOM v16.8+ or React Native v0.59+ to work.

You can use React hooks - including useState - in function components, Easy State won't interfere with them. Consider using autoEffect instead of the useEffect hook for the best experience though.

import React from 'react';
import { view, store } from '@rsjs/core';

export default view(() => {
  const [name, setName] = useState('Ann');
  const user = store({ age: 30 });
  return (
    <div>
      <input value={name} onChange={(ev) => setName(ev.target.value)} />
      <input value={user.age} onChange={(ev) => (user.age = ev.target.value)} />
    </div>
  );
});

Local stores in class components

import React, { Component } from 'react';
import { view, store } from '@rsjs/core';

class Counter extends Component {
  counter = store({ num: 0 });
  increment = () => counter.num++;

  render() {
    return <button onClick={this.increment}>{this.counter.num}</button>;
  }
}

export default view(Counter);

You can also use vanilla setState in your class components, Easy State won't interfere with it.

import React, { Component } from 'react';
import { view, store } from '@rsjs/core';

class Profile extends Component {
  state = { name: 'Ann' };
  user = store({ age: 30 });

  setName = (ev) => this.setState({ name: ev.target.value });
  setAge = (ev) => (this.user.age = ev.target.value);

  render() {
    return (
      <div>
        <input value={this.state.name} onChange={this.setName} />
        <input value={this.user.age} onChange={this.setAge} />
      </div>
    );
  }
}

export default view(Profile);

Don't name local stores as state. It may conflict with linter rules, which guard against direct state mutations.

import React, { Component } from 'react';
import { view, store } from '@rsjs/core';

class Profile extends Component {
  // DON'T DO THIS
  state = store({});
  // DO THIS
  user = store({});
  render() {}
}

Deriving local stores from props (getDerivedStateFromProps).

Class components wrapped with view have an extra static deriveStoresFromProps lifecycle method, which works similarly to the vanilla getDerivedStateFromProps.

import React, { Component } from 'react';
import { view, store } from '@rsjs/core';

class NameCard extends Component {
  userStore = store({ name: 'Bob' });

  static deriveStoresFromProps(props, userStore) {
    userStore.name = props.name || userStore.name;
  }

  render() {
    return <div>{this.userStore.name}</div>;
  }
}

export default view(NameCard);

Instead of returning an object, you should directly mutate the received stores. If you have multiple local stores on a single component, they are all passed as arguments - in their definition order - after the first props argument.

Advanced Usage :nerd_face:

Adding side effects

Use autoEffect to react with automatic side effect to your store changes. Auto effects should contain end-of-chain logic - like changing the document title or saving data to LocalStorage. view is a special auto effect that does rendering.

Never use auto effects to derive data from other data. Use dynamic getters instead.

import { store, autoEffect } from '@rsjs/core';

// DON'T DO THIS
const store1 = store({ name: 'Store 1' });
const store2 = store({ name: 'Store 2' });
autoEffect(() => (store2.name = store1.name));

// DO THIS INSTEAD
const store1 = store({ name: 'Store 1' });
const store2 = store({
  get name() {
    return store1.name;
  }
});

Global auto effects

Global auto effects can be created with autoEffect and cleared up with clearEffect.

import { store, autoEffect, clearEffect } from '@rsjs/core';

const app = store({ name: 'My App' });
const effect = autoEffect(() => (document.title = app.name));

// this also updates the document title
app.name = 'My Awesome App';

clearEffect(effect);
// this won't update the document title, the effect is cleared
app.name = 'My App';

Local auto effects in function components

Use local auto effects in function components instead of the useEffect hook when reactive stores are used inside them. These local effects are automatically cleared when the component unmounts.

import React from 'react';
import { store, view, autoEffect } from '@rsjs/core';

export default view(() => {
  const app = store({ name: 'My App' });
  // no need to clear the effect
  autoEffect(() => (document.title = app.name));
});

Explicitly pass none reactive dependencies - like vanillas props and state - to local auto effects in function components.

Because of the design of React hooks you have to explicitly pass all none reactive data to a hook-like dependency array. This makes sure that the effect also runs when the none reactive data changes.

import React from 'react';
import { store, view, autoEffect } from '@rsjs/core';

export default view(({ greeting }) => {
  const app = store({ name: 'My App' });
  // pass `greeting` in the dependency array because it is not coming from a store
  autoEffect(() => (document.title = `${greeting} ${app.name}`), [greeting]);
});

Local auto effects in class components

Local effects in class components must be cleared when the component unmounts.

import React, { Component } from 'react';
import { store, view, autoEffect } from '@rsjs/core';

class App extends Component {
  app = store({ name: 'My App' });

  componentDidMount() {
    this.effect = autoEffect(() => (document.title = this.app.name));
  }

  componentWillUnmount() {
    // local effects in class components must be cleared on unmount
    clearEffect(this.effect);
  }
}

API Summary 📖

store(obj)

Creates an observable store from the passed object and returns it. Can be used outside components for global stores and inside components for local stores.

import { store } from '@rsjs/core';

const user = store({ name: 'Rick' });

view(Comp)

Creates a reactive view from the passed component and returns it. A reactive view re-renders whenever any store data used inside it is mutated.

import React from 'react';
import { view, store } from '@rsjs/core';

const user = store({ name: 'Bob' });

export default view(() => <div>Hello {user.name}!</div>);

batch(fn)

Immediately executes the passed function and batches all store mutations inside it. Batched mutations are guaranteed to not trigger unnecessary double renders. Most task sources are batched automatically, only use batch if you encounter performance issues.

import React from 'react';
import { view, store } from '@rsjs/core';

const user = store({ name: 'Bob' });

function setName() {
  batch(() => {
    user.name = 'Rick';
    user.name = 'Ann';
  });
}

autoEffect(fn)

Creates a reactive function from the passed one, immediately executes it, and returns it. A reactive function automatically re-reruns whenever any store data used inside it is mutated.

Can be used both outside and inside components.

import { store, autoEffect } from '@rsjs/core';

const user = store({ name: 'Bob' });

autoEffect(() => (document.title = user.name));

clearEffect(fn)

Takes a reactive function (returned by autoEffect) and clears the reactivity from it. Cleared reactive functions will no longer re-rerun on related store mutations. Reactive functions created inside function components are automatically cleared when the component unmounts.

import { store, autoEffect, clearEffect } from '@rsjs/core';

const user = store({ name: 'Bob' });

const effect = autoEffect(() => (document.title = user.name));
clearEffect(effect);

Articles 📢

TODO

Performance 🚀

You can compare Easy State with plain React and other state management libraries with the below benchmarks. It performs a bit better than MobX and similarly to Redux.

Platform support 💻

Node: 6 and above
Chrome: 49 and above
Firefox: 38 and above
Safari: 10 and above
Edge: 12 and above
Opera: 36 and above
React Native: 0.59 and above

This library is based on non polyfillable ES6 Proxies. Because of this, it will never support IE.

使用完整react能力开发小程序

Fri, 22 Nov 2019 22:00:00 GMT

最近这一年在小象负责移动端相关的架构工作，之前提到我们游戏基于 pixi 自研了一个游戏框架，成功的将 react 桥接到 pixi 上。这给了我很大的信息，开始思考是否能让 react 跑在任意平台上、

我们的小程序是一个电商业务比较复杂，可以微信搜索“美团买菜”体验一下，和 APP 的交互都是对齐的。这就导致这个小程序其实很大，开发的时候需要一整套工具和规范来进行约束，所以18年的时候又研发了小程序的构建工具，提供了 npm,typescript,scss,less,postcss,babel 等等的支持，但是整体支持的还是小程序原生的语法，因此希望在这个基础上，支持 react 语法。

市面上比较出名的方案是京东的taro，它使用静态语法分析在构建的过程将jsx硬转成小程序模板，确实是一个很赞的做法，但是会有很多方案的限制，我们不太想写业务的时候有太多“心智负担”，react怎么写就怎么写，react生态的库该怎么用就怎么用，所以taro的思路肯定不行。基于做游戏的思路，初步想法是在小程序上面实现一个运行时来兼容整个react，其实就是实现一个类似vdom的结构连接react和小程序视图层。在开发的过程中，有些库依赖一些BOM接口，所以我们干脆就实现了一个简单的dom/bom的垫片，让react能跑在上面，然后由这个垫片和小程序视图层做交互。

前端视角支持游戏开发

Tue, 12 Nov 2019 22:30:00 GMT

最近实现了一个天天领钱 H5 游戏，一期基础场景如下

在做果园之前，我们和其他部门专职做游戏的同学充分的进行了沟通，得到很多宝贵的经验：框架层面：了解到他们使用的是 cocos creator 框架，但是提到 cocos 框架是 c++迁移到 js 的，所以本身就有诸多小问题，所以新的游戏他们都使用的是 laya 框架，也推荐我们来使用。通讯层面：后端交互使用的是 websocket 实现的，通讯相关的复杂度很高，因为后端是有状态服务，前端要做 request event 和 response event 之间的关联。所以建议我们还是用短连接。

回来后深入学习了下 laya 框架，也玩了一些同类的游戏，发现其实这类游戏与其说是游戏还不如说是一个运营活动。其实技术上游戏元素很少，只是玩法上是类似游戏的交互。所以未必真的需要上 laya 框架另外：

团队技术储备都是偏向小程序/H5 游戏类的都没什么经验，产品侧给的时间比较短风险也大
游戏本身很简单(交互性很低)，判断不需要太复杂的游戏框架

架构分析

那么基于这样的一个限制，思考了一个新的做法：

美术同学做好果园需要的骨骼动画，
前端通过某种方式当用户点击的时候播放对应动画即可

剩下所有功能都使用前端技术(React)去做。

关于骨骼动画目前其实三部分：

树的点击，成长，升级；
水壶的浇水；
奖励的弹窗
领水滴动画

所以其实就是四个动画文件，在合适的时机去播放合适的动画就行了。调研了一圈，最后选择使用 pixi.js V5 来做这游戏的画布，封装了 pixi-dragonbones 进行龙骨的播放。

所以我们的整个架构就变成了下面这样三层的结构，底层就是主场景的绘制，主要动画的执行，中间层就是各种业务弹层，上层是动画弹层

游戏引擎篇

最开始的时候，只是单纯的封装了三层架构到一个 Game 类里面，然后游戏精灵的创建还是使用的类似 JQuery 的方式进行的。所以一旦有数据层面的变动，必须直接找到对应的精灵实例进行操作，比如坐标变化。这样其实有一些倒退。写的过程中也很不爽，后面就思考了下响应式的做法，有两个办法

基于 RXJS+对象
类似 react 的方式声明对象，数据变化导致精灵属性的变化由框架维护

因为之前写过一些 RXJS 的项目，了解里面的复杂度，再团队内推很可能导致较大的延期风险，毕竟很多 RXJS 配套的运行时都没有研发。所以潜意识里就第一时间放弃这个做法（也是目前最后悔的地方，应该用的，后面再聊），而为了方便现有开发，将已有的 react 资产集成进来开始考虑如何用 react 的方式进行游戏开发，第一反应就是实现一个 ReactPiXi (对标 ReactDom)，所以快速写了一个 ReactPiXi 验证了一下发现果然可行。继续完善的过程中，查资料偶然发现一个开源的方案 @inlet/react-pixi ，大部分都实现了，但是遇到点小问题，提了 pr 也很快合入了，最后就选定了这个库，至此游戏精灵对象和 dom 对象两层就在逻辑上合并为一层了。游戏精灵的 react 写法这样游戏对象和数据流就可以通过声明的方式进行关联了。至此整体开发就完全变成前端最熟悉的开发模式，和游戏就没有太多关系了。后续这方面的工作就和 RN 一样，要使用 react 组件的方式封装一些原生的精灵对象即可。

数据流篇

数据流选用了 mobx，这是目前复盘看比较失败的地方。mobx 的优势最大的就是响应式编程，当时使用 mobx 是想的当数据变化的时候，直接响应的回调操作游戏精灵，类似下面的代码

autorun(()=>{
  const sprite = new Sprite();
  sprite.y = store.tree.x;
  sprite.x = store.tree.y;
})

这样只有在tree的x或者y属性变化的时候才会执行这个回调，能有效的进行数据和对象的绑定，但是后面换成react架构之后，绑定关系在render函数中就实现了，所以根本不需要这么写。当时考虑到mobx和react也能很好的集成，所以我们就没有进行数据源的更换，还是沿用了mobx。

在正常业务开发的时候mobx没有太多的问题，但是当进行多个动画对象联动的时候mobx就出现了比较大的麻烦。比如浇水动画播放到2s的时候播放进度条动画，等服务端返回的时候播放数升级动画同时更新主场景，然后升级2s的时候出弹层动画。整个流程使用mobx就比较难以描述，还是要在业务层代码写很多离散的逻辑。而这些正好是rxjs比较擅长解决的问题，会把同步的异步的推拉两种架构都汇总到同一个流的模式上完成，其实是最契合目前的场景的。

另外发现一个问题，mobx 的开发者工具没有 redux 的好用，仅仅支持简单的数据流变化，这种变化监听是牺牲了易用性完成的，及必须将每个 state 的操作都通过 action 进行才可以。而这么写在开发角度看就回退到了 redux 的模式。另外 mobx 对数据没有一个很好的管理方案，store 是离散的，所以没办法对 store 做很好的镜像上报，不容易排查问题。

目前实践下来 Mobx 目前比较好的点就是不需要关注更新位置，只有变更的组件才会更新，不需要写 memo 之类的函数进行处理。

资源管理篇

资源管理的诉求

支持换肤，动态换肤/静态换肤
支持自动图集(雪碧图)
支持自动有损压缩
支持webp
最好能做到设计自行传图片，应用后线上自动生效，不需要研发介入

针对上面的诉求资源管理最开始希望做一个托管的网站进行管理，解耦设计和研发之间的依赖。但是发现流程和版本控制上比较复杂，几经讨论就暂时搁置了这个方案，需要进一步探索

新的方案暂时不满足第五点，满足前四点就只需要提供一个本地的构建工具即可，我们按照目录进行了约定，将游戏内使用的资源分为三类：

文案资源
颜色资源
静态文件资源(json动画文件，图片文件等)

目录结构：

所有主题默认继承base，如果存在同名的就覆盖base里面的配置，其中比较特殊的是files下有sprites目录，这个目录下面每个文件夹都会被自动打包成一张图片，最后处理完所有资源后会生成d.ts和json两个文件。项目中实现了一个资源替换的模块统一处理了游戏内皮肤替换和H5皮肤替换

至此，一个使用 react 开发前端营销游戏的架子就完整的搭建起来了。基本满足我们的诉求

团队成员没有游戏开发经验如何快速上手开发游戏
已有前端资产如何和游戏打通
能支撑业务长期迭代

文档

https://juejin.im/post/5c563a4ef265da2ddb293ba3#heading-2 https://github.com/Zainking/LearningPixi#takingitfurther https://reactpixi.org/components/container#props

typescript高级用法梳理

Thu, 08 Aug 2019 22:26:30 GMT

infer 最早出现在 PR 中，表示在 extends 条件语句中待推断的类型变量。

比如 2.8中内置的ReturnType可以用于提取函数类型的返回值类型

type ReturnType<T> = T extends (...args: any[]) => infer P ? P : any;

-? 将代表可选项的 ? 去掉

type Required<T> = { [P in keyof T]-?: T[P] };

类似地还可以对 readonly 进行加减. 以下代码的作用就是将 T 的所有属性的 readonly 移除,你也可以写一个相反的出来.

type Mutable<T> = {
  -readonly [P in keyof T]: T[P]
}

inversify学习

Sat, 01 Jun 2019 21:36:41 GMT

container

scope

这个 scope 的wiki没有太讲清楚， request_scope.test 这个单测基本说的就很明白了

TransientScope 所有的都是新的，这个很好理解

SingletonScope 顾名思义单例模式，所有通过容器获取到的实例都是同一个

RequestScope 同一个对象里面的是同一个(除非用tag或者targetName限制住)

targetName 和 tagged

targetName不能传参，tagged注解的时候可以加参数

国际化-RTL

Sun, 26 May 2019 23:00:00 GMT

背景

今天看到一个TS的写法

enum SOME_ENUM {
A = 1,
B = 2
}
type CodeType = typeof SOME_ENUM[keyof typeof SOME_ENUM];
type CodeType1 = (typeof SOME_ENUM)[keyof typeof SOME_ENUM];

这两个等价么？发现对这两个操作符的认识还是不够，于是做了整理如下

1. `keyof` 的作用

获取对象类型的键的联合类型：

    interface Person {
      name: string;
      age: number;
    }
    type PersonKeys = keyof Person; // "name" | "age"

这常用于限制函数参数必须为对象的有效键：

function getProperty<T, K extends keyof T>(obj: T, key: K) {
  return obj[key];
}

2. `typeof` 的作用

获取变量或表达式的类型：

const person = { name: "Alice", age: 30 };
type PersonType = typeof person; // { name: string; age: number }

这在避免重复定义类型时非常有用，尤其是当变量结构复杂时。

3. 结合使用 `keyof` 和 `typeof`

动态生成键的联合类型：

const config = { host: "localhost", port: 8080 };
type ConfigKeys = keyof typeof config; // "host" | "port"

当 config 结构变化时，ConfigKeys 会自动更新。

4. 典型应用场景

类型安全的对象操作：限制函数只能访问对象的有效属性，避免拼写错误：

const obj = { id: 1, value: "test" };
function logKey(key: keyof typeof obj) {
	console.log(obj[key]);
}
logKey("id");    // 正确
logKey("name");  // 错误：类型不匹配

映射类型和工具类型： keyof 常用于构建映射类型，如内置的 Partial<T> 或自定义类型：

type Readonly<T> = {
    readonly [K in keyof T]: T[K];
};

枚举键的提取：获取枚举类型的键名字符串联合：

enum Direction { Up, Down }
type DirectionKeys = keyof typeof Direction; // "Up" | "Down"

5. 注意事项

联合类型的 keyof：对联合类型使用 keyof 会得到所有成员键的联合：

type A = { a: string } | { b: number };
type Keys = keyof A; // "a" | "b"

typeof 的上下文区分：在类型上下文中使用 typeof（提取类型），而非值上下文中的 JavaScript typeof（返回类型字符串）

总结

keyof：从类型中提取键的联合类型，增强属性访问的安全性。
typeof：从值中提取类型，避免重复定义类型。
联合使用：动态生成与变量结构一致的键类型，提升代码可维护性。

推进工作的方法论之PDCA循环

Wed, 13 Feb 2019 22:00:00 GMT

意义

每一项工作，都是一个pdca循环，都需要计划、实施、检查结果，并进一步进行改进，同时进入下一个循环，只有在日积月累的渐进改善中，才可能会有质的飞跃，才可能取得完善每一项工作

细则

Plan：制定目标与计划；
Do：任务展开，组织实施；
Check：对过程中的关键点和最终结果进行检查；
Action：纠正偏差，对成果进行标准化，并确定新的目标，制定下一轮计划。

参考

http://wiki.mbalib.com/wiki/%E6%88%B4%E6%98%8E%E5%BE%AA%E7%8E%AF

RASCI模型

Wed, 13 Feb 2019 22:00:00 GMT

在快速发展的过程中，会不时的冒出一些之前没有明确界定的事情，往往产生一些看似大家都在负责，事实上无人负责的事情。RACI 模型对快速发展的我们的最重要的启发是：每件事都要尽早确定谁负责，也就是确定主 R。


谁负责（R = Responsible）	负责执行任务的角色，具体负责操控项目、解决问题。
谁批准（A = Accountable）	对任务负全责的角色，只有经其同意或签署之后，项目才能得以进行。
谁支持（S = Support）	参与具体任务，协助R完成工作的角色。
咨询谁（C = Consulted）	在任务实施前或中提供指定性意见的人员。
告知谁（I = Informed）	及时被通知结果的人员，不必向其咨询、征求意见。

参考

MECE-金字塔原理

Tue, 12 Feb 2019 22:00:00 GMT

7个问题理解《金字塔原理》：

什么是金字塔原理？

一件事情可归纳出一个中心论点，而这个中心论点可以由3-7个论据进行支撑；

每一个论据本身又可作为一个论点，同样被3-7个论据支撑…

如此重复往返，就形成金字塔一样的结构。

使用金字塔原理要注意哪些关键点？

①结论先行：原因：符合人类大脑运作方式，你的逻辑更容易被理解，信息传达量最足。如果大脑提前了解一个结论，那么它就会自动地把接下来获得的相关信息放在这个论点下与之寻找联系。

②每个论据不要超过7条大脑无法同时记住超过7件事，如果论据超过了5条，最好就要抽象到不同类别，拆分成2层结构。

③每个论点要清晰准确论点清晰，有明确思想。要让他人一看，就知道你要表达什么。

组织思想的四个逻辑顺序分别是什么？

①时间顺序：按先后 ②空间顺序：按结构 ③重要性顺序：按优先级 ④逻辑演绎顺序：按三大段

为什么每条论据需要符合MECE法则？

ME（Mutually Exclusive）：相互独立，不重叠，分清 CE（Collectively Exhaustive）：完全穷尽，无遗漏，分净一个问题，如果做到MECE，则可以完整清晰地呈现出这个问题的各个方面，从而有机会彻底、有效地应对解决过程中遇到的情况。

如何做到MECE？

①拿到一个问题，先往高抽象一层，看顶层的属性是什么，然后再回看具体问题 [ 王者荣耀-游戏；商家发券-营销 ] ②用不断否定法。 [ 比如分析海底捞，海底捞卖的是什么？火锅。如果不是火锅呢？服务。如果是不服务呢？地理位置… ]

让别人对你的观点感兴趣的SCQ法如何操作

利用讲故事的方法：SCQ，利用大脑对已认定的事实产生的冲突带来的好奇心。 S（Situation）：背景。关键点是寻求认同。介绍一个观点，分析一个问题之前，先讲大家都共同认可的信息。 C（Complication）：冲突。发生了什么，从而产生了差异，引起了冲突。 Q（Question）：疑问。让人心里一直想着为什么，怎么办。

金字塔原理的局限性在哪里

①金字塔原理只是用树状结构重新定义了问题，简单形成因果关系，而真实世界的问题，往往要素之间是互相影响的形成网状结构，需要在金字塔基础上，运用系统性思维去思考解决问题的方法（罗斯福炉边谈话，毛主席对战争的理解）。 ②金字塔原理偏静态，而很多问题的形成往往看似静态，实则是动态形成的平衡。

SWOT分析法

Tue, 12 Feb 2019 21:00:00 GMT

SWOT 分析是一种战略规划方法，用于帮助个人或组织识别其优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）和威胁（Threats）。这个框架是通过对以上四个方面进行评估，以了解一个项目、产品、业务或个人的当前状态和潜在发展。以下是SWOT四个方面的具体描述：

优势(Strengths)：这些是个人、组织或项目在内部具有的优点，这些优点可以帮助达到目标。这可能包括专业技能、资金、人才、技术、品牌优势等。
劣势(Weaknesses)：这些是个人、组织或项目在内部的缺点或者不足，可能会阻碍目标的实现。这可能包括缺乏资金、技能不足、内部流程问题等。
机会(Opportunities)：这些是个人、组织或项目在外部环境中可能利用的有利条件，可以帮助达到目标。这可能包括市场趋势、技术发展、政策变化等。
威胁(Threats)：这些是个人、组织或项目在外部环境中可能面临的挑战或风险，可能会阻碍目标的实现。这可能包括竞争压力、市场变化、政策风险等。

进行SWOT分析时，通常会绘制一个四格矩阵，然后在每个格子里列出对应的优势、劣势、机会和威胁。这样可以帮助我们更好地了解当前的情况，制定出更合适的战略或方案。

5WHY分析法

Mon, 11 Feb 2019 22:00:00 GMT

简介

COE复盘时经常会提到5why分析法，又称“5问法”，其实就是对一个问题点连续以5个“为什么”来自问，以追究其根本原因。虽为5个为什么，但使用时不限定只做“5次为什么的探讨”，主要是必须找到根本原因为止，有时可能只要3次，有时也许要10次，如古话所言：打破砂锅问到底。 5why法的关键所在：鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱，从结果着手，沿着因果关系链条，顺藤摸瓜，直至找出原有问题的根本原因。

实施方法

5WHY从三个层面来实施：

为什么会发生？从“制造”的角度。
为什么没有发现？从“检验”的角度。
为什么没有从系统上预防事故？从“体系”或“流程”的角度。

每个层面连续5次或N次的询问，得出最终结论。只有以上三个层面的问题都探寻出来，才能发现根本问题，并寻求解决。

案例

丰田汽车公司前副社长大野耐一曾举了一个例子来找出停机的真正原因问题一：为什么机器停了？答案一：因为机器超载，保险丝烧断了。问题二：为什么机器会超载？答案二：因为轴承的润滑不足。问题三：为什么轴承会润滑不足？答案三：因为润滑泵失灵了。问题四：为什么润滑泵会失灵？答案四：因为它的轮轴耗损了。问题五：为什么润滑泵的轮轴会耗损？答案五：因为杂质跑到里面去了。经过连续五次不停地问“为什么”，才找到问题的真正原因和解决的方法，在润滑泵上加装滤网。如果员工没有以这种追根究底的精神来发掘问题，他们很可能只是换根保险丝草草了事，真正的问题还是没有解决

其他

根本原因分析（Root Cause Analysis，简称 RCA）是一种问题解决方法，它的目标是确定并解决问题的根本原因，而不仅仅是处理问题的表面症状。根本原因分析的主要目的是防止问题再次发生。

在进行根本原因分析时，你需要反复问“为什么”问题，以便深入到问题的核心。例如，如果你的网站突然出现故障，你可能首先会问：“为什么网站无法访问？”可能的答案是服务器出了问题。然后你需要继续问：“为什么服务器出了问题？”可能的答案是硬盘满了。然后你再问：“为什么硬盘满了？”可能的答案是日志文件过大。这样，你就找到了问题的根本原因，也就是日志文件过大导致硬盘满了，进而导致服务器出问题，最后导致网站无法访问。

有几种常见的根本原因分析方法，包括5 Why（五次为什么）、鱼骨图（也称为因果图或者石川图）、故障树分析等。这些方法都有其特点，可以根据问题的实际情况选择最合适的方法。

需要注意的是，根本原因分析并不总是一个直线过程，可能需要反复迭代和探索才能找到真正的根本原因。另外，一些复杂的问题可能有多个根本原因，需要分别处理。

5WHY分析法

Mon, 11 Feb 2019 22:00:00 GMT

算法题-24点

Mon, 07 May 2018 16:22:01 GMT

题目

从 1~13 任取四个数字，通过+，-，* ，/和() 来计算 24 点

其实这个是算法分析里面提到过的一个标准做法，使用的方式是逆波兰表达式，也就是后缀表达式首先把全部运算情况的逆波兰表达式穷举出来，采用逆波兰表达式是因为不用考虑操作符的优先级. 24 点的逆波兰表达式总共有如下 4 种情况. 其中 abc 的代表 4 个数字 #代表+-*/任意一个操作符.

ab#cd##
abc##d#
abcd###
ab#c#d#

后面就是遍历这四个数字的全排列和操作符的全排列即可，其中数字不可以重复使用，操作符可以重复使用

代码

function calculate(a, b, operator) {
  switch (operator) {
    case "+":
      return a + b
    case "-":
      return a - b
    case "*":
      return a * b
    case "/":
      return b === 0 ? -10 : a / b
    default:
      return -10
  }
}

function equalTo24(...nums) {
  let result = 0,
    result1 = 0
  const operators = ["+", "-", "*", "/"]

  for (let i1 = 0; i1 < 4; i1++) {
    for (let i2 = 0; i2 < 4; i2++) {
      if (i1 === i2) continue
      for (let i3 = 0; i3 < 4; i3++) {
        if (i3 === i1 || i3 === i2) continue
        let i4 = 6 - i1 - i2 - i3
        for (let o1 = 0; o1 < 4; o1++) {
          for (let o2 = 0; o2 < 4; o2++) {
            for (let o3 = 0; o3 < 4; o3++) {
              // ab#cd##
              result = calculate(nums[i1], nums[i2], operators[o1])
              result1 = calculate(nums[i3], nums[i4], operators[o2])
              result = calculate(result, result1, operators[o3])
              if (result === 24)
                return `(${nums[i1]}${operators[o1]}${nums[i2]})${operators[o3]}(${nums[i3]}${operators[o2]}${nums[i4]})`
              // abc##d#
              result = calculate(nums[i2], nums[i3], operators[o1])
              result = calculate(nums[i1], result, operators[o2])
              result = calculate(result, nums[i4], operators[o3])
              if (result === 24)
                return `(${nums[i1]}${operators[o2]}(${nums[i2]}${operators[o1]}${nums[i3]}))${operators[o3]}${nums[i4]}`
              // abcd###
              result = calculate(nums[i3], nums[i4], operators[o1])
              result = calculate(nums[i2], result, operators[o2])
              result = calculate(nums[i1], result, operators[o3])
              if (result === 24)
                return `${nums[i1]}${operators[o3]}(${nums[i2]}${operators[o2]}(${nums[i3]}${operators[o1]}${nums[i4]}))`
              // ab#c#d#
              result = calculate(nums[i1], nums[i2], operators[o1])
              result = calculate(result, nums[i3], operators[o2])
              result = calculate(result, nums[i4], operators[o3])
              if (result === 24)
                return `((${nums[i1]}${operators[o1]}${nums[i2]})${operators[o2]}${nums[i3]})${operators[o3]}${nums[i4]}`
            }
          }
        }
      }
    }
  }
  return "It's not possible!"
}

算法题-螺旋化

Sun, 06 May 2018 23:46:37 GMT

原题如下

Your task, is to create a NxN spiral with a given size.

For example, spiral with size 5 should look like this:
00000
....0
000.0
0...0
00000
and with the size 10:
0000000000
.........0
00000000.0
0......0.0
0.0000.0.0
0.0..0.0.0
0.0....0.0
0.000000.0
0........0
0000000000
Return value should contain array of arrays, of 0 and 1, for example for given size 5 result should be:
[
  [1, 1, 1, 1, 1],
  [0, 0, 0, 0, 1],
  [1, 1, 1, 0, 1],
  [1, 0, 0, 0, 1],
  [1, 1, 1, 1, 1]
]
Because of the edge-cases for tiny spirals, the size will be at least 5.

General rule-of-a-thumb is, that the snake made with ‘1’ cannot touch to itself.

这个费了半天时间弄了个超级复杂的解答，但是看到最佳答案的时候我都蒙了

function spiralize(size) {
  if (size == 2)
    return [
      [1, 1],
      [0, 1],
    ]
  if (size == 3)
    return [
      [1, 1, 1],
      [0, 0, 1],
      [1, 1, 1],
    ]
  var base = spiralize(size - 2)
  var res = [[], []]
  for (var i = 0; i < size; i++) {
    res[0].push(1)
    res[1].push(0)
  }
  res[1][size - 1] = 1
  for (var i = size - 3; i >= 0; i--) {
    res.push(base[i].reverse().concat([0, 1]))
  }
  res[size - 1][size - 2] = 1
  return res
}

递归来做，想都没往这个方向想

留下一个其他人的回复

Woah! it’s an art! :)

小程序实时日志

Tue, 01 May 2018 20:10:00 GMT

背景

小程序开发的过程中，我们遇到一个比较麻烦的问题，在真机调试的时候是看不到日志的。本来我们只需要支持美团小程序，这个情况还可以通过VConsole来处理，但是后面我们开始支持美团小程序开发的时候，因为机制问题没有支持service里面的日志没有打印出来，就这个问题就很麻烦了。

另外很多时候我们需要查看网络请求具体的内容和返回，copy为curl 和后端联调，这个目前就都没有什么方案，所以我们开始想弄一个实时日志的功能。

因为我没来做新零售之前负责大象实时协作文档的架构与研发，所以这个工具做起来还是比较轻松的，完全可以复用整个实时协作的基础设施，只需要考虑如何将小程序接入以及如何后台展示即可。

整体设计

在小程序端上提供统一的日志模块，将所有被记录的日志放到日志缓冲池里面，这样在APP刚启动还没有建立长连接之前的日志不会丢失，然后通过长连SDK来消费缓冲池里面的日志数据。

这里面有一个需要思考的是传递给服务端的包信息要如何设计，ha

需要解决两个问题，一个是日志如何

参考资料

DI&IOC基本概念

Tue, 01 May 2018 14:00:00 GMT

DI 和 IOC 的关系

DI（依赖注入）和 IOC（控制反转）是两个相关但不完全相同的概念。控制反转（IOC）是一种设计原则，它强调将控制权从应用程序代码中转移到外部容器或框架中。根据 IOC 原则，应用程序的组件不应该负责自己的依赖关系的解析和管理，而是将这些责任交给外部的容器。通过 IOC，应用程序的组件变得松耦合，可以更容易地被替换、重用和测试。

依赖注入（DI）是实现IOC的一种具体方式。DI是一种将依赖关系注入到组件中的机制，以解耦组件与其依赖的创建和管理。通过DI，依赖关系不是由组件自身来创建和解析，而是由外部的注入器或容器来处理。这意味着组件不需要关心如何获取它所依赖的对象，而只需要声明它所需要的依赖，并让容器负责注入。

因此，DI 是 IOC 的一种实现方式，通过依赖注入实现了控制反转的原则。DI 框架和容器负责在应用程序中管理组件的依赖关系，根据组件的声明和配置，自动注入所需的依赖。通过使用 DI 和 IOC，可以实现松耦合、可测试和可维护的应用程序架构。

IOC 基本概念

组件（Component）：组件是应用程序的构建块，可以是类、对象、服务或其他可被管理的实体。
容器（Container）：容器是IOC框架的核心，负责创建和管理组件。它通过读取配置信息和应用程序代码，解析和创建组件的实例，并解决它们之间的依赖关系。
注册（Registration）：注册是将组件与容器关联的过程。通常在配置文件或代码中指定组件的类型、名称、依赖关系等信息。
解析（Resolution）：解析是指容器根据注册信息，创建并返回请求的组件实例的过程。解析可能涉及创建新的对象实例，或返回现有的单例对象。
依赖注入（Dependency Injection）：依赖注入是IOC的重要特征，它是指容器自动将组件所依赖的其他组件注入到目标组件中的过程。依赖可以通过构造函数、属性或方法参数等方式注入。
生命周期管理（Lifecycle Management）：IOC框架通常提供生命周期管理功能，用于创建、初始化、销毁组件。可以定义各种生命周期事件（如初始化、销毁），并由容器在适当的时间触发。
作用域（Scope）：作用域定义了组件的生命周期范围。常见的作用域包括单例（Singleton）作用域，每次请求都返回同一个实例；原型（Prototype）作用域，每次请求都创建一个新的实例；会话（Session）作用域等。
配置（Configuration）：IOC框架通常需要配置信息，如组件的注册信息、依赖关系、作用域设置等。配置可以通过XML、注解或其他方式提供。
AOP（Aspect-Oriented Programming）：AOP是一种与IOC常一起使用的编程范式，用于实现横切关注点的分离。AOP允许在不改变组件代码的情况下，通过切面来实现跨组件的功能，如日志记录、事务管理等。

DI 基本概念

在软件开发中，依赖注入（Dependency Injection，DI）是一种设计模式，用于管理组件之间的依赖关系。实现一个 DI 框架需要涉及以下几个概念：

组件（Component）：组件是应用程序的构建块，可以是类、对象、服务或其他可被注入的实体。
依赖（Dependency）：依赖是组件与其他组件之间的关系，表示一个组件需要使用或依赖其他组件的功能。
注入器（Injector）：注入器是DI框架的核心，负责创建和管理组件的实例以及解决它们之间的依赖关系。
注入点（Injection Point）：注入点是组件中用于接收依赖的地方，通常通过构造函数、属性或方法参数来定义。
注入策略（Injection Strategy）：注入策略定义了如何将依赖注入到组件中。常见的注入策略包括构造函数注入、属性注入和方法注入。
生命周期管理（Lifecycle Management）：DI框架可以提供组件的生命周期管理功能，包括创建、销毁和释放资源等操作。
作用域（Scope）：作用域定义了组件的生命周期范围，例如单例作用域、原型作用域等。不同的作用域决定了组件的创建和销毁时机。
配置（Configuration）：DI框架通常需要一些配置信息，如组件的依赖关系、作用域设置、注入策略等。
AOP（Aspect-Oriented Programming）：AOP是一种编程范式，可用于在DI框架中实现横切关注点的分离，例如日志、事务管理等。

控制反转（IOC）其他实现方式

虽然依赖注入是实现IOC的一种常见方式，但并不是唯一的方式。不同的实现方式适用于不同的场景和需求，选择合适的实现方式取决于具体的应用程序架构和开发环境。

服务定位器模式（Service Locator Pattern）：服务定位器模式是通过一个中心注册机制来获取所需要的服务。首先，所有的服务都在服务定位器中注册，然后当需要某个服务时，通过服务定位器来查找并获取。虽然这种方式可以实现IOC，但因为服务定位器往往隐藏了类之间的依赖关系，因此并不像DI那样推荐。
工厂模式（Factory Pattern）：工厂模式是创建对象的一种最常见的方法，通过工厂类可以返回需要的实例，而不需要关心具体的实现。这样也可以实现IOC，即不直接在类中创建对象，而是通过工厂类来获取。不过工厂模式通常需要手动管理对象的生命周期，所以在某些情况下可能会比DI更复杂。
模板方法模式（Template Method Pattern）：在模板方法模式中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种模式主要解决方法的执行顺序问题。
策略模式（Strategy Pattern）：策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。在策略模式中，上下文（Context）不应知道正在使用哪个策略，策略和上下文都不应知道彼此的实现细节。

基于canvas 实现 excel

Sat, 21 Apr 2018 22:00:00 GMT

小程序工程化-构建工具：重新定义小程序开发体验

Sat, 21 Apr 2018 22:00:00 GMT

MT内部已经广泛使用，目前已开源

详情参考官网： https://ximing.github.io/mpbuild/ Github: https://github.com/ximing/mpbuild

背景

在小程序开发的实践中发现传统构建工具在小程序场景下的水土不服。小程序有着独特的架构设计和运行机制，它既不是传统的单页应用，也不是常见的多页应用，而是一个全新的应用形态。目前业界内的各种方案不是很好的能解决痛点问题

痛点分析：现有方案的局限性

1. 微信开发者工具原生方案

现状： 绝大多数小程序项目仍在使用微信开发者工具的原生构建能力。

痛点：

仅支持基础的 npm 包处理，无法满足现代前端开发的工程化需求
不支持 TypeScript、Sass/Less 等预处理器
缺乏代码分割和依赖优化能力
无法接入现有的前端工程化生态

2. 基于 Gulp 的解决方案

现状： 部分团队选择基于 Gulp 构建针对小程序的工作流。

优势：

实现简单，学习成本低
可以针对 js、wxml、wxss、json 四种文件类型分别处理
能够复用一些开源的处理插件

痛点：

依赖分析不精准：无法准确分析模块依赖关系，容易产生冗余代码
扩展性差：难以适应复杂的业务场景和技术演进
同构能力缺失：当需要小程序同构到 Web 时，现有工作流无法复用

3. 基于 Webpack 插件的方案

现状： 一些团队尝试通过 Webpack 插件来适配小程序开发。

优势：

强大的依赖分析能力
丰富的 loader 和 plugin 生态
成熟的代码分割和优化策略

痛点：

理念冲突：Webpack 本质上是 bundle 工具，而小程序采用原生的分包策略，两者理念不匹配
适配复杂：需要大量的配置和 hack 来适配小程序的特殊需求
性能开销：过度的 bundle 处理反而影响小程序的启动性能

设计理念：专为小程序而生

基于对现有方案的深入分析，提出了 mpbuild 的核心设计理念：

1. 原生优先 (Native First)

小程序有着独特的文件结构和运行机制，我们不应该强行套用 Web 开发的模式，而应该：

尊重小程序的原生分包策略，不进行不必要的 bundle
保持文件的语义化，确保构建后的代码结构清晰可读
优化而非重构，在保持原有开发体验的基础上增强工程化能力

2. 插件化架构 (Plugin Architecture)

构建一个高度可扩展的插件系统：

核心最小化：核心只负责文件处理流程，具体的转换逻辑由插件完成
插件标准化：定义统一的插件接口，确保生态的一致性
生态开放：尽可能使用社区已有的生态，不重复造轮子

3. 同构支持 (Isomorphic Support)

为未来的多端统一做好准备：

代码复用：相同的业务逻辑可以在小程序和 Web 端复用
构建统一：通过配置切换，实现一套代码多端构建
渐进式迁移：支持项目逐步从小程序独立开发转向多端统一

技术实现：精准而高效

依赖分析引擎

mpbuild 内置了专门针对小程序的依赖分析引擎：

静态分析：通过 AST 解析准确识别模块依赖
动态依赖：支持识别 require() 动态导入
资源依赖：自动分析图片、字体等静态资源依赖关系

文件处理流水线

采用流式处理机制，确保构建性能：

增量构建：只处理变更的文件，大幅提升构建速度
并行处理：多文件类型并行处理，充分利用多核性能
缓存机制：智能缓存中间结果，避免重复计算

生态集成能力

无缝集成前端生态：

JavaScript 生态：支持 Babel、TypeScript、ESLint 等
样式处理：支持 PostCSS、Less、Sass 等预处理器
代码质量：集成 Prettier、ESLint、Stylelint 等工具

开发体验的重新定义

开箱即用 (Zero Configuration)

智能配置：基于项目结构自动推断配置
最佳实践：内置业界最佳实践，开发者无需关心复杂配置
渐进式配置：支持按需自定义，满足复杂项目需求

开发效率提升

错误提示：友好的错误提示和解决建议
性能监控：内置构建性能分析，帮助优化构建流程

面向未来的架构设计

多端统一的准备

mpbuild 从设计之初就考虑了多端统一的需求：

抽象层设计：通过抽象层隔离平台差异
适配器模式：不同平台使用不同的适配器
配置驱动：通过配置文件控制不同平台的构建逻辑

生态扩展性

插件市场：计划建设插件市场，促进生态发展
社区驱动：鼓励社区贡献，形成良性循环
标准制定：参与制定小程序工程化标准

结语

mpbuild 不仅仅是一个构建工具，更是对小程序工程化的一次深度思考。我们希望通过这个项目，能够推动整个小程序生态的工程化进程，让开发者能够更专注于业务逻辑的实现，而不是工程化的繁琐配置。

小程序开发，理应更加优雅。

实时协作文档复盘

Fri, 02 Mar 2018 22:00:00 GMT

马上要转战新零售的业务了，大象商业化即将暂停，是要对着半年做的文档事情做一个总结了，凝结了很多的心血在这个业务中

待续…

实时协作-01

Tue, 07 Nov 2017 22:34:06 GMT

最近在负责大象团队的创新业务，主打多人实时协作的文档，有富文本，Excel，脑图，流程图，markdown五种文档的需求。这类的业务其实在前端领域是比较复杂的，主要有两点

编辑器本身开发就很复杂
整个协作模型是很麻烦的一个东西，稍微不对整个协作结果就完全错了，这是不可以接受的。

针对编辑器我这主要开发的就是富文本，Excel 和 markdown 三个，另起文章来解释，除了总会发现 chrome 浏览器的 bug。主要说一下实时协作。

协作目前比较靠谱的方案有两种一种是Operational Transformation(后文简称OT)，一种是CRDT。Google Doc应该是最开始大规模商业应用实时协作文档的，他们是基于OT研发的，所以后面市面上大部分的协作产品都是基于OT来开发的，这两个方式其实没有太大的区别，CRDT里也有基于Op的，不过CRDT在对等网络中比OT更合适。

OT整体来讲是需要一个中央服务器来做操作的定序的，中央服务器会将所有客户端的并发操作按照次序依次应用到文档(快照)上，其实和区块链的

前端状态管理思考与实践

Mon, 11 Sep 2017 21:00:00 GMT

目前已开源 rab 仓库文档传送门

背景

再过去的两年我一直在维护大量的 OA 应用，所以在 redux 的基础上封装了路由，订阅器，action 生命周期等功能，方便各个 OA 系统开箱即用使用。一个极简的 demo 如下：注: 其中的 reducers 有 start，next，throw，finish 四个生命周期，方便进一步简化 redux 异步处理的情况下的样板代码

import React from 'react';
import rab, {connect, createModel, put, call} from 'rab';
import {Router, Route} from 'rab/router';

function stop(time) {
    return new Promise((res, rej) => {
        setTimeout(function () {
            res();
        }, 2000);
    });
}

const app = rab();

// 2. Model
let count = createModel({
    namespace: 'count',
    state: {
        num: 0,
        loading: false
    },
    reducers: {
        add(state, action) {
            console.log(action.payload);
            return Object.assign({}, state, {num: state.num + 1})
        },
        asyncAdd(state, action) {
            return Object.assign({}, state, {num: state.num + action.payload})
        },
        asyncMinus: {
            start(state, action){
                return Object.assign({}, state, {loading: true});
            },
            next(state, action){
                return Object.assign({}, state, {num: state.num + action.payload})
            },
            throw(state, action){
                return Object.assign({}, state, {num: state.num + action.payload})
            },
            finish(state, action){
                return Object.assign({}, state, {loading: false});
            }
        }
    },
    actions: {
        asyncAdd: (a, b, c) => async ({getState, dispatch}) => {
            await stop();
            return 100;
        },
        async asyncMinus() {
            await stop();
            return -100;
        }
    },
    subscriptions: {
        init({history, dispatch}){
            history.listen((location) => {
                console.log('init------------>', location)
            })
        }
    }
})

app.addModel(count);

// 3. View
const App = connect(({count}) => ({
    count
}))((props) => {
    return (
        <div>
            <h2>{ props.count.num }</h2>
            <h2>{ !props.count.loading ? 'finish' : 'loading' }</h2>
            <button key="add" onClick={() => {
                put({type: 'count.add', payload: {a: 1}});
            }}>+
            </button>
            <button key="asyncadd" onClick={() => {
                props.dispatch(count.actions.asyncAdd());
            }}>ASYNC ADD
            </button>
            <button key="asyncminus" onClick={() => {
                put({type: 'count.asyncMinus', payload: {a: 1, n: 2}});
            }}>ASYNC Minus
            </button>
        </div>
    );
});

// 4. Router
app.router(({history}) => {
    return (
        <Router history={history}>
            <Route path="/" component={App}/>
        </Router>
    );
});

// 5. Start
app.start('#demo_container');

问题

在今年开始，我主要负责实现一系列的大象富应用，如实时协作的 excel，word，ppt，脑图等等。考虑到后期的维护性，我们全面拥抱了 TS ，这时候发现之前的状态管理存在一些问题：

存在字符串进行 dispatch 的情况，如上面例子中第 57 行的 count.asyncMinus
整体集成方式过于耦合，在富应用的开发环境下，我们更希望能基于依赖注入的方式将各个模块解耦
局部状态过于复杂，在实际应用开发过程中，会发现存在很多局部的 UI 状态，这些是和业务建模相关的数据无关的，但是由于我们组件化拆分的比较彻底，就会导致如果不放在全局统一的数据源下，就需要层层的 props 进行传递，代码的维护性和可读性都会有影响
需要自行的处理

实时协作算法基本类型

Sat, 01 Jul 2017 02:10:00 GMT

偏序、因果关系、并发关系

操作间的偏序最早源于 Lamport 事件偏序关系，即 happened before 和 concurrent 的逻辑时钟（Logical Clocks）。基于 Lamport 的偏序事件关系，协同编辑系统中的因果关系和并发关系，可以理解为定义1 和定义2。

基本定义

定义 1. 因果关系

给定任意两个分别位于站点 i 和站点 j 的操作 Oa 和 Ob，称 Oa 和 Ob 存在因果关系（记做 Oa→Ob），当且仅当 Oa 和 Ob 满足下列三个条件之一：

i=j，Oa 发生在 Ob 之前
i≠j，Oa 在站点 j 的执行先于 Ob 的产生
存在操作 Oc，有 Oa→Oc 并且 Oc→Ob

定义 2. 并发关系

给定任意两个操作 Oa 和 Ob，称 Oa 和 Ob 存在并发关系（记做 Oa || Ob），当且仅当 Oa 和 Ob 既不满足 Oa→Ob，又不满足 Ob→Oa。

定义 3. 简单并发关系

当满足并发关系的两个操作 Oa 和 Ob 产生于相同的文档状态时，称 Oa 和 Ob 是简单并发关系。

定义 4. 偏并发关系

当满足并发关系的两个操作 Oa 和 Ob 产生于不同的文档状态时，称 Oa 和 Ob 是偏并发关系。

✨ 具体例子：协同文档编辑

假设有两个用户Alice和Bob正在协同编辑一个文档，初始文档内容为：“Hello”

场景1：因果关系

Alice在位置5插入” World”，文档变为”Hello World”
Bob看到Alice的操作后，在位置11插入”!”，文档变为”Hello World!”
这里Bob的操作→Alice的操作，存在因果关系

场景2：并发关系

Alice在位置5插入” World”
Bob同时在位置0插入”Hi ”
两个操作并发产生，互不知晓对方的存在，存在并发关系

关系图示例

graph TD
    subgraph "站点A (Alice)"
        A1["O1: Insert 'World' at pos 5<br/>SV: (1,0)"]
        A2["O3: Insert '!' at pos 11<br/>SV: (2,1)"]
    end

    subgraph "站点B (Bob)"
        B1["O2: Insert 'Hi ' at pos 0<br/>SV: (0,1)"]
        B2["O4: Insert '...' at pos 15<br/>SV: (2,2)"]
    end

    A1 --> A2
    A1 --> B2
    B1 --> B2

    A1 -.->|"并发关系 ||"| B1
    A2 -.->|"并发关系 ||"| B1

    style A1 fill:#e1f5fe
    style A2 fill:#e1f5fe
    style B1 fill:#fff3e0
    style B2 fill:#fff3e0

图说明：

实线箭头表示因果关系（happened-before）
虚线表示并发关系（concurrent）
SV表示状态向量（State Vector）
O1→O3, O1→O4, O2→O4 为因果关系
O1||O2, O2||O3 为并发关系

图 1 用时空图（time-space)给出操作之间的因果和并发关系。其中：

O1 与 O2、O1 与 O3 为因果关系
O2 与 O3、O1 与 O4、O2 与 O4、O3 与 O4 为并发关系
O2 与 O3、O1 与 O4 为简单并发关系
O2 与 O4、O3 与 O4 为偏并发关系

图 2 采用因果执行图（Causally Executable Graph）给出操作之间的因果和并发关系。图中的顶点表示各站点产生的操作，操作之间的有向边表示操作的因果关系，其中，有向边的起点是有向边终点的因操作。操作之间的无向边表示操作的并发关系，包括简单并发关系和偏并发关系。如图 2 所示：O1→O2，O1→O3，O2||O3，O1||O4，O2||O4，O3||O4。

全序

相比偏序关系定义的客观性，全序关系的定义更依赖于某种”假设”。例如，Lamport 提出的全序关系，如果逻辑时钟相等，假设可以通过进程 ID 号来确定次序，从而得到一种全序关系。类似地，实时协同编辑算法采用不同假设和策略来定义全序，基于某种”假设”来对操作或者操作对象进行定序。

操作的全序

操作的全序是给实时协同编辑系统中产生的所有操作赋予唯一的全局次序，并按照全序进行操作转换或按照全序执行。操作的全序有两类具体方法。

分布式全序

代表性的方法有：

GOT 算法：基于 SV 和站点编号（siteID）定义了操作间的一种全序
TIBOT/TIBOT2.0：以线性的时间间隔 TI（Time Interval）和 siteID 来定义操作间的全序

📋 GOT 算法详解

GOT（Generic Operational Transformation）算法 是一种基于分布式全序的经典操作转换算法，由 Sun 和 Chen 在 2002 年提出。

核心思想

GOT 算法通过状态向量（State Vector, SV）和站点编号（siteID）来定义操作间的全序关系，确保所有站点上的操作按照相同的顺序执行，从而保证最终一致性。

状态向量定义

状态向量 SV：一个长度为 n 的整数数组，其中 n 是系统中站点的总数。

SV[i] 表示当前站点已知的站点 i 产生的操作数量
每个操作都有一个关联的状态向量，表示该操作产生时的系统状态

全序定义规则

对于两个操作 Op1 和 Op2，其全序关系定义为：

状态向量和比较：计算 sum(SV1) 和 sum(SV2)
优先级排序：
- 如果 sum(SV1) < sum(SV2)，则 Op1 < Op2
- 如果 sum(SV1) > sum(SV2)，则 Op1 > Op2
- 如果 sum(SV1) = sum(SV2)，则比较 siteID1 和 siteID2
  - 如果 siteID1 < siteID2，则 Op1 < Op2
  - 如果 siteID1 > siteID2，则 Op1 > Op2

算法流程示例

sequenceDiagram
    participant A as 站点A (siteID=1)
    participant B as 站点B (siteID=2)
    participant C as 站点C (siteID=3)

    Note over A,C: 初始状态: SV=(0,0,0)

    A->>A: Op1: Insert("H",0)<br/>SV=(1,0,0), sum=1
    A->>B: 发送 Op1
    A->>C: 发送 Op1

    B->>B: Op2: Insert("i",1)<br/>SV=(1,1,0), sum=2
    B->>A: 发送 Op2
    B->>C: 发送 Op2

    C->>C: Op3: Insert("!",0)<br/>SV=(1,1,1), sum=3
    Note over A,C: 全序: Op1 < Op2 < Op3<br/>(基于SV和的比较)

    Note over A,C: 最终结果: "H!i" (所有站点一致)

具体实现示例

class GOTAlgorithm {
  constructor(siteId, totalSites) {
    this.siteId = siteId;
    this.stateVector = new Array(totalSites).fill(0);
    this.operations = [];
  }

  // 产生本地操作
  generateOperation(type, content, position) {
    this.stateVector[this.siteId]++;
    const operation = {
      type,
      content,
      position,
      siteId: this.siteId,
      stateVector: [...this.stateVector], // 复制当前状态向量
      timestamp: Date.now()
    };
    this.operations.push(operation);
    return operation;
  }

  // 接收远程操作
  receiveOperation(operation) {
    this.operations.push(operation);
    // 更新状态向量
    for (let i = 0; i < this.stateVector.length; i++) {
      this.stateVector[i] = Math.max(this.stateVector[i], operation.stateVector[i]);
    }
  }

  // GOT全序比较函数
  compareOperations(op1, op2) {
    const sum1 = op1.stateVector.reduce((a, b) => a + b, 0);
    const sum2 = op2.stateVector.reduce((a, b) => a + b, 0);
    
    if (sum1 !== sum2) {
      return sum1 - sum2; // 状态向量和小的操作优先
    }
    
    // 状态向量和相等时，比较siteID
    return op1.siteId - op2.siteId;
  }

  // 获取全序排列的操作序列
  getOrderedOperations() {
    return [...this.operations].sort(this.compareOperations);
  }
}

// 使用示例
const siteA = new GOTAlgorithm(0, 3);
const siteB = new GOTAlgorithm(1, 3);
const siteC = new GOTAlgorithm(2, 3);

// 站点A生成操作
const opA = siteA.generateOperation('insert', 'H', 0);
console.log('操作A:', opA);
// 输出: { type: 'insert', content: 'H', position: 0, siteId: 0, stateVector: [1,0,0] }

// 站点B生成操作
const opB = siteB.generateOperation('insert', 'i', 1);
console.log('操作B:', opB);
// 输出: { type: 'insert', content: 'i', position: 1, siteId: 1, stateVector: [0,1,0] }

// 全序比较
console.log('A < B:', siteA.compareOperations(opA, opB) < 0); // true (sum=1 < sum=1, siteId=0 < siteId=1)

📋 TIBOT/TIBOT2.0 算法详解

TIBOT（Time Interval Based Operational Transformation）算法 是另一种分布式全序算法，通过时间间隔来定义操作的全序关系。

核心思想

TIBOT 算法使用**时间间隔（Time Interval, TI）**作为主要的排序依据，结合站点编号来确定操作的全序关系。每个操作都被分配一个时间间隔，这个时间间隔反映了操作的相对重要性和执行顺序。

时间间隔定义

时间间隔 TI：一个实数值，表示操作在时间轴上的相对位置

TI 值越小，操作的优先级越高
通过算法动态计算，确保全局唯一性

TIBOT2.0 改进

TIBOT2.0 在原有基础上进行了优化：

更精确的时间间隔分配：避免时间间隔冲突
更好的网络延迟处理：适应不同网络环境
优化的存储和传输：减少数据开销

全序定义规则

对于两个操作 Op1 和 Op2：

时间间隔比较：
- 如果 TI1 < TI2，则 Op1 < Op2
- 如果 TI1 > TI2，则 Op1 > Op2
站点ID优先级：
- 如果 TI1 = TI2，则比较 siteID1 和 siteID2
- siteID 小的操作优先

时间间隔分配算法

class TIBOTAlgorithm {
  constructor(siteId) {
    this.siteId = siteId;
    this.operations = [];
    this.currentTI = 0;
  }

  // 计算时间间隔
  calculateTimeInterval(previousTI, nextTI) {
    if (nextTI === undefined) {
      // 如果没有后续操作，TI = previousTI + 1
      return previousTI + 1;
    }
    if (previousTI === undefined) {
      // 如果没有前驱操作，TI = nextTI / 2
      return nextTI / 2;
    }
    // 在两个操作之间插入，TI = (previousTI + nextTI) / 2
    return (previousTI + nextTI) / 2;
  }

  // 生成操作
  generateOperation(type, content, position) {
    // 查找插入位置的前后操作
    const orderedOps = this.getOrderedOperations();
    let previousTI, nextTI;
    
    for (let i = 0; i < orderedOps.length; i++) {
      if (orderedOps[i].position <= position) {
        previousTI = orderedOps[i].timeInterval;
      } else {
        nextTI = orderedOps[i].timeInterval;
        break;
      }
    }

    const timeInterval = this.calculateTimeInterval(previousTI, nextTI);
    
    const operation = {
      type,
      content,
      position,
      siteId: this.siteId,
      timeInterval,
      timestamp: Date.now()
    };
    
    this.operations.push(operation);
    return operation;
  }

  // TIBOT全序比较函数
  compareOperations(op1, op2) {
    if (op1.timeInterval !== op2.timeInterval) {
      return op1.timeInterval - op2.timeInterval;
    }
    // 时间间隔相等时，比较siteID
    return op1.siteId - op2.siteId;
  }

  // 获取全序排列的操作序列
  getOrderedOperations() {
    return [...this.operations].sort(this.compareOperations);
  }

  // 接收远程操作
  receiveOperation(operation) {
    this.operations.push(operation);
  }
}

// 使用示例
const tibotA = new TIBOTAlgorithm(0);
const tibotB = new TIBOTAlgorithm(1);

// 站点A生成操作
const opA = tibotA.generateOperation('insert', 'H', 0);
console.log('TIBOT操作A:', opA);
// 输出: { type: 'insert', content: 'H', position: 0, siteId: 0, timeInterval: 1 }

// 站点B生成操作
const opB = tibotB.generateOperation('insert', 'e', 1);
console.log('TIBOT操作B:', opB);
// 输出: { type: 'insert', content: 'e', position: 1, siteId: 1, timeInterval: 1 }

// 全序比较
console.log('A < B:', tibotA.compareOperations(opA, opB) < 0); // true (TI相等时，siteId=0 < siteId=1)

TIBOT算法执行流程

graph TD
    A[产生操作] --> B[计算时间间隔TI]
    B --> C{是否有前驱操作?}
    C -->|有| D[TI = (prev_TI + next_TI) / 2]
    C -->|无| E{是否有后续操作?}
    E -->|有| F[TI = next_TI / 2]
    E -->|无| G[TI = current_TI + 1]
    D --> H[分配TI给操作]
    F --> H
    G --> H
    H --> I[广播操作到其他站点]
    I --> J[接收站点按TI和siteID排序]
    J --> K[按全序执行操作]
    K --> L[保证最终一致性]

    style A fill:#e1f5fe
    style K fill:#c8e6c9
    style L fill:#c8e6c9

算法对比总结

特性	GOT算法	TIBOT/TIBOT2.0
排序依据	状态向量和(SV sum) + siteID	时间间隔(TI) + siteID
时间复杂度	O(n) 计算SV和	O(1) TI比较
空间复杂度	O(n) 存储状态向量	O(1) 存储TI值
网络开销	传输完整状态向量	仅传输TI值
适用场景	中小规模协作	大规模分布式环境
冲突解决	基于全局状态	基于时间序列

实际应用考虑

网络延迟：TIBOT在高延迟网络环境中表现更好
可扩展性：TIBOT2.0 支持更多并发用户
存储效率：时间间隔比状态向量占用空间更少
实现复杂度：GOT概念更直观，TIBOT需要精确的时间间隔管理

集中式全序

又可分为中心服务器取全序和中心序列产生器取全序：

中心服务器取全序：将各协同站点产生的操作发送到中心服务器，中心服务器采用先进先出（First in First out）策略将接收操作序列化之后转发给其它站点，如：

Jupiter 系统
Google Wave/Docs
NICE

中心序列产生器取全序：将中心序列产生器产生的连续的正整数赋予给各站点产生的操作，如：

SOCT3/4：通过一个中心 Sequencer 定义了操作间全序

某些算法系统，例如 COT 既可采用分布式取全序，也可采用集中式取全序。

操作对象的全序

操作对象的全序指协同编辑系统中，操作对象在系统内部数据结构的全局位置 ID 标识。

协同编辑算法通过维护内部数据结构中操作对象的全序位置关系来维护共享对象的一致性。代表性算法有：

AST 算法：采用了地址空间转换技术维护每个站点字符节点间一致的顺序
ABT 家族算法：通过操作转换技术维护各站点操作对象间相同的全序位置关系
CRDT 家族算法：通过给操作对象分配全局有序的唯一 ID，并通过 ID 将操作对象全序的保存到内部数据结构中实现各站点内部数据结构中操作对象间全序的位置关系

全序假设与优先级

全序的定义，在前面若干判定条件相等情况下，往往假设可以用到优先级（Priority）定序。上述操作全序中的分布式全序方法和操作对象的全序方法，主要采用 siteID 作为优先级来对全序定义进行完备化。

具体应用实例：

GOT：当两个操作的 SV 的和相同时，siteID 小的操作全序在前
TIBOT/TIBOT2.0：当两个操作的 TI 相同时，siteID 小的操作全序在前
SDT、SDTO、LBT 及 ABT：当两个并发的插入操作在同一位置插入不同操作对象时，siteID 小的操作对象全序在前
AST：当两个插入字符的 SV 和相同时，siteID 小的插入字符位置在前
WOOT：siteID 小的操作对象全序在前
TreeDoc：当两个操作对象的逻辑时钟相同时，siteID 小的操作对象的 ID 全序小
RGA：当两个操作对象的 session 相同且 SV 的和相同时，siteID 小的操作对象的 ID 全序小

这些方法，本质上与 Lamport 的假设可以把进程 ID 号作为优先级进行全序完备化方法相似。

一致性模型

支持操作意图一致性的协同编辑算法可参照一致性模型来设计和开发。

主要一致性模型

(1) CC 模型

1996年，Ressel 在文献中明确阐述了协同编辑算法要满足两个一致性条件：

因果一致性（Causality Preservation）
结果一致性（Convergence）

并提出了 CC 模型。

(2) CCI 模型

后续研究发现 CC 模型不足以完整约束一个操作转换系统的行为。因此，Sun 在 CC 模型的基础上进行了完善，指出一个协同编辑系统除了要满足因果一致性和结果一致性外，还需要做到操作意图一致性，并给出 OT 算法应遵循的 CCI 模型：

因果一致性
结果一致性
操作意图一致性（Intention Preservation）[3, 61]

大多数算法参照 CCI 模型设计和开发的。

(3) CA 模型

CCI 模型中意图保持定义的模糊性（ambiguity），提出了可以被形式化证明的 CA 模型：

因果一致性
Admissibility 属性

其中，Admissibility 属性蕴含了操作意图一致性和结果一致性两方面含义。参照 CA 模型设计的协同编辑算法可以被形式化证明其算法的正确性。

因果一致性和结果一致性

定义 5. 因果一致性

给定任意一对操作 Oa 和 Ob，如果 Oa→Ob，那么在所有站点 Oa 在 Ob 之前执行。

定义 6. 结果一致性

当一个协同会话在静默状态时，所有站点共享文档的副本是一致的。

实现方法

因果一致性：一般可通过 SV 定义和实现。

结果一致性：一般可通过两种方法实现：

转换属性方法：设计算法的转换函数满足转换属性 TP1（Transformation Property 1）和 TP2（Transformation Property 2）
唯一全序方法：设计算法的控制过程避免 TP1/TP2 的约束，即可以构建唯一全序的操作转换路径

已有研究成果表明，设计转换函数满足 TP1/TP2 非常困难，相继有学者找出：

dOPT 不能满足 TP1 和 TP2 的”puzzle”
adOPTed 不满足 TP2 的”puzzle”
SOCT2 不满足 TP1 的”puzzle”
GOTO 不满足 TP1 的”puzzle”

相比之下，第二类方法更容易实现结果一致性。

Puzzle 问题的解决方案

为了解决 TP1 和 TP2 的”puzzle”问题，很多学者做了大量的研究和探索：

Sun（2014）：从转换函数层面上总结了 OT 算法的”puzzle”问题，包括 do 操作的 TP1/TP2 的”puzzle”问题以及 undo 操作的 IP1、IP2/IP3 的”puzzle”问题
解决思路：
1. 从转换函数的层面上解决，但需要结合具体的应用来设计相应的转换函数
2. 从算法的控制层面上考虑设计避免 TP1/TP2、IP1 和 IP2/IP3 约束的 OT 算法
Randolph 等人（2015）：总结了已有算法存在的”puzzle”问题，并利用自动机合成了满足 TP1 和 TP2 的操作转换函数

操作意图一致性

Sun 的定义

Sun 最早通过操作的”执行效果（execution effect）“给出”操作意图（intention of an operation）“的一个笼统定义 [3, 61]，并未严格定义、度量和说明”执行效果”。Sun 等人认为操作意图的具体定义要依赖于具体应用中的”操作语义（operation’s semantics）“，并且不能通过串行化方法达到。

Sun 等人从两个层面上考虑维护操作意图的一致性 [3, 61]：

算法控制过程：给出了维护操作意图一致性的一个通用框架，即可采用维护操作的因果一致性和操作的全序来构建操作转换路径
操作转换函数：指出通过设计操作转换函数来维护操作的意图需要依赖于具体应用中的操作语义

基于以上讨论，Sun 的操作意图的维护，结合了 Sun 同时代多版本的含义，多种结果只要获得其中的任意一个一致性结果，即认为满足操作意图一致性。

不同技术的实现方法

地址空间转换技术：意图保持可以通过转换文档的地址空间实现。当处理并发操作时，并不需要转换操作，而是将文档的地址空间回溯到操作产生时的状态，在该状态下执行操作可以获取正确的执行位置。这种方法可以保证当所有的操作在各站点执行结束后，各站点线性结构存储的操作字符的顺序是一致的，实现了结果一致性和操作意图一致性。

CRDT 方法：与 OT 技术和地址空间转换技术不同，CRDT 方法维护操作意图一致性需要给每个操作对象分配全局唯一的 ID，结合不同的调度算法将操作对象全序的映射到内部的数据结构中，确保内部数据结构中操作对象的全序位置关系，从而实现操作意图一致性，并收敛于一致性的结果。

研究路线图

建立维护操作意图一致性的整体框架：即每一步的执行都要维护操作的意图
针对某种”应用”：基于某种”效果”，描述或者定义某种”操作意图”
基于（2）中操作意图的描述或者定义：设计相应的操作意图一致性的维护算法

虽然各类算法对操作意图的理解不同，定义不同，维护方法不同，应用效果不同，但到目前为止，基本上都能够被上述路线图所覆盖。

✨ 操作转换具体例子

场景：两个用户同时编辑文档”ABC”

sequenceDiagram
    participant A as Alice
    participant S as Server
    participant B as Bob

    Note over A,B: 初始文档: "ABC"

    A->>S: Insert("X", 1) → "AXBC"
    B->>S: Delete(2) → "AB"

    Note over S: 服务器需要进行操作转换

    S->>B: Transform(Insert("X", 1), Delete(2))
    S->>A: Transform(Delete(2), Insert("X", 1))

    Note over A: 执行转换后的Delete(3) → "AXB"
    Note over B: 执行转换后的Insert("X", 1) → "AXB"

    Note over A,B: 最终一致性: "AXB"

转换规则示例：

IT 转换（Insert-Transform）：当插入操作遇到其他操作时的转换
DT 转换（Delete-Transform）：当删除操作遇到其他操作时的转换

操作组合	转换前	转换后	说明
Insert vs Insert	Insert(“X”,1), Insert(“Y”,1)	Insert(“X”,1), Insert(“Y”,2)	后插入位置后移
Insert vs Delete	Insert(“X”,2), Delete(1)	Insert(“X”,1), Delete(1)	插入位置前移
Delete vs Insert	Delete(2), Insert(“X”,1)	Delete(3), Insert(“X”,1)	删除位置后移
Delete vs Delete	Delete(2), Delete(1)	Delete(1), Delete(1)	删除位置前移

总结

基于上述对操作意图及一致性问题的讨论，可将代表性的操作意图一致性的维护算法大体分为三类：

操作转换算法
地址空间转换算法
可交换的复制式的数据类型

实时协作算法基本类型

Sat, 01 Jul 2017 01:20:00 GMT

传统的一致性维护方法例如锁机制(locking)和串行化(serialization)方法不适合实时协同编辑, 主要有两方面原因. 一是, 传统方法的操作响应时间过长, 难以支持自由、和谐和自然的人机/人人交互. 二是, 传统方法重点考虑共享对象的结果一致性, 而忽略了用户的操作意图.

理论研究方面, 最早Ellis 和Gibbs 在1989 年以 GROVE 系统为背景首先提出操作转换(OT, Operational Transformation)的基本模型和算法[2], 来维护实时协同编辑过程中共享对象的一致性. 以此为开端, OT 算法在Ressel、Sun、Li 等的指引和推动下得到了大量的探索, 发表在ACM CSCW 会议、ACM Siggroup 会议、ACM TOCHI 期刊、 IEEE TPDS 期刊、 IEEE TOC 期刊

OT 算法的主要思想是本地产生的操作立刻执行, 接收到的远程操作需要与本地操作历史中已执行的并发操作进行操作转换后再执行. 与传统的锁机制和串行化方法相比, OT 算法的优势是具有很好的本地响应性. OT 算法也面临一些技术挑战, 例如, 设计正确的操作转换函数困难, 不断有算法被找出特定协同场景下的“puzzle”; 大部分 OT 算法没有良好的伸缩性等

地址空间转换算法作为另一类支持操作意图一致性的协同编辑算法, 为共享对象的一致性维护提供了新的思路, 典型代表为 AST(Address Space Transformation)算法[4, 62]. 与OT 算法相比, 这类算法在处理远程操作时, 并不是通过修正操作来获取操作的正确执行位置, 而是通过计算文档的地址空间来将文档状态回退到操作产生时的状态来获取操作的执行位置. 为实现文档地址空间的正确转换, 采用标记和回溯的方法实现. 因此, 该类方法又称为标记和回溯(Mark&Retrace)方法. 基于 AST 算法, 各种相关算法被提出

可交换的复制式的数据类型 (CRDT, Commutative Replicated Data Type)作为一类新的支持操作意图一致性的协同编辑算法被提出并得到了深入的研究. 以法国的研究机构 INRIA 为代表,提出了一系列 CRDT 相关算法, 发表在 ACM CSCW 会议、ACM Siggroup 会议、IEEE TPDS 期刊等上. CRDT 算法不需要保存操作历史, 并发操作之间不需要进行操作转换. 通过分配给所有操作对象唯一的标识符 ID(Identifier), 使得并发操作之间可交换执行. 大部分CRDT 算法具有良好的伸缩性, 适合应用于大规模的 p2p 协同编辑领域. CRDT 算法也面临一些技术挑战, 例如, 如何设计并发操作的可交换执行、如何给操作对象分配全局唯一的 ID, 如何减少ID 的空间开销等

实时协作-yjs和ShareDB对比

Sun, 30 Apr 2017 21:30:00 GMT

两个方案都在脑图的协作中尝试了一下，大体总结如下：

Yjs (基于 CRDT 算法) 和 ShareDB (基于 OT 算法) 是两种流行的实时协作编辑解决方案，每种都有其优点和缺点。 Yjs (基于 CRDT 算法) 的优点：

离线支持和冲突解决： CRDT 算法在设计上就考虑到了离线工作和冲突解决，使得 Yjs 能够在无需中心化服务器参与的情况下解决冲突。用户可以在离线状态下进行编辑，然后在重新连接时将其更改与其他副本合并，而不会导致任何冲突。
分布式和去中心化： CRDT 不需要中心服务器来解决冲突，这使得 Yjs 在设计上更加分布式和去中心化，可以在不同的网络环境中使用，包括 peer-to-peer 网络。
高性能和可伸缩性： Yjs 的实现对于大量用户协作编辑大型文档具有很好的性能和可伸缩性。

Yjs (基于 CRDT 算法) 的不足：

数据负载： 由于 CRDT 保持所有操作的历史记录以解决冲突，因此文档的大小可能会随着时间和操作的数量而增长，这可能会对网络传输和存储产生影响。
复杂性： CRDT 的理论和实现比 OT 更复杂，这可能会增加学习和实施的难度。

ShareDB (基于 OT 算法) 的优点：

实时同步： ShareDB 通过使用 WebSocket 提供实时的数据同步，这使得它在低延迟的网络环境中表现良好。
灵活性： ShareDB 支持任何 JSON 可序列化的数据类型，使其适用于更多种类的应用。

ShareDB (基于 OT 算法) 的不足：

需要中心服务器： OT 需要一个中心服务器来处理和转换操作，以解决冲突。这使得 ShareDB 更依赖于中心服务器和网络连接。
离线支持和冲突解决： 尽管 ShareDB 提供了离线支持，但是在没有服务器参与的情况下解决冲突往往会更复杂，而且实践下来存在乱序&丢内容的情况。
性能和可伸缩性： 与 CRDT 相比，OT 的性能和可伸缩性可能会受到更多的限制，特别是在大量用户协作编辑大型文档的情况下。

具体项目中实践可能要结合公司工程基建能力思考下怎么选择。

实时协作-yjs基本理解4-Ytext

Wed, 12 Apr 2017 06:30:00 GMT

Yjs 中的 Y.Text 是一种特殊的 CRDT (Conflict-free replicated data types)，它是用于处理分布式环境中的实时合作文本编辑的数据结构。Y.Text 允许多个用户同时在文本的任何位置进行插入和删除操作，无需担心冲突或数据不一致。 Y.Text 的工作原理基于两个主要的概念：

操作的唯一标识符： 在 Yjs 中，每个插入或删除操作都由一个全局唯一的标识符标识。此标识符是由生成操作的用户的唯一标识符和一个递增的逻辑时钟值组成的。这保证了即使两个用户在相同的位置进行操作，他们的操作也可以被区分开。
操作的部分排序： Yjs 使用这些唯一标识符为所有的操作定义了一个部分排序。具体来说，如果操作 A 的标识符小于操作 B 的标识符，那么我们就说操作 A 在操作 B 之前。当两个操作在同一位置发生时，这种排序可以用来解决冲突：我们总是选择标识符较小的操作先执行。

从操作和合并的角度看： 1. 插入操作 每一个字符都被赋予一个全局唯一的标识符（ID）。这个 ID 由两部分组成：生成该操作的客户端的唯一 ID 和一个在该客户端中的递增的逻辑时钟。因此，即使在网络延迟的情况下，不同客户端的操作也能被准确地区分开。 2. 删除操作 删除操作在 Yjs 中实现的方式是，每个字符的删除信息被记录下来，并与插入操作一同被传播到所有的副本。当一个副本收到一个删除操作时，它会从文档中删除对应的字符。 3. 更新操作、在 Y.Text 中，并没有明确的“更新”操作。它通过组合删除和插入操作来达到“更新”的效果。例如，如果想在某个位置替换一个字符，你可以在那个位置先删除那个字符，然后再插入新的字符。 4. 冲突解决 当两个或更多的操作在同一位置发生时，Yjs 通过比较他们的 ID 来决定他们的顺序。因为 ID 是全局唯一的，并且有一个定义好的顺序，所以所有的副本都会得到相同的结果，无论他们收到操作的顺序如何。 5. 并发操作 当两个并发的操作到达时，Yjs 会根据前面提到的规则决定他们的顺序。这样，只要所有的副本都收到了所有的操作，他们最终就会达到相同的状态。

另外在Yjs中，通过维护一个操作日志来保存所有的插入和删除操作。操作日志是Yjs的核心数据结构，通过它可以在任何时候重建当前的文档状态。以下是一个自己实现的粗略的代码示例，用于说明这些概念：

class YText {
  constructor() {
    this.ops = []; // 操作日志
    this.text = []; // 文本的当前状态
    this.clientId = Math.random().toString(36).substring(2); // 随机生成客户端ID
    this.clock = 0; // 逻辑时钟
  }

  insert(index, char) {
    const id = { clientId: this.clientId, clock: this.clock++ };
    this.ops.push({ type: 'insert', id, index, char });
    this.text.splice(index, 0, { id, char });
  }

  delete(index) {
    const { id } = this.text[index];
    this.ops.push({ type: 'delete', id, index });
    this.text.splice(index, 1);
  }

  // 处理来自其他客户端的操作
  receive(operation) {
    if (operation.type === 'insert') {
      this.text.splice(operation.index, 0, { id: operation.id, char: operation.char });
    } else if (operation.type === 'delete') {
      const index = this.text.findIndex(c => compareIds(c.id, operation.id) === 0);
      if (index >= 0) {
        this.text.splice(index, 1);
      }
    }
    // 对文本进行重新排序
    this.text.sort((a, b) => compareIds(a.id, b.id));
  }
}

// ID比较函数
function compareIds(id1, id2) {
  if (id1.clientId < id2.clientId) {
    return -1;
  } else if (id1.clientId > id2.clientId) {
    return 1;
  } else {
    return id1.clock - id2.clock;
  }
}

在这个例子中，我假设操作是按顺序接收的，即没有网络延迟或乱序操作的问题。在实际的 Yjs 中，处理这些问题需要更多的逻辑和数据结构，包括状态向量、删除集、并进行操作转换等。

请注意，这个示例代码是一个非常简化的版本，Yjs 的实际实现会更复杂，因为它需要处理各种网络问题，例如乱序的操作和网络分区，还需要进一步分析源码。

实时协作-yjs基本理解3-操作日志

Wed, 12 Apr 2017 04:00:00 GMT

在 Yjs 中，操作日志（Operation Log）被用于记录对数据的所有修改操作，这包括插入字符、删除字符等。每个操作都包含有关操作的信息，如操作的类型（插入或删除）、操作的位置、操作的内容，以及操作的唯一标识符（包含用户 ID 和时间戳）。操作日志可以用于生成一个差异（delta），这个差异可以发送给其他的副本以便更新其状态。

在收到新的操作时，Yjs 首先会将其添加到操作日志中，然后将其应用到数据结构上。这样，即使在没有网络连接的情况下，用户也可以继续进行编辑操作，这些操作会被保存在本地的操作日志中。当网络连接恢复后，Yjs 可以通过发送和接收操作日志来同步数据。以下是一个简单的实例，演示了如何在 Yjs 中使用和更新操作日志：

class OperationLog {
  constructor() {
    this.log = [];
  }

  // 添加一个新的操作到操作日志
  add(operation) {
    this.log.push(operation);
  }

  // 获取操作日志
  get() {
    return this.log;
  }

  // 将操作日志转换为差异
  toDelta() {
    // 以简单的方式，直接返回整个操作日志
    // 在实际的 Yjs 系统中，会实现更复杂的差异计算算法
    return this.log;
  }
}

let opLog = new OperationLog();

opLog.add({type: 'insert', position: 0, content: 'Hello, world!', siteId: 'A', timestamp: Date.now()});
opLog.add({type: 'delete', position: 5, length: 1, siteId: 'A', timestamp: Date.now()});

console.log(opLog.get()); // 输出操作日志
console.log(opLog.toDelta()); // 输出操作日志的差异

在这个例子中，我们首先创建了一个操作日志 opLog，然后添加了两个操作：一个插入操作和一个删除操作。我们可以使用 opLog.get() 来获取操作日志，也可以使用 opLog.toDelta() 来获取操作日志的差异。

我们实现的这个例子非常简单，实际的 Yjs 系统会对操作日志进行更复杂的处理，例如，当计算差异时，Yjs 可能会比较两个副本的向量时钟，然后只包含那些在接收方副本上还未执行的操作。

实时协作-yjs基本理解2-向量时钟

Wed, 12 Apr 2017 01:30:00 GMT

向量时钟（Vector Clock）是分布式系统中用于记录和比较事件发生顺序的一种数据结构。每个节点都维护着一个向量时钟，向量时钟是一个列表，每个元素对应一个系统节点的逻辑时钟值。逻辑时钟值是一个非负整数，表示一个节点已经发生的事件的数量。

在 Yjs 中，每个用户或客户端可以被视为一个节点。向量时钟用于追踪每个节点的操作顺序。具体来说，每个 Yjs 节点（客户端）都维护一个向量时钟，其中，向量时钟的键是节点的 ID，值是节点已执行的操作的数量。

当一个节点执行一个新的操作时，它会在其向量时钟中对应的元素值加一。当一个节点接收到其他节点的更新时，它会将自己的向量时钟与接收到的向量时钟进行比较，并据此决定更新的顺序。

向量时钟的比较规则如下：

如果一个向量时钟的所有元素值都大于或等于另一个向量时钟的对应元素值，我们说第一个向量时钟“发生在”第二个向量时钟之后。
如果一个向量时钟的所有元素值都小于或等于另一个向量时钟的对应元素值，我们说第一个向量时钟“发生在”第二个向量时钟之前。
如果两个向量时钟中的一部分元素值大于对方，另一部分元素值小于对方，我们说这两个向量时钟是并发的。

Yjs 使用向量时钟来解决并发操作的问题。当两个并发的操作修改了同一个数据元素时，Yjs 会根据向量时钟的顺序来决定哪个操作应该被接受。具体来说，Yjs 会选择向量时钟值较大的操作，也就是后发生的操作。

需要注意的是，Yjs 的向量时钟实际上是一种优化的实现，称为版本向量（Version Vector）。版本向量只跟踪那些修改了共享数据的节点的逻辑时钟值，而不是所有节点的逻辑时钟值。这使得 Yjs 能够以更低的内存和网络开销处理大量的节点和操作。

以下是一个简单的实例，演示了如何在 Yjs 中使用和更新向量时钟：

class VectorClock {
  constructor() {
    this.clock = {};
  }

  // 获取当前节点的时钟值
  get(siteId) {
    return this.clock[siteId] || 0;
  }

  // 增加当前节点的时钟值
  increment(siteId) {
    this.clock[siteId] = this.get(siteId) + 1;
  }

  // 合并两个向量时钟，取各自时钟值的最大值
  merge(otherClock) {
    for (let siteId in otherClock.clock) {
      this.clock[siteId] = Math.max(this.get(siteId), otherClock.get(siteId));
    }
  }

  // 比较两个向量时钟
  compare(otherClock) {
    let greater = false;
    let lesser = false;
    for (let siteId in this.clock) {
      if (this.get(siteId) > otherClock.get(siteId)) {
        greater = true;
      } else if (this.get(siteId) < otherClock.get(siteId)) {
        lesser = true;
      }
    }

    if (greater && lesser) {
      return 0; // concurrent
    } else if (greater) {
      return 1; // this clock happened after otherClock
    } else if (lesser) {
      return -1; // this clock happened before otherClock
    } else {
      return 0; // identical
    }
  }
}

let clockA = new VectorClock();
let clockB = new VectorClock();

clockA.increment('A');
clockB.increment('B');

console.log(clockA.compare(clockB)); // Output: 0, A and B are concurrent

clockA.merge(clockB);
console.log(clockA.compare(clockB)); // Output: 1, A happened after B

在这个例子中，我们首先创建了两个向量时钟 clockA 和 clockB，然后使它们各自增加一次。此时，clockA 和 clockB 的值是并发的（即，它们的值无法确定先后顺序），所以 clockA.compare(clockB) 的结果是 0。

然后我们调用 clockA.merge(clockB)，这将会取 clockA 和 clockB 的各自元素的最大值，合并后 clockA 的值变大，所以 clockA.compare(clockB) 的结果是 1，表示 clockA 发生在 clockB 之后。

这个例子很简单，在实际的 Yjs 系统中，可能有多个节点，并且每个节点都可能有多个操作。Yjs 使用向量时钟来跟踪所有这些操作，并确保它们能够以一致的方式合并。

实时协作-yjs基本理解

Tue, 11 Apr 2017 23:00:00 GMT

Yjs 是一个开源的 JavaScript 库，它实现了一种称为 CRDT（Conflict-free Replicated Data Type）的数据类型，这是一种可以在多个副本之间无冲突地复制和合并的数据类型。Yjs 允许多个用户在没有中心协调者的情况下并发地编辑共享的数据。

目前对 Yjs 的基本原理理解如下：

数据结构：Yjs 实现了多种 CRDT 数据结构，如 Y.Text（用于协作文本编辑）、Y.Array（用于协作列表编辑）等。这些数据结构都有一个共同的特点，即它们可以在没有中心协调者的情况下并发地被多个用户修改，而最终能够达到一致的状态。
唯一标识符：Yjs 为每一个操作（比如插入一个字符、删除一个列表元素等）分配一个全局唯一的标识符。这个标识符是由用户的唯一 ID 和一个递增的计数器组合而成的。Yjs 使用这个唯一标识符来追踪每个操作，这样就可以处理并发的操作，并确保所有副本的最终一致性。
向量时钟：Yjs 使用一种称为向量时钟的技术来跟踪操作的顺序。向量时钟是一个映射，它将每个用户的唯一 ID 映射到该用户的操作计数器。通过比较两个向量时钟，Yjs 可以确定两个操作的顺序关系。
操作日志：每当一个操作被应用到 Yjs 的数据结构时，这个操作都会被添加到操作日志中。Yjs 可以使用这个操作日志来生成一个差异（delta），然后将这个差异发送给其他的副本。接收到差异的副本可以使用这个差异来更新自己的状态。
冲突解决：当两个并发的操作修改了同一个数据元素时，Yjs 需要进行冲突解决。Yjs 的冲突解决规则是基于唯一标识符的：如果两个并发操作有相同的唯一标识符，那么它们实际上是同一个操作；如果它们的唯一标识符不同，那么 Yjs 会根据唯一标识符的顺序来决定哪个操作应该被接受。

Yjs 的设计使得它可以在任何网络协议（如 WebSocket、WebRTC、HTTP 等）上工作，可以与任何数据持久化库（如 IndexedDB、LevelDB 等）配合使用，也可以和任何协作编辑框架（如 CodeMirror、ProseMirror 等）集成。

实时协作-CRDT基本理解(2)

Mon, 10 Apr 2017 13:00:00 GMT

在现实中，CRDT 的实现需要考虑更多的细节，比如并发操作和网络延迟。为了处理这些问题，一种常见的 CRDT 用于协作编辑的类型是 LSEQ tree。然而，这个类型的数据结构非常复杂，因此在这里，我们将使用一种简化的数据类型——列表 CRDT，它依然可以处理插入、删除和并发操作。

我们将使用一个操作日志来模拟网络延迟。在这个模型中，每个编辑器都有一个操作日志，用来存储所有已经执行的和将要执行的操作。我们将假定所有的操作都是异步的，并且可能会在任何时间到达任何编辑器。

这是一个简化的列表 CRDT Demo 来支持插入和删除操作：

class CRDTList {
  constructor() {
    this.elements = [];
    this.history = [];
    this.remoteQueue = [];
  }

  insert(value, position) {
    const element = {value, id: Date.now()};
    this.elements.splice(position, 0, element);
    this.history.push({type: 'insert', element, position});
  }

  delete(position) {
    const element = this.elements.splice(position, 1)[0];
    this.history.push({type: 'delete', element, position});
  }

  merge(remoteList) {
    this.remoteQueue.push(...remoteList.history);
    this.processQueue();
  }

  processQueue() {
    while (this.remoteQueue.length > 0) {
      const operation = this.remoteQueue.shift();
      switch (operation.type) {
        case 'insert':
          const insertIndex = this.elements.findIndex(element => element.id > operation.element.id);
          this.elements.splice(insertIndex !== -1 ? insertIndex : this.elements.length, 0, operation.element);
          break;
        case 'delete':
          const deleteIndex = this.elements.findIndex(element => element.id === operation.element.id);
          if (deleteIndex !== -1) this.elements.splice(deleteIndex, 1);
          break;
      }
    }
  }

  print() {
    console.log(this.elements.map(element => element.value).join(""));
  }
}

// 创建两个 CRDT 列表实例
const listA = new CRDTList();
const listB = new CRDTList();

// 端 A 在光标位置 0 插入字符 'X'
listA.insert('X', 0);
listA.print(); // 输出: "X"

// 端 B 在光标位置 0 插入字符 'Y'
listB.insert('Y', 0);
listB.print(); // 输出: "Y"

// 模拟网络延迟，合并两个列表
setTimeout(() => {
  listA.merge(listB);
  listA.print(); // 输出: "YX"
}, 2000);

// 端 A 删除光标位置 0 的字符
setTimeout(() => {
  listA.delete(0);
  listA.print(); // 输出: "X"
}, 3000);

// 模拟网络延迟，合并两个列表
setTimeout(() => {
  listB.merge(listA);
  listB.print(); // 输出: "X"
}, 4000);

在这个代码示例中，每一个元素都有一个唯一的 id，并且这个 id 是由插入操作的时间戳生成的。当我们合并两个列表时，我们根据这个 id 来决定元素的顺序。

然而，这个简化版的列表 CRDT 还是存在一些问题的。比如，如果两个编辑器在同一毫秒内插入了一个元素，那么这两个元素的 id 就会是一样的，这就会引发问题。因此，在实际中，我们会使用更复杂的方法来生成这个 id，比如我们可以将时间戳和编辑器的唯一标识符（siteId）组合起来生成 id。

此外，这个例子也没有考虑元素的更新操作。在实际的 CRDT 中，我们通常会把一个更新操作看作是一个删除操作和一个插入操作的组合。

实时协作-CRDT基本理解

Mon, 10 Apr 2017 09:10:00 GMT

CRDT（Conflict-free Replicated Data Types）通过合并策略和操作转换来保证两个端之间的实时协作最终一致性。下面使用一个简单的文本编辑器的例子来建立一下体感：

假设我们有两个端 A 和端 B，它们同时编辑同一个文本。现在我们进行如下操作：

端 A 在光标位置插入字符 ‘X’，生成一个插入操作。
同时，端 B 在同样的光标位置插入字符 ‘Y’，生成一个插入操作。

现在，端 A 和端 B 都有了不同的操作。为了保证最终一致性，我们需要一个合并策略和操作转换。在这个例子中，我们使用标识符和位置信息来处理并发操作。每个字符都有一个唯一的标识符和位置信息。以下是使用 JavaScript 实现 CRDT 文本编辑器的简单代码：

// 定义一个 CRDT 文本编辑器类
class CRDTTextEditor {
  // 类的构造函数，初始化一个空字符串
  constructor() {
    this.text = ""; // 存储文本的变量
  }

  // 插入字符的方法，参数包括插入的字符信息，来源站点 ID，操作计数器以及插入的位置
  insert(char, siteId, counter, position) {
    // 在指定的位置插入字符，并更新存储的文本
    this.text = this.text.slice(0, position) + char + this.text.slice(position);
  }

  // 合并两个 CRDT 文本编辑器的方法，参数是另一个 CRDT 文本编辑器
  merge(otherEditor) {
    // 合并两个文本编辑器的文本
    const mergedText = this.mergeText(this.text, otherEditor.text);
    // 更新两个文本编辑器的文本为合并后的文本
    this.text = mergedText;
    otherEditor.text = mergedText;
  }

  // 获取存储的文本内容的方法
  getText() {
    return this.text;
  }

  // 合并两个文本的方法，参数是两个要合并的文本
  mergeText(text1, text2) {
    // 初始化一个空字符串，用于存储合并后的文本
    let mergedText = "";

    // 初始化两个指针，分别用于遍历两个文本
    let i = 0;
    let j = 0;

    // 当两个文本都还没有遍历完时，执行循环
    while (i < text1.length || j < text2.length) {
      // 获取当前遍历到的两个字符
      const char1 = text1[i];
      const char2 = text2[j];

      // 如果文本1还有字符而文本2没有，将文本1的字符加入到合并后的文本中，然后将文本1的指针后移
      if (char1 && !char2) {
        mergedText += char1;
        i++;
      } else if (!char1 && char2) {
    // 如果文本2还有字符而文本1没有，将文本2的字符加入到合并后的文本中，然后将文本2的指针后移
        mergedText += char2;
        j++;
      } else {
        // 如果两个文本都还有字符，比较两个字符的来源站点 ID 和操作计数器
        const siteId1 = char1.siteId;
        const siteId2 = char2.siteId;
        const counter1 = char1.counter;
        const counter2 = char2.counter;

        // 如果字符1的来源站点 ID 小于字符2的，或者来源站点 ID 相同但操作计数器小于字符2的，将字符1加入到合并后的文本中，然后将文本1的指针后移
        if (siteId1 < siteId2 || (siteId1 === siteId2 && counter1 < counter2)) {
          mergedText += char1;
          i++;
        } 
        // 否则，将字符2加入到合并后的文本中，然后将文本2的指针后移
        else {
          mergedText += char2;
          j++;
        }
      }
    }

    // 返回合并后的文本
    return mergedText;
  }
}

// 创建两个 CRDT 文本编辑器的实例
const editorA = new CRDTTextEditor();
const editorB = new CRDTTextEditor();

// 端 A 在光标位置插入字符 'X'
editorA.insert({ char: 'X', siteId: 'A', counter: 1 }, 'A', 1, 0);

// 端 B 在同样的光标位置插入字符 'Y'
editorB.insert({ char: 'Y', siteId: 'B', counter: 1 }, 'B', 1, 0);

// 合并两个文本编辑器
editorA.merge(editorB);
editorB.merge(editorA);

// 获取端 A 的文本内容并打印
const textA = editorA.getText();
console.log(textA); // 输出: "XY"

// 获取端 B 的文本内容并打印
const textB = editorB.getText();
console.log(textB); // 输出: "XY"

在这个例子中，通过使用标识符和位置信息，CRDT 文本编辑器能够合并端 A 和端 B 的插入操作，并保持最终一致的状态。最终，两个端都得到了包含字符 ‘X’ 和 ‘Y’ 的文本内容。

这个例子简化了一些 CRDT 的重要概念，比如它没有处理删除操作，也没有处理并发操作的所有可能情况。实际的 CRDT 实现可能更加复杂，并根据具体的数据结构和合并策略来处理并发操作。CRDT 的关键是设计合适的合并策略和操作转换规则，以确保最终各个端之间的实时协作达到一致的状态。

百度脑图支持实时协作

Tue, 21 Feb 2017 20:00:00 GMT

微前端思考

Sun, 19 Feb 2017 23:30:00 GMT

引言：为什么需要微前端？

在前端工程化快速发展的今天，单体前端应用面临着越来越多的挑战：

团队协作问题：多个团队在同一个代码库中开发，代码冲突频繁
技术栈限制：整个应用必须使用相同的框架和技术栈
部署耦合：一个模块的变更需要整个应用重新部署
维护复杂度：应用规模增长带来的复杂度呈指数增长

这些问题的本质是什么？集成、依赖、发布 三个维度的复杂度急剧上升。

微前端作为一种新的架构模式，试图解决这些问题。

什么是微前端？

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用可以独立运行、独立开发、独立部署。

核心理念

微前端和微服务在设计思想上高度一致，都体现了几个关键原则：

单一职责原则：每个服务/应用只负责特定的业务领域
迪米特原则：服务间通过明确接口交互，内部实现对外透明
独立自治：每个单元可以独立开发、部署、运行

从单体应用到微服务，设计关注点从分层转向了服务拆分；类似地，从单体前端到微前端，关注点从组件复用转向了应用拆分。

微服务 vs 微前端：架构对比

为了更好地理解微前端，我们来对比一下微服务和微前端的架构特点：

维度	微服务	微前端
独立自治	服务是最小单元，语言无关，框架无关(Spring MVC, Flask, Koa.js) 各服务间除调用关系外互相不产生副作用	应用是最小单元，框架无关(React, Vue, Angular) 应用间不互相影响(样式、事件、状态) 需要通过 iframe、Web Components 或自定义规范隔离
服务治理	• 服务注册与发现 • 配置中心 • 依赖关系管理 • 链路跟踪、限流、降级、熔断 • 日志与监控 • 生命周期管理	• 应用注册与发现 • 运行时配置管理 • 应用依赖关系管理 • 运行环境管理(iframe, Web Worker, 当前窗口) • 宿主环境管理(iframe, Shadow DOM, 当前窗口) • 应用生命周期管理
通信机制	• RPC、HTTP 直接通讯 • 消息中间件(Kafka)异步通讯 • 负载均衡	• EventBus/RxJS/Tapable 事件通讯 • 直接获取实例 • PostMessage 跨域通讯
聚合方式	• API 网关聚合 • 业务服务聚合(提单聚合履约、促销、订单等)	• 主应用聚合 • 由主应用管理子应用生命周期 • 通常用于 B 端后台系统

核心应用场景：B 端后台的”超级平台”

微前端最主要的应用场景是 B 端后台系统，这类业务有一个典型特征：入口聚合，超级平台。

痛点分析

B 端业务面临的核心矛盾是：快速增长的需求量 vs 研发复杂度的急剧上升

从需求角度看：

n 个需求分配给 n 个人，效率提升往往达不到 n 倍
很多需求无法拆分，必须由一个人完成
加人有时反而会降低效率（2 人做可能需要 4 人日）
代码合并、冲突解决占用大量时间

从工程角度看：

希望代码拆分足够细粒度，方便测试和减少冲突
同时希望保持使用的便利性
但这两个目标往往相互冲突

复杂度守恒定律

这里引入一个我在 2015 年想出来的概念：复杂度守恒

复杂度守恒和能量守恒定律类似，指在一个封闭系统中，复杂度不能凭空产生或消失，只能从一个地方转移到另一个地方，在转移过程中复杂度的总量几乎保持不变。

举例说明：

生成二维码让后端做，前端复杂度低（调接口获取图片）
前端自己生成，后端复杂度低（前端通过 canvas 画图导出）
总体复杂度基本相同，只是分布不同

前端复杂度的转移历程

当前前端开发感觉不太复杂，本质是因为我们将大量复杂度转移到了以 webpack 为核心的构建工具中。

但 webpack 与微服务理念存在根本偏差：

webpack 的假设：面向单一应用，通过构建时静态分析生成依赖关系
微前端的需求：运行时动态加载应用，管理应用生命周期

技术演进：从静态构建到动态加载

当前模式的局限

Webpack 的工作模式：

静态分析依赖关系
构建时生成资源表
按路由进行 code-split
使用 npm 管理包依赖

这种模式本质上是静态的，而微前端需要的是动态的运行时管理。

未来趋势

以 JavaScript Dynamic Import + HTTP/2 为代表的新规范更适合微前端：

不再需要传统的打包工具
只需要 loader 工具（如 SystemJS）
真正实现运行时动态加载

渐进式过渡方案

为了支持系统渐进过渡和旧版本浏览器，我们需要建设一套动态微前端治理架构。

微前端复杂度转移架构

复杂度在微前端架构中的转移路径：

一堆微前端 → 微前端治理平台 → 线上模板渲染 → 浏览器

治理平台职责

微前端治理平台承担了主要的复杂度：

微前端注册：应用注册与发现机制
依赖管理：处理应用间的依赖关系
应用编排：定义应用加载顺序和规则
应用聚合：将多个微前端组合成完整应用

总结与展望

微前端的价值

开发效率提升：团队可以独立开发、部署
技术栈灵活性：不同应用可以使用不同框架
风险隔离：单个应用的问题不会影响整体
渐进式重构：可以逐步替换老旧模块

需要解决的挑战

运行时性能：动态加载带来的性能开销
状态管理：跨应用状态共享和同步
用户体验：保证应用间切换的流畅性
治理复杂度：构建完善的微前端基础设施

未来方向

微前端架构正在朝着更加标准化和平台化的方向发展：

Web Components 标准的完善
后续应该会有相关的微前端框架逐步推出出来可以持续观望
微前端治理平台的标准化

在复杂度守恒的前提下，关键是找到最合适的复杂度分布点，让系统既能满足业务需求，又能保持良好的可维护性。

摘录林彪

Tue, 10 Jan 2017 22:00:00 GMT

杨成武回忆：1936年12月,西安事变爆发，红军大学第一期毕业。即将奔赴前线，林彪找我谈话，给我留下很深的印象。我过去当政委，还想干老本行。但军委经过全面考虑,确定我当师长。林彪说毛主席要我和你谈一次话，讲一下怎样当好师长的问题。谈话时罗瑞卿也在场,杨成武认真作了记录。林彪讲了九条,这也是他自己在战争中的体会：

一、要勤快。不勤快的人办不好事情，不能当好军事指挥员。应该自己干的事情一定要亲自过目，亲自动手。比如，应该上去看的山头就要爬上去，应该了解的情况就要及时了解，应该检查的问题就要严格检查。不能懒，军事指挥员切忌懒，因为懒会带来危险，带来失败。比方说，一个军事指挥员，到了宿营地就进房子，搞水洗脸洗脚，搞鸡蛋煮面吃，吃饱了就睡大觉。他对住的村子有多大，在什么位置，附近有几个山头周围有几条道路，敌情怎么样，群众条件怎么样，可能发生什么情况，部队到齐了没有，哨位在什么地方，发生紧急情况时的处置预案如何，都不过问，都不知道。这样，如果半夜三更发生了情况，敌人来个突然袭击，就没有办法了。到那种时候，即使平时很勇敢的指挥员，也会束手无策，只好三十六计，跑为上计，结果，变成一个机会主义者。机会主义和打败仗，常常是因为没有思想准备，没有组织准备，工作没有做到家，懒的结果。因此，不论大小指挥员都要勤快，要不惜走路，不怕劳累，要多用脑子，要做到心到、眼到、口到、脚到、手到。事情没有做好以前，不能贪闲。贪闲就隐伏着犯错误的根子。什么事都要心中有底，“凡事预则立，不预则废”。雷打不动的干部，牛皮糖式的干部，不管有多大本事，都不是好干部。

二、要摸清上级的意图。对上级的意图要真正理解，真正融会贯通，真正认识自己所受领的任务在战役、战斗全局中的地位和作用。这样，才能充分发挥自己的主观能动性；才能打破框框，有敢于和善于在新情况中找到新办法的创造性；才能有大勇，才能决心强、决心狠，敢于彻底胜利，有强烈的吞掉敌人的企图和雄心。指挥员的勇敢集中表现在歼敌决心的坚定顽强上面。指挥员的大勇建立在革命的最高自觉性和正确理解上级意图的基础上面。

三、要调查研究。对于敌情、地形、部队的情况和社会情况，要经常做到心中有数。要天天摸，天天琢磨，不能间断。这样做，不能看作是重复，实际上这不是重复，而是不断深化不断提高的过程，是取得正确认识的必不可少的手段。平时积累掌握的情况越多，越系统，在战时，特别是在紧张复杂的情况下，就越沉着，越有办法。急中生智的“智”，才有基础。因此，调查研究工作要贯串在各项工作中，要贯串在每一次战役、战斗的整个过程，反对打莽撞仗、糊涂仗，反对急性病，反对不亲自动手做调查研究的懒汉作风。特别是敌情，必须切实摸透。因为敌情是活的，敌人必然会极力隐蔽、伪装他们的真实企图和行动。要尽一切可能不间断地侦察，查清敌人的部署和动向，看他扮演什么角色？是主角还是配角？是主力还是非主力？是骄兵还是败兵？能集中多大兵力向我们进攻和阻挡我们的进攻。查明敌主官的特性，看他惯用和擅长用什么战法，根据他当前的企图判断他可能采用什么打法，等等。只要摸清了敌情、我情、地形的底，决心就快，就硬，就坚定。就不会被任何假象所迷惑，就不会被任何困难所吓住。如果情况不清，就会犹豫不决，举棋不定，坐失良机，或者勉强下了决心，一遇风吹草动，听到畏难叫苦和不正确的建议，就容易动摇，可能一念之差，前功尽弃。

四、要有个活地图。指挥员和参谋必须熟悉地图，要经常读地图。熟读地图可以产生见解，产生智慧，产生办法，产生信心。读的方法是把图挂起来，搬个凳子坐下来，对着地图看，从大的方向到活动地区，从地区全貌到每一地段的地形特点，从粗读到细读，逐块逐块地读，用红蓝铅笔把主要的山脉、河流、城镇、村庄、道路标划出来，边读，边划，等到地图差不多快划烂了，也就差不多把地图背熟了，背出来了。在熟读地图的基础上，要亲自组织有关指挥员和参谋对作战地区和战场进行实地勘察，核正地图，把战场的地形情况和敌我双方的兵力部署都装至脑子里去，做到闭上眼睛面前就有一幅鲜明的战场图影，离开地图也能指挥作战。这样，在你死我活、瞬息万变的战斗情况下，可以比敌人来得快，争取先机，先敌一着，掌握主动，稳操胜券。

五、要把各方面的问题想够想透。每一次战役、战斗的组织，要让大家提出各种可能出现的问题，要让大家来找答案，而且要从最坏的最严重的情况来找答案。把所有提出来的问题都回答了，再没有问题没有回答的了，这样，打起仗来才不会犯大错误，万一犯了错误，也比较容易纠正。没有得到答案的问题，不能因为想了很久想不出来就把它丢开，留下一个疙瘩。如果这样，是很危险的，在紧要关头，这个疙瘩很可能冒出来，就会使你们心中无数，措手不及。当然，在战争环境中，要考虑的问题很多，不可能一次都提完，也不可能一次都回答完，整个战役、战斗的过程，就是不断提出问题和不断回答问题的过程。有时脑子很疲劳，有的问题可能立即回答不了。这时，除了好好地和别人商量以外，就好好地睡一觉，睡好了，睡醒了，头脑清醒了，再躺在床上好好想一想，就可能开窍，可能想通了，回答了，解决了。总之，对每一个问题不能含糊了事。问题回答完了，战役、战斗的组织才算完成。

　　六、要及时下达决心。在什么样的情况下可以下决心打呢？指挥员必须以最大努力组织战役、战斗的准备工作，力求确有把握才动手，不打无把握之仗。但是任何一次战斗都不可能完全具备各种条件，不可能有百分之百的把握。一般说有百分之七十左右的把握，就很不错了，就要坚决地打，放手地打。不足的条件，要通过充分发挥人的因素的作用，依靠人民群众的力量，充分发挥人民军队特有的政治上的优势，充分发挥指战员的智慧和英勇顽强的战斗作风来弥补，以主观努力来创造条件，化冒险性为创造性，取得胜利。

七、要有一个很好的很团结的班子。领导班子思想认识要一致，行动要协调、合拍，要雷厉风行，要有革命英雄主义的气概。都要勤快，都千方百计地办好事情，完成任务。不互相扯皮，不互相干扰，不抱旁观者的态度。如果领导班子不好，人多不但无用，反而有害。

八、要有一个很好的战斗作风。有好的战斗作风的部队才能打好仗，打胜仗。好的战斗作风首先是不叫苦，抢着去担负最艰巨的任务，英勇顽强，不怕牺牲，猛打猛冲猛追。特别是要勇于穷追。因为把敌人打垮以后，追击是解决战斗、扩大战果、彻底歼灭敌人最关键的一招。在追击时，要跑步追，快步追，走不动的扶着拐棍追，就是爬、滚，也要往前追，只有抓住敌人，才能吃掉敌人。好的战斗作风要靠平时养成，要靠实际锻炼，要在紧张、残酷的战斗中才能锻炼出来。不敢打硬仗、恶仗的部队，让他打几次就打出来了，因为已经见识过硬仗、恶仗的场面，有了体会，有了经验，知道怎么打了，百炼成钢就是这个道理。做工作也要有好的作风，说了就要做，说到那里做到那里，要做得干脆利索，要一竿子插到底，一点不含糊，不做好不撒手。好的作风的养成，关键在于干部。强将手下无弱兵，干部的作风怎么样，部队的作风就会怎么样。因此，首先要抓好干部，要干部做出样子，影响带动部队。只要干部作风好，指挥好战斗，多打胜仗，即使是新建的部队或者原来基础较弱的部队，也会很快打出好作风来，像铁锤一样，砸到那里，那里就碎。

九、要重视政治，亲自做政治工作。部队战斗力的提高要靠平时坚强的党的领导、坚强的政治工作。连队的支部一定要建设好，支部的工作要做活，就是要把所有党团员的革命劲头鼓得足足的，充分发挥他们的模范作用、带头作用，通过他们把全连带动起来，通过他们去做政治工作，提高全体指战员的阶级觉悟。有了坚强的党支部的领导，有了坚强的政治工作，就可以做到一呼百应，争先恐后，不怕牺牲，前赴后继。战术、技术也要练好，特别是技术，如果枪打不准，战场上就不能消灭敌人，就不能解决战斗。因此，军事训练不能马虎，党政工作要领导好训练。艺高人胆大，胆大艺更高，部队有了高度的无产阶级觉悟，有了好的战斗作风，再加上过硬的作战本领，就如虎添翼，就可以无敌于天下。

算法题-数组列表中的最大距离

Sun, 01 Jan 2017 16:00:00 GMT

题目

给定 m 个数组，每个数组都已经按照升序排好序了。现在你需要从两个不同的数组中选择两个整数（每个数组选一个）并且计算它们的距离。两个整数 a 和 b 之间的距离定义为它们差的绝对值 |a-b| 。你的任务就是去找到最大距离

输入： 
[[1,2,3],
 [4,5],
 [1,2,3]]
输出： 4
解释：
一种得到答案 4 的方法是从第一个数组或者第三个数组中选择 1，同时从第二个数组中选择 5 。

代码

function maxDistance(list) {
  let res = 0,
    min_val = list[0][0],
    max_val = list[0][list[0].length - 1]

  for (let i = 1; i < list.length; i++) {
    res = Math.max(
      res,
      Math.max(
        Math.abs(list[i][list[i].length - 1] - min_val),
        Math.abs(max_val - list[i][0])
      )
    )
    min_val = Math.min(min_val, list[i][0])
    max_val = Math.max(max_val, list[i][list[i].length - 1])
  }
  return res
}

2016总结

Sat, 24 Dec 2016 16:27:12 GMT

2016 年总体就是一个繁忙的一年，技术上面的成长整体去看没有之前的三年那种飞跃的感觉，不过整体还是有一些进步的。总体来讲就是一个能够勉强接受的还处于上升的势头。

我是比较看不得无法进步的人，更不要说原地踏步或者退步了。以前和创业的伙伴去讲我要去别的地方去试试，如果在一个地方看不到进步就是换一个地方的时候了。一转眼到美团也快有两年了，不知道明年会不会给自己一个比较满意的回答。

2016 年我对于没办法提升自己这件事情上，有越来越大的抵触情绪，做事情如果能做到能力所要求的天花板，就不会懈怠的说差不多就行了。所以基本上每天都要做/学很多事情，做到很晚。

今年读的书也是最多的，最杂的，有心理学，行为学的，有社会学，有科技类的，专业类的，甚至海淘了十几本日语轻小说大大小小装满了一个书架，也写了一些读书笔记。

今年某些事情给我的冲击也是最大的，甚至最后看「西藏生死书」来缓解自己的情绪，你不得不去做一些事情，就因为你还活在当下。昨天听阿妹在唱「我期待」，突然感觉有点怀念宝哥，你年龄渐长，看的东西多了一些，思考的多了一些的时候，就越来越能明白很多事情。

13 年这时候我用王小波的一句话结尾“那一天我二十一岁，在我一生的黄金时代，我有好多奢望。我想爱，想吃，还想在一瞬间变成天上半明半暗的云。后来我才知道，生活就是个缓慢受锤的过程，人一天天老下去，奢望也一天天消失，最后变得像挨了锤的牛一样。可是我过二十一岁生日时没有预见到这一点。我觉得自己会永远生猛下去，什么也锤不了我。”

14 年我最后说「希望肚子饿的时候旁边就有吃的，希望下雨的时候手边就有一把伞，希望疲惫的时候能得到一个拥抱」

15 年我最后说「这世界是个好地方，值得为它奋斗」

今年的结尾，我希望明年的时候能做到「该吃饭的时候吃饭，该睡觉的时候睡觉，认真的去做每件事情，认认真真的活在当下」。

德州牌型概率

Wed, 10 Aug 2016 22:00:00 GMT

结论

德州扑克的牌型，从高到低排序如下：

皇家同花顺（Royal Flush）概率是 $1.54 \times 1 0^{- 6}$ ，约每649,739次有一次。
同花顺（Straight Flush）概率是 $1.39 \times 1 0^{- 5}$ ，约每72,193次有一次
四条（Four of a Kind）概率是 $2.40 \times 1 0^{- 4}$ ，约每4,165次有一次。
葫芦（Full House）概率是 $1.44 \times 1 0^{- 3}$ ，约每694次有一次
同花（Flush）概率是 $1.97 \times 1 0^{- 3}$ ，约每509次有一次。
顺子（Straight）概率是 $3.92 \times 1 0^{- 3}$ ，约每255次有一次。
三条（Three of a Kind）概率是 $9.14 \times 1 0^{- 3}$ ，约每109次有一次
两对（Two Pair）概率是 $4.75 \times 1 0^{- 2}$ ，约每21次有一次。
一对（One Pair）概率是 $0.358$ ，约每3次有一次。
高牌（High Card）概率是 $0.578$ ，约每2次有一次。

详情

皇家同花顺

在德州扑克中，皇家同花顺是最高的牌型，它由同一花色的 A, K, Q, J, 10组成。由于一副扑克牌有四种花色，所以皇家同花顺的可能组合有4种。

一副扑克牌有52张牌，所以在德州扑克中，从52张牌中抽取5张牌的所有可能组合为 ( C(52, 5) )。这是一个组合数学的问题，其中 ( C(n, k) ) 表示从n个不同的元素中选择k个元素的组合数。

因此，皇家同花顺的概率可以通过以下公式计算：

P (Royal Flush) = \frac{Number of Royal Flush combinations}{Total number of 5-card combinations} = \frac{4}{C ( 52 , 5 )}

皇家同花顺的概率是大约 (1.54 \times 10^{-6})，或者说大约是每649,739次有一次。

同花顺

同花顺是由同一花色的五张连续的牌组成。在计算同花顺的概率时，我们需要排除皇家同花顺，因为皇家同花顺是同花顺的一种特殊情况。

在每种花色中，有9种可能的同花顺（例如，A-2-3-4-5，2-3-4-5-6，…，9-10-J-Q-K），所以总共有 (4 \times 9 = 36) 种可能的同花顺。

因此，同花顺的概率可以通过以下公式计算：

P (Straight Flush) = \frac{Number of Straight Flush combinations excluding Royal Flush}{Total number of 5-card combinations} = \frac{36}{C ( 52 , 5 )}

同花顺的概率是大约 (1.39 \times 10^{-5})，或者说大约是每72,193次有一次。

四条

四条是由四张同一点数的牌和一张其他任意牌组成。在一副扑克牌中，有13种点数，所以有13种可能的四条。对于每种四条，第五张牌有48种可能（52张牌中剩下的48张），所以总共有 (13 \times 48 = 624) 种可能的四条。

因此，四条的概率可以通过以下公式计算：

P (Four of a Kind) = \frac{Number of Four of a Kind combinations}{Total number of 5-card combinations} = \frac{624}{C ( 52 , 5 )}

四条的概率是大约 (2.40 \times 10^{-4})，或者说大约是每4,165次有一次。

葫芦

葫芦是由三张同一点数的牌和另外两张也是同一点数的牌组成。在一副扑克牌中，有13种点数，所以有13种可能的三条。对于每种三条，剩下的两张牌有12种可能的点数，所以总共有 (13 \times 12 = 156) 种可能的葫芦。

然而，我们还需要考虑到每种点数有4张牌，所以三条有 (C(4, 3) = 4) 种可能，两对有 (C(4, 2) = 6) 种可能。因此，总共有 (156 \times 4 \times 6 = 3744) 种可能的葫芦。

因此，葫芦的概率可以通过以下公式计算：

P (Full House) = \frac{Number of Full House combinations}{Total number of 5-card combinations} = \frac{3744}{C ( 52 , 5 )}

葫芦的概率是大约 (1.44 \times 10^{-3})，或者说大约是每694次有一次。

同花

同花是由同一花色的五张牌组成。在一副扑克牌中，有4种花色，所以有4种可能的同花。对于每种花色，有 (C(13, 5) = 1287) 种可能的牌组合。然而，我们需要排除同花顺和皇家同花顺，因为它们是同花的特殊情况。每种花色有10种可能的同花顺（包括皇家同花顺），所以总共有 (4 \times 1287 - 4 \times 10 = 5108) 种可能的同花。因此，同花的概率可以通过以下公式计算：

P (Flush) = \frac{Number of Flush combinations excluding Straight Flush and Royal Flush}{Total number of 5-card combinations} = \frac{5108}{C ( 52 , 5 )}

同花的概率是大约 (1.97 \times 10^{-3})，或者说大约是每509次有一次。

顺子

顺子是由五张连续的牌组成。在一副扑克牌中，有10种可能的顺子（例如，A-2-3-4-5，2-3-4-5-6，…，10-J-Q-K-A），每种顺子有4的5次方（1024）种可能的花色组合。然而，我们需要排除同花顺，因为它是顺子的一种特殊情况。每种顺子有4种可能的同花顺，所以总共有 (10 \times 1024 - 4 \times 10 = 10,200) 种可能的顺子。

因此，顺子的概率可以通过以下公式计算：

P (Straight) = \frac{Number of Straight combinations excluding Straight Flush}{Total number of 5-card combinations} = \frac{10200}{C ( 52 , 5 )}

顺子的概率是大约 (3.92 \times 10^{-3})，或者说大约是每255次有一次。

三条

三条是由三张同一点数的牌和两张其他任意牌组成。在一副扑克牌中，有13种点数，所以有13种可能的三条。对于每种三条，第四张牌有48种可能（52张牌中剩下的48张），第五张牌有44种可能（剩下的44张），所以总共有 (13 \times 48 \times 44 = 27,504) 种可能的三条。然而，我们需要排除葫芦和四条，因为它们是三条的特殊情况。每种点数有 (C(4, 3) = 4) 种可能的三条，每种点数有 (C(4, 4) = 1) 种可能的四条，所以总共有 (13 \times 4 \times 12 \times 6 + 13 \times 1 \times 48 = 3,744) 种需要排除的组合。因此，总共有 (27,504 - 3,744 = 23,760) 种可能的三条。

因此，三条的概率可以通过以下公式计算：

P (Three of a Kind) = \frac{Number of Three of a Kind combinations excluding Full House and Four of a Kind}{Total number of 5-card combinations} = \frac{23760}{C ( 52 , 5 )}

三条的概率是大约 (9.14 \times 10^{-3})，或者说大约是每109次有一次。

两对

两对是由两张一样的牌和另外两张也是一样的牌以及一张其他任意牌组成。在一副扑克牌中，有13种点数，所以有 (C(13, 2) = 78) 种可能的两对。对于每种两对，第五张牌有44种可能（52张牌中剩下的44张），所以总共有 (78 \times 44 = 3432) 种可能的两对。然而，我们需要考虑到每种点数有4张牌，所以每种两对有 (C(4, 2) = 6) 种可能，第五张牌有4种可能的花色，所以总共有 (78 \times 6 \times 6 \times 4 = 123,552) 种可能的两对。

因此，两对的概率可以通过以下公式计算：

P (Two Pair) = \frac{Number of Two Pair combinations}{Total number of 5-card combinations} = \frac{123552}{C ( 52 , 5 )}

两对的概率是大约 (4.75 \times 10^{-2})，或者说大约是每21次有一次。

一对

一对是由两张一样的牌和三张其他任意牌组成。在一副扑克牌中，有13种点数，所以有13种可能的一对。对于每种一对，第三张牌有48种可能（52张牌中剩下的48张），第四张牌有44种可能（剩下的44张），第五张牌有40种可能（剩下的40张），所以总共有 (13 \times 48 \times 44 \times 40 = 1,098,240) 种可能的一对。然而，我们需要排除两对、三条、葫芦和四条，因为它们是一对的特殊情况。每种点数有 (C(4, 2) = 6) 种可能的一对，所以总共有 (13 \times 6 \times 12 \times 6 \times 4 + 13 \times 4 \times 48 + 13 \times 4 \times 12 \times 6 + 13 \times 1 \times 48 = 123,552 + 29,952 + 14,976 + 624 = 169,104) 种需要排除的组合。因此，总共有 (1,098,240 - 169,104 = 929,136) 种可能的一对。

因此，一对的概率可以通过以下公式计算：

P (One Pair) = \frac{Number of One Pair combinations excluding Two Pair, Three of a Kind, Full House, and Four of a Kind}{Total number of 5-card combinations} = \frac{929136}{C ( 52 , 5 )}

让我们来计算这个概率。

一对的概率是大约 (0.358)，或者说大约是每3次有一次。

高牌

高牌是不符合任何上述牌型的五张牌。高牌的概率可以通过以下公式计算：

P (High Card) = 1 - P (One Pair) - P (Two Pair) - P (Three of a Kind) - P (Straight) - P (Flush) - P (Full House) - P (Four of a Kind) - P (Straight Flush) - P (Royal Flush)

高牌的概率是大约 (0.578)，或者说大约是每2次有一次。

以上就是德州扑克中各个牌型的概率。这些概率是基于从一副52张牌中随机抽取5张牌的情况计算的。在实际的德州扑克游戏中，由于玩家可以选择是否换牌，因此各个牌型的实际概率可能会有所不同。

IM 消息文件实现

Sat, 23 Jul 2016 21:40:00 GMT

背景：

之前负责的云盘业务和内部使用的大象 IM 融合，云盘需要负责大象日常 im 所有的文件流转，这里涉及到两个现有系统融合的问题，大象之前的协议里面文件消息包含的是一个静态的链接，目前还没有上鉴权。云盘设计之初就为了保证安全性，所有分发出去的链接都是动态的，有鉴权信息和时效的。那么如何设计一个有鉴权信息而且还满足大象 im 协议需求的 url 就成了融合里面稍微麻烦点的问题。

最初的想法

1，链接只包含必要的im id和cookie(或者header)，然后请求到服务端，服务端鉴权后，定位到文件，然后重定向到一个动态链接上面。这个方案的问题在app端兼容上面，而且一次图片要发起两次请求，体验不好，第一个被否决。 2，使用java/go转发流量，链接包含必要的im id和和cookie(或者header)，请求到一个java的服务，鉴权和定位文件没有问题，就去mss上面请求文件，然后使用流对流的方式返回给客户端，这个有两个问题： a：观察流量走向：业务nginx->java服务->mss nginx->swift集群，这里有两个问题，如果扩容，那么java服务和swift集群都要同时扩容，流量在内部走了两份就代表流量浪费和相应时间加长 b：流对流不稳定，云盘在非核心的地方尝试使用过流对流的方案，基本上每3W 次请求会有1~2次失败，因为关键节点太多，稳定性是乘法关系，网络或者机器内存等等原因稍微有问题，就可能导致失败这不满足 im 图片在消息稳定性上的要求

进一步的想法

仔细想了下，重新观察正常的流量走向是：请求->mss nginx->swift 集群。在方案 2 中我们添加 java 服务的原因就是为了做：1，鉴权 2，文件寻址。根据我之前的了解，其实可以在 nginx 上面直接做，所以进一步我想直接用 lua 或者 c 给 nginx 写这个业务模块，和基建的同学沟通后得知他们的 nginx 可以直接写 lua 拓展，那么事情就简单了第一个直觉想法是流量请求到 nginx 里面，然后由 lua 鉴权，然后文件寻址。lua 请求到文件后添加到 nginx response content 里面核心代码大概就像下面这样

//前面是鉴权，寻址文件获得url
local http = require("socket.http");
local body, code = http.request("http://7xi576.com1.z0.glb.clouddn.com/01CE5B62-E4E2-4D84-99EC-BE70DA46269B.png")
if not body then ngx.say("获取不到文件");return; end
ngx.print(body);

但是转头一想，如果由 lua 去获取文件，肯定没有 nginx 本身 c 模块直接获取文件要好一些，所以有了接下来的想法，核心原理就是直接用 nginx 的 proxy_pass 特性，每次请求上下文中由 lua 鉴权，寻址文件，并动态动态替换需要 proxy_pass 的 url 和 content-type 之类的参数即可。这样整个文件流转就变成下面比较合理的方式：

client request file -> mss nginx（鉴权，文件寻址，代理到文件）-> mss server

整个方案稳定性和云盘原有方案基本保持一致，安全性一致，同时兼容大象im协议。核心 lua 代码大概是下面样子：

local http = require("socket.http");
local ltn12 = require("ltn12")
local cjson = require ("cjson");
local cjsonObj = cjson.new()
local var = ngx.var;
local request_body = [[ { "objectId" : "test","password" : "123" } ]];
local response_body = { }
local body, code, response_headers = http.request{
    url = "http://127.0.0.1:8411/image",
    method = "POST",
    headers =
    {
        ["Authorization"] = "Maybe you need an Authorization header?",
        ["Content-Type"] = "application/json",
        ["Content-Length"] = request_body:len(),
        ["Cookie"] = var.http_cookie,
    },
    source = ltn12.source.string(request_body),
    sink = ltn12.sink.table(response_body)
}

if type(response_body) == "table" then
    local resBodyStr = table.concat(response_body,"");
    local resJsonObj = cjsonObj.decode(resBodyStr);
    if code == 200 then
        if not resJsonObj.error then
            var.image_proxy_url = resJsonObj["filepath"];
        else
            ngx.say(resJsonObj.error.msg);
        end
    else
        ngx.say("获取不到文件");
    end
else
    ngx.say("Not a table:", type(response_body))
end

进一步的想法

如果频繁(每次请求更改一次)更改的 proxy_pass 的话，对 nginx 的性能会有影响，同时模块见耦合也过于严重，so，我们的想法进一步变成通过内部 rewrite 来进行解耦，同时隔离开各个模块： auth，error，not-fount，proxy_pass. 整个流程说难也不难，主要是思路上的问题，同时还要对nginx模块/拓展开发足够熟悉并能灵活运用。

轻OA 的一些思考

Mon, 11 Jul 2016 22:16:11 GMT

任何信息化系统，从技术角度看过去，都是流程，表单和角色。

从业务的角度看过去，会有所不同，比如 ERP 关注的物质资产，HR 系统关注的是人力资产，CRM 关注的是外部客户资源等等。

轻 OA 来讲的话，关注的应该是事务性的工作，比如周报，日程，TODO 等等。

现在如果围绕及时通讯去做 OA 的话，合理的技术拆解方案应该是这样的：从后台的角度业务其实就是各种中间件的一种组合（这里指的并不是 nodejs/python 的那种中间件，而是类似于微服务相互关联的一整套架构），大部分轻 OA 应用实际编码部分将会是流程上面的一种流转控制，其余的抽象为中间件去做。更进一步，流转方式一旦抽象出来，甚至可以实现一种用户自定义表单的形式来反转系统的开发复杂度，也就是系统控制流程和角色两个变量，让用户去自定义实际业务中变化最大的表单部分。 如图一，这样更符合当前内信的目标群体和策略

在整个架构中，如果我们抓住不变的，那么应对变化就会有所余力和预期，在目前的一些业务诉求下，很容易能想到的一些通用型的中间件可以有「通知」「报表数据导入与处理」「组织结构信息获取」「任务调度」「分词搜索」「存储服务」「」。。。等等越往后越偏向于通用与底层。而在端上面来看，更多的是对表单组件的封装，以及通用 SDK 的抽象上。

解决复杂问题的方法论

Wed, 11 May 2016 22:27:12 GMT

引言：为什么需要复杂性管理框架？

在日常工作和生活中，我们经常面临各种类型的问题。有些问题很简单，按照标准流程就能解决；有些问题比较复杂，需要专业分析；还有一些问题充满不确定性，传统的方法往往失效。

如何正确识别和处理不同类型的问题？最近发现 Cynefin 框架 有一套思路。

Cynefin 框架概述

Cynefin 是一个帮助决策的概念框架，由 Dave Snowden 在 1999 年供职于 IBM 时创建。

Cynefin，发音为 ku-nev-in，是威尔士语中的一个词，表示我们环境中的多种因素以及以我们无法理解的方式影响我们的经验。

框架核心思想

Cynefin 根据因果关系的可预测性提供了五种决策场景：

框架分为两个主要区域：

右半边：有序状态（简单、繁杂）- 因果关系已知或可发现
左半边：无序状态（复杂、混乱）- 因果关系难以预测
中央：失序区域 - 不清楚存在什么样的因果关系

四种场景详解

1. 简单（Simple）- 最佳实践

特征：因果关系显而易见，有明确的正确答案

方法：感知 → 分类 → 响应（Sense - Categorise - Respond）

适用场景：

标准化流程
重复性任务
规则明确的操作

实际例子：

技术场景：服务器重启、代码格式化、数据库备份
管理场景：报销流程、请假申请、安全检查
生活场景：银行转账、网上购物、交通出行

注意事项：避免自满，定期检查”最佳实践”是否仍然有效

2. 繁杂（Complicated）- 好的实践

特征：因果关系存在但需要分析，需要专业知识

方法：感知 → 分析 → 响应（Sense - Analyze - Respond）

适用场景：

专业技术问题
需要专家判断
可通过分析解决

实际例子：

技术场景：系统架构设计、性能优化、复杂 Bug 调试
管理场景：团队重组、绩效分析、市场调研
生活场景：投资理财、房屋装修、医疗诊断

关键点：依赖专家经验，但答案相对确定

3. 复杂（Complex）- 涌现实践

特征：因果关系只能事后感知，充满不确定性

方法：探索 → 感知 → 响应（Probe - Sense - Respond）

适用场景：

创新项目
人际关系
未知领域探索

实际例子：

技术场景：新技术选型、敏捷开发、开源社区建设
管理场景：文化变革、新产品研发、跨部门协作
生活场景：育儿教育、创业、社交网络

操作要点：

小步快跑，快速迭代
鼓励实验和创新
从失败中学习

4. 混乱（Chaotic）- 新颖实践

特征：没有明显的因果关系，情况紧急

方法：行动 → 感知 → 响应（Act - Sense - Respond）

适用场景：

危机处理
紧急事件
完全未知情况

实际例子：

技术场景：系统大面积宕机、数据泄露事故、安全攻击
管理场景：公关危机、资金链断裂、核心人员离职
生活场景：自然灾害、突发疾病、意外事故

关键点：先稳定局面，再寻找规律

5. 失序（Disorder）- 困惑状态

特征：不清楚问题属于哪种类型，容易陷入个人偏好

处理方式：

分解问题
收集更多信息
寻求多角度分析

场景间的动态转换

顺时针移动（知识积累）

随着知识和经验的增加：混乱 → 复杂 → 繁杂 → 简单

例子：

新技术从完全未知（混乱）→ 探索阶段（复杂）→ 专家分析（繁杂）→ 标准化应用（简单）
新员工从手忙脚乱（混乱）→ 摸索学习（复杂）→ 寻求指导（繁杂）→ 熟练操作（简单）

逆时针移动（失效和退化）

由于自满、缺乏维护或环境变化：简单 → 混乱（灾难性失败）

例子：

过度依赖”最佳实践”，忽视环境变化
流程僵化，无法应对新情况
技术债务积累，导致系统崩溃

实践应用指南

1. 问题识别清单

在面对问题时，问自己：

这个问题之前遇到过吗？（简单）
需要专家或深入分析吗？（繁杂）
结果是否无法预测？（复杂）
情况是否紧急混乱？（混乱）

2. 团队决策应用

会议组织：

简单问题：快速决策，标准流程
繁杂问题：邀请专家，深入分析
复杂问题：头脑风暴，小步试错
混乱问题：紧急响应，稳定优先

项目管理：

根据项目特性选择合适的管理方法
敏捷适合复杂项目，瀑布适合繁杂项目

3. 个人成长应用

学习策略：

简单技能：按教程练习
繁杂技能：找导师学习
复杂领域：实践探索
混乱情况：行动中学习

职业发展：

识别当前工作的复杂性类型
制定相应的能力提升计划

常见误区与注意事项

误区一：用错方法

问题：用简单域的方法处理复杂域的问题
后果：教条主义，缺乏创新
例子：用固定流程处理创新项目

误区二：停留在舒适区

问题：总是用自己熟悉的方法
后果：无法适应环境变化
建议：主动学习不同域的处理方式

误区三：灾难性转移

问题：从简单直接跳到混乱
预防：保持警觉，避免过度自信

结语

Cynefin 框架的价值在于：

提升决策质量：根据问题特性选择合适方法
减少决策时间：快速识别问题类型
增强团队协作：统一对问题复杂性的认知
促进持续学习：理解知识转化过程

在这个快速变化的时代，掌握复杂性管理框架，能帮助我们更好地应对各种挑战，做出更明智的决策。

推荐阅读：

《复杂性思维》- Dave Snowden
《决策与判断》- Scott Plous

动态规划

Wed, 20 Apr 2016 23:25:01 GMT

nodejs addon 结合 libuv 使用经验

Wed, 20 Apr 2016 23:25:01 GMT

最近在基于 electron 做客户端相关工作，需要写 nodejs 的 addon 以便拓展 electron 相关功能，涉及到一些高级东西，写下相关经验。

一：asynchronous addons

在开发过程中，我们一定会遇到需要在 c++中处理一些耗时的任务，这个时候，必须使用异步 addon，如果使用同步的就像下面的传统 addon 写法，就会导致 JavaScript 线程被 blocked。

// 引入 C++ addon
var addon = require("./cpp/build/Release/addon");
...
// 调用 addon, 这里就会被blocked住，直到c++返回结果
var outputdata = addon.get_some_result(some input data);

//do some thing

这种情况应该使用的是传统的 JavaScript 回调的机制：

addon.get_some_result_async(some input data, function(outputdata) {
  //do some thing
});

这时候就必须了解相关的的线程机制，在我们当前的 case 中会有两个线程，一个是 event loop【javascript 在其中执行的线程】，也是我们不想阻塞的线程。另一个线程是被 libuv 管理的线程我们叫他 worker 线程，很显然你不能在 event loop 线程和 worker 线程共享各自的栈数据，所以我们需要某种方案在两个线程里面共享数据，以便 worker 线程能拿到 event loop 线程的输入，event loop 线程能拿到 worker 线程的输出。

整个调用流程如下图：

首先定义一个共享数据结构体，放在内存堆上。

struct Work {
  uv_work_t  request; //指向了work本身，libuv api 在启动worker 线程的时候接受一个uv_work_t类型的指针
/*
*Persistent代表存储在堆上，防止被回收，可以完成类似闭包的功能。
在这里要了解几个V8里面的概念
在v8当中所有JavaScript数据都是由GC管理的，内存分配都是在V8的堆中进行分配的，JavaScript的值和对象也都存放在V8的堆中。
这个堆由V8独立的去维护，失去引用的对象将会被V8的GC掉并可以重新分配给其他对象。而所有数据型（Value的派生类）变量的地址（Value*）本身就是一个Handle，即是对堆中对象的引用。
所以V8内存管理其实就是对Handle进行管理，这样通过Handle GC就能知道Heap中一个对象的引用情况，当一个对象的Handle引用为发生改变的时候，GC即可对该对象进行回收（gc）或者移动。而直接通过C++的方式去直接去引用一个对象，会使得该对象无法被V8管理。
另外Handle分为Local和Persistent两种：
Local是局部的，同时被HandleScope进行管理。
persistent，是全局的，不受HandleScope的管理，其作用域可以延伸到不同的函数可以用来实现一些Closure之类的效果。Persistent Handle对象需要Persistent::New, Persistent::Dispose配对使用，类似于C++中new和delete。

通常在一个函数中会有很多Handle，而HandleScope则相当于用来装Handle（Local）的容器，当HandleScope生命周期结束的时候，其内部包含的所有Handle也将会被释放，这将会引起堆中对象引用的更新。
HandleScope是分配在栈上，不能通过New的方式进行创建。对于同一个作用域内可以有多个HandleScope，新的HandleScope将会覆盖上一个HandleScope，并对Local Handle进行管理。
*/
  v8::Persistent<Function> callback; //callback存储javascript回调函数
  std::string input//例子中javascript传入的输入
  std::string output;//异步worker线程返回的输出
};

addon 的 get_some_result_async 方法，通过 libuv 启动 worker 线程

void get_some_result_async(const v8::FunctionCallbackInfo<v8::Value>&args) {
    Isolate* isolate = args.GetIsolate();
    Work * work = new Work();
    work->request.data = work;
    v8::String::Utf8Value param1(args[0]->ToString());
    std::string inputString = std::string(*param1);
    work->input = inputString;
     Local<Function> callback = Local<Function>::Cast(args[1]);
    work->callback.Reset(isolate, callback);
    // 启动 worker 线程异步去做一些事情，本线程中立即返回
    uv_queue_work(uv_default_loop(),&work->request,
        workAsync,workAsyncComplete);
    //直接返回给js了
    args.GetReturnValue().Set(Undefined(isolate));
}

worker 线程

static void workAsync(uv_work_t *req)
{
    Work *work = static_cast<Work *>(req->data);
    std:string input = work->input;
    //假装很耗时的样子
    sleep(3000);
}

worder 线程 complete 后回调，注意这个函数执行在 v8 线程中

static void WorkAsyncComplete(uv_work_t *req,int status)
{
    Isolate * isolate = Isolate::GetCurrent();
    v8::HandleScope handleScope(isolate); // Required for Node 4.x

    Work *work = static_cast<Work *>(req->data);

    // 设置回调函数参数
    Handle<Value> argv[] = { v8::String::NewFromUtf8(isolate, work->output) };

    // 执行callback
    Local<Function>::New(isolate, work->callback)->
      Call(isolate->GetCurrentContext()->Global(), 1, argv);

   // 释放 persistent回调函数
    work->callback.Reset();

    delete work;
}

如何召开一场有效的会议

Fri, 01 Jan 2016 22:33:12 GMT

会议前的思考：我真的需要开会吗？

在发起一场会议前，别着急，先思考一下”我真的需要会议吗？”

如果确认要进行会议，就必须做好会前、会中、会后的过程管理，切实保证会议有效。

会议发起人的核心职责

在整个流程中，会议发起人的角色非常关键。一名合格的会议发起人，应该履行以下职责。

会前准备阶段

明确会议主题、议程

核心要求：

每个会议都需要议程明确定义目标和期望结果（即使是信息分享）
会议的24小时前发出加入到行事历中
要求与会者审查和挑战议程

发送会议邀请

操作要点：

提前发送会议邀约（最晚提前2-3天）
发会议邀请的时候可以没有议程（但是需要在会议前24小时补上）
明确需要做决定或承诺会后执行的人（也许需要咨询你的上级经理）
注明哪些人是required（干系人），哪些是optional

会中控制阶段

开始会议

准时开始原则：

主持人提前到场，并确认会议所需设备完善可用
因为各种原因，需要考虑取消会议，分以下两种情况：
- 会议当天前：明确延期或取消，直接改期或取消会议
- 会议当天：迟到十五分钟以上，可取消会议

开场流程：

确立会议目的
描述期望的结果
介绍议程
询问与会者是否要加其它议程（需考虑会议时限）

控制节奏

关键要点：

好的会议通常是有压力的
控制时间保证可以涉及所有议程
最后的议程应该包括核心要点和后续需要跟进的任务
建议偏题的讨论在会后再议
控制”霸占”会议的人，点名让沉默的人有机会发言

结束会议

成功标准：

时间不够意味着会议失败（排除有临时增加重要议题的情况）
会议完整结束且达到效果，主要分：
- 所有的议题都讨论过
- 明确会后跟进的任务

会后跟进阶段

写好会议记录

重要原则：

主持人负责会议记录，除非有其它委派
写会议记录是非常有效权力，不要放弃
人们会忘记会议本身，只有记录（包括跟进任务）会被记住
如果会议是关于项目，需更新项目文档页面
啰嗦的记录毫无用处

跟进后续任务

执行要点：

分发会议记录email或大象群给到参会者及相关人员，邀请大家更正错误
及时更新文档和会议记录，记录里面要明确TODO的责任人（owner）和完成时间
跟进TODO

会议流程总览

会议阶段	核心职责	关键要点
会前准备	明确会议主题、议程	每个会议都需要议程明确定义目标和期望结果（即使是信息分享）会议的24小时前发出加入到行事历中要求与会者审查和挑战议程
发送邀请	提前发送会议邀约	最晚提前2-3天可以没有议程但需在会议前24小时补上明确决策人和执行人注明required和optional人员
会中开始	准时开始会议	主持人提前到场，确认设备可用迟到15分钟以上可取消会议开场确立目的、期望结果、介绍议程
节奏控制	控制时间和讨论	好的会议通常是有压力的控制时间涉及所有议程建议偏题讨论会后再议平衡发言机会
会议结束	确保达成目标	时间不够意味着会议失败所有议题都讨论过明确会后跟进任务
记录整理	撰写会议记录	主持人负责记录人们只会记住记录和跟进任务项目会议需更新项目文档避免啰嗦记录
后续跟进	执行和监督	分发记录邀请更正明确TODO责任人和时间持续跟进执行

相关阅读：

解决复杂问题的方法论

Fri, 01 Jan 2016 22:33:12 GMT

步骤

1、确认给予反馈意见的必需性。这一问题会影响工作吗？会对工作关系造成不利影响吗？如果答案是否定的，暂时无需提供反馈意见。

2、在给出反馈意见前，需做好准备工作。收集近期这一问题的详细例子。注意需针对行为或者结果。

3、想好什么是你想要得到的结果。做好提供纠正错误的反馈信息，或者进行指导的准备。

4、在私下给予反馈意见。

5、如果你想要某一特定行动或者结果，需表达清楚。

6、确定你将如何跟进这项工作。

准则

1、要详细具体。没有人能够按照线索或者模糊的反馈意见行事。如果你告诉某人“这份报告非常出色”，这句话可以表达你的赞许，但对方并不知道报告出色的地方在哪里。

2、在事件发生后，第一时间给出反馈意见。等到年终考核才给出反馈意见起不到任何作用。即使等到季度考核，也是无济于事。

3、不要针对人进行反馈，应描述某一行为或者结果。不要说“你在工作中非常粗心”，可以说“我发现在最后一组产品的交付记录中有很多打印和拼写错误”。

4、不要责怪员工，说话不要太绝对。不要说“你从来都不测试你的编码”，可以说“你在检查最后三处改变时没有对这些改变进行测试”。

5、倾听对方的意见。要确定对方同意你的描述，认为它是正确的。

6、保留所有反馈谈话的记录。要保留所有与工作表现相关的谈话的非正式笔记，比如，保留所有你与员工进行的一对一谈话笔记。如果等到问题严重了，你才开始做文字性的报告，那么对方很可能会声称受到了不公的指责。所以，应该将你为改善状况付出的持续努力记录下来。

2015总结

Thu, 31 Dec 2015 15:50:00 GMT

总的来说，这世界是个好地方，值得为它奋斗。

如何分析问题

Sat, 12 Dec 2015 21:40:00 GMT

为什么需要结构化分析问题？

美团的汇报文档一般有以下几部分组成

背景(现状)
分析
问题
目标
解决方案
预计结果

MECE法则

金字塔原理的本质就是提倡一种结构化的思考方式和习惯，核心就是从上到下逐层展开，从下到上逐层支撑，具体做法就是不重不漏(穷举)。

参考资料：https://km.sankuai.com/page/1207135841

SCQA结构

这个就是如何结构化表达，就是上面提到的美团汇报风格的几部分，原始的结构化表达如下：

S：情景（Situation）
C：冲突（Complication）
Q：问题（Question）
A：答案（Answer）

所以其实很明显SCQA是考验写作基本功的，核心还是在MECE上，但是MECE并不是一个很容易理解和操作的东西，针对研发领域我有一些具体的操作方式：

首先明确一个问题解决方案链：

大问题 ↔ 方案 ↔ 小问题 ↔ 方案 ↔ 更小的问题

核心原则

从上到下逐层展开：每个大的问题都会有一系列的方案，每个方案都会产生更多的小问题
从下到上逐层支撑：每个小问题都是一个更大问题的解决方案的一部分

这样做的好处能帮助我们加深思考的深度，也就是对某个问题，看得更具体。

思考框架

操作步骤

在已有的**问题解决方案链(因果链)**上找一个合适的层级(切入点)
评估现状为什么我们认为它不够好
找到衡量”好的”指标，并用它说明为什么这是一个值得解决的问题
穷举已知问题的拆解方案，通过指标衡量一个最合适的视角
在这个最合适的视角下展开具体的解决方案

常见误区

不要把所有问题都当成问题：明确问题是 why、how、what 具体哪个层面的，一般来讲要从why的角度作为最大的问题做分解拆分
明确什么是现象什么是问题：不要搞混
区分好什么是手段什么是目的：不能混淆

工具推荐

结构化框架的最好表达方式就是思维导图：

工具类型	推荐产品	特点说明
全平台	GitMind	PC Web 移动端都有，不确定以后是否收费
Web版	百度脑图	我参与开发的产品
PC版	XMind	功能强大但收费

相关阅读：

MECE-金字塔原理

云盘点击热点图

Thu, 12 Nov 2015 21:50:00 GMT

最近在云盘中实现了热点上报系统，方便 UED 同学进行针对性的设计，最后成品如下：

实现

采集上报

实现思路很简单，因为云盘使用 react 框架，常规的业务事件都由 react 合成事件代理。所以热点 sdk 可以直接将在 document 上监听 mouseDown 事件，获取坐标，1200 * 800 (设计稿尺寸) 进行上报。大致的伪代码如下

// 监听页面的点击事件
document.addEventListener('click', function(e) {
    // 获取点击的原始坐标
    var x = e.pageX;
    var y = e.pageY;

    // 获取页面的实际尺寸
    var pageWidth = document.documentElement.scrollWidth;
    var pageHeight = document.documentElement.scrollHeight;

    // 将坐标值缩放到800*1200
    var scaledX = Math.round(x / pageWidth * 800);
    var scaledY = Math.round(y / pageHeight * 1200);

    // 打包成对象
    var reportData = {
        x: scaledX,
        y: scaledY,
    };

    // 将数据上报到服务器（这里假设你有一个名为 report 的函数来完成数据上报）
    report(reportData);
});

数据清洗

数据上报后会送到 kafka 中，有一个 java 任务进行 kafka 消费，数据按照分钟级别存入 mysql 中即可，这个过程需要区分一下版本&AB 等进行分组

数据展示

后台设计上传不同版本的设计稿 (1200 * 800) ，根据版本信息去数据库中获取对应时间段的点位信息，通过 echarts 热力图展示即可

可改进

滚动

目前云盘不存在整个页面的滚动行为，所以没有实现滚动下点击位置的校准

云盘服务端从nodejs 专项 java 相关复盘

Thu, 24 Sep 2015 23:50:00 GMT

说明

这里是对云盘 node.js 转向 java 做的一个客观总结，个人平时也会经常使用 nodejs,go,python,C#,java 进行开发，比较熟悉各个工具链，所以也并没有语言，框架上面的歧视。

云盘 web 前后端，服务端开发是我在5月份接手的，当时所有端是基础终端来负责，服务化的事情是云计算组负责，5月份的时候全部移交到我们负责，在这之前云计算组已经和我们进行过几次碰头，已经使用 python tornado 开发了一些服务端的事情。接收到我们组之后，由于我们希望在 nodejs 上面来进行更多地技术积累，经过几次评审放弃了我当时在维护的 python 版本，转向 nodejs 进行开发。

云盘概览

服务端功能模块

整个架构为：web 前端（自行开发框架进行开发），web 后端（koajs），服务端（koajs，postgresql），以及 pc，mac，android，iphone 等终端

经过两个月的工作，基本开发出来一个可用的 nodejs 版本服务端，在这些日子的开发遇到了下面这些问题：

nodejs 进行事务管理并没有很好办法，必须要在服务层透传一个 transaction 到 dao 层，整个代码写到后期就基本没办法维护，哪怕抽离出来 db 层也只是将问题放 db 层没办法很好解决问题，牵一发动全身，同时基础的 mysql 包事务管理也有问题，高并发下并不能真正的处理好事务，会抛出奇怪的错误，而且无法定位，无法复现
每次重构必须通过单元测试，功能测试进行覆盖，很多在编译期就能解决的问题必须通过测试来覆盖，前期开发很爽，后期重构火葬场
整个服务化领域并没有很好的解决方案，很多知名三方服务没有一个稳定包进行开发，比如存储使用 openstack 的时候我就必须自己查看 openstack 接口给三方包打补丁
和公司服务化大潮流格格不入，公司在今年下半年开启使用 java 进行服务化，很多提供 jar 包，而 nodejs 必须在 wiki 中寻找接口然后自行开发
云盘服务端会做很多数据处理的工作，属于高 cpu 工作，上线 node 版本之后，会发现 cpu 会经常不正常波动，后期我使用 c++开发一些模块进行处理，这个问题才得到缓解，但相应的每次重构的时候都会很麻烦，丧失了 nodejs 快速开发的乐趣
nodejs 的回调写法是反人类的，使用 koa.js 也仅仅是缓解了这个问题，但是还是会遇到很多 js 本身的坑，当时 node 还是0.12.7这个版本，在大型项目中定位问题也会很麻烦

所以经过实际检测发现目前这个阶段使用nodejs开发服务端的方式基本是不对的，我们需要重新评估整个服务端

快速的调研了国内外知名网盘的架构情况，最后得到两个比较靠谱的方案，一个是使用 golang 进行开发（dropbox，七牛），另一个就是使用 java 进行开发，golang 很快被我们否掉了，因为还是回碰到上面的1，3，4的问题，很多包需要自己打补丁，云盘当时的情况是服务端只有我自己一个人，同时还要兼管 web 端的事情，时间不够，决定使用 java 进行开发，同时我们重新设计了 java 版本服务端架构

架构

架构 1

架构 2

整个架构被我们认为的拆分成了各个微服务，通过 kafka 进行一步消息通知，通过 kafka 进行全局事务维护，保证整个系统是最终一致的。

在这里，我们使用了spring mvc，和spring boot进行微服务的处理，几个关键的服务被我们合并到微服务网关里面进行统一的处理，内嵌了jetty作为服务容器。

整个项目大概开发了两周的时间，开发完成上线第一个bate版本，同等功能的代码量同比nodejs版本多了一些，主要在配置文件上，但是可维护性更强，同时模块间相对独立，各层之间相对独立，可以放心进行重构，快速添加新功能，通过spring自带的事务进行事务管理，通过注解的方式在代码里面可以不去管理事务，同时可以很好的利用公司提供的服务比如mafka，tair等。可以说在nodejs当中遇到的问题基本上都解决了，不好的地方大概是资源消耗上，我们多开了一台服务器，同时java通过mvn编译时间太长，不能像nodejs那样所见即所得。

开发方式上的不同

不同的语言有不同的编程哲学，在nodejs和java里面能明显感受出来这样的变化

1，异常处理 js：由于js是弱类型的，所以我们可以使用函数返回值的方式进行错误处理，调用函数去判定是不是存在error对象，存在就返回给终端错误，同时我们还可以抛出异常，然后进行全局异常拦截器中间件进行拦截 java：java是强类型的，无论是业务错误，还是别的错误，通常我们都使用抛出异常的方式进行处理， 2，数据处理 js：js本身是面向对象也是面向函数的，可以大量借鉴函数式编程的优点，在数据处理上借助lodash很容易写出下面的链式函数（熟悉.net的朋友肯定感觉下面的和linq基本一样）

_.chain(arr).filter((item)=>{return item.name.indexOf(dep_name)!==-1}).map(item=>item.count).reduce((total,n)=>{return total + n}).value()

其实上面并不是“纯函数式”编程，而是以对象/容器为中心的串联，有些像 jquery 对象的链式调用，不过也比java得写法好的多，同时不必担心效率问题，我们可以优化这个链上的任何一个函数，从而达到优化速度的目的，而且整个过程是懒加载的，如果真的使用纯函数编程【ramda.js】，会compose fuctor等概念进行一些合并，直接一次算出结果。 java：if,else,while,for慢慢写吧。。。。别忘了这个过程中还要在声明很多中间过渡需要的承载类，真的有点浪费生命，这里scala做的就很好，最开始其实想使用scala +play框架开发的，如果不是人力上的问题。

3，日志管理 js，我发现普遍对于日志并没有什么特殊的做法，大家通常都是通过pm2查看access log，npm上面有个一log4j的库，不过用法没有java灵活，需要自己在需要的地方埋 java，日志这里通常使用log4或者logback之类的，而且不需要自己处理，只需要声明一个全局的Logger就行，这样还可以动态的调整输出类型，也可以调整输出位置

4，部署 js，通过ops系统，配置两个脚本，扔到服务器就可以 java，需要编译而且和不同版本还有关，而且现有 ops 使用 docker 编译会重新下载所有依赖，非常慢，中间也会遇到很多问题，基本需要和 sre 进行沟通解决。不过新版基于 docker 的发布系统已经在研发中了，这个问题应该很快得到解决

spring aop 权限拦截

Wed, 23 Sep 2015 11:43:15 GMT

在云盘服务端 java 化的进程中，我们选择使用了在 header 中添加认证头信息的方式进行权限校验，这样就触发了一个问题，spring mvc 中如何完成这个认证过程。里面有一个难点就是如果请求 body 有业务内容，我们需要获取到里面的内容进行签名，最开始我们直接实现了一个 Interceptor 类，然后通过 preHandle 方法中的 HttpServletRequest 获取到了 body，然后进行签名计算，但是这样有问题，在 spring mvc 将 body 内容注入到 handler 参数之前我们人为的消费了里面的数据，导致如下 function 中 addGroup 参数为空，所以这个方法肯定不行。

解决办法：

接下来经过研究 spring 注入流程，发现这个办法，直接实现 spring 中的 MethodInterceptor 这个接口如下：

然后在 handler 函数上加入我们自定义好的注解类即可：

这里面的原理是，这个会 MethodInterceptor 在函数被注入后执行之前进行触发，这样我们只需要做好一些约定，就可以使用这个注解完成我们的权限验证的问题，从而避免 body 被提前消费。

最后别忘在配置文件中进行实现如下配置，让 spring 容器加载这个拦截器

<bean id="accessRequiredInterceptor" class="com.xxx.xm.mbox.interceptors.AccessRequiredInterceptor"/>

从上面这个事情上不难看出，spring mvc 基于 spring 构建的，整个请求生命周期过滤可以在 mvc 中进行，也可以借助 spring 本身的 aop 进行拦截。后者明显更底层一些

dozer使用

Wed, 23 Sep 2015 10:52:14 GMT

在进行云盘项目开发的时候，经常会遇到将领域模型转化为业务模型，或者将业务模型转化为符合要求的JSON格式，这里面就涉及到大量的 Java Bean to Java Bean 的映射，我们很容易会写出来下面的代码：

这让人很不爽，所以如果两个类结构一样，最常使用的是BeanUtils.copyProperties(src，aim)方法将一个对象的值赋给另一个对象，但是如果属性不同或者名称不同(上面的例子中opver就是一个是String一个是Long)这样是不可以的，出于职业习惯，再造轮子之前先去翻了翻果然让我找到了dozer这个映射工具。

安装并使用

首先在pom.xml中插入下面的依赖，然后mvn install一下即可安装到项目中

注意如果项目中依赖了mafka的jar包必须按照如下的方法写，否则程序无法运行

然后写好配置文件，加载到dozer中就可以直接映射class

更多的时候我们希望能够使用spring管理我们的依赖，只需要按照下面的写法即可导入配置文件到dozer并被spring所管理

一些高级用法

dozer如果属性名相同可以自动映射很多类型比如String->Long ,Long->String,Data->Timestamp等等，几乎满足所有需求，但是项目中总有一些需要我们配置的奇葩现象，

1,属性名不相同

1，使用注解，如下

2，xml 配置如下

其中a代表源，b代表目标，field代表我们需要映射的属性的名称，这里类型可以是不一样的，自动转换类型支持如下：

Primitive to Primitive Wrapper Primitive to Custom Wrapper Primitive Wrapper to Primitive Wrapper Primitive to Primitive Complex Type to Complex Type String to Primitive String to Primitive Wrapper String to Complex Type if the Complex Type contains a String constructor String to Map Collection to Collection Collection to Array Map to Complex Type Map to Custom Map Type Enum to Enum Each of these can be mapped to one another: java.util.Date, java.sql.Date, java.sql.Time, java.sql.Timestamp, java.util.Calendar, java.util.GregorianCalendar String to any of the supported Date/Calendar Objects. Objects containing a toString() method that produces a long representing time in (ms) to any supported Date/Calendar object.

会使用上面的方法，基本满足我们90%的日常开发,但是貌似还是有一些情况不能用这种方式自动转换，比如云盘经常会遇到String和Date互相转换的情况我们可以这么写

如果整个类里面有很多，可以提高date-format

如果整个配置文件所有类都需要转换，可以在提高date-format

这样就可以对整个文件所有时间类型进行转换

2,自定义转换器

上面的Date->String都是使用的dozer本身存在的转换器，我们可能需要使用一些自己自定义的转换器以满足自定义类的转换，这个时候就需要实现dozer为我们提供的接口:

然后在配置文件中可以如下写法

3,更多

上面说的基本上可以满足99%的业务需求，不过dozer还有很多奇妙的用法，可以访问dozer官网学习。

My Second Post!

Wed, 06 May 2015 23:46:37 GMT

Wow! I love blogging so much already.

Did you know that “despite its name, salted duck eggs can also be made from chicken eggs, though the taste and texture will be somewhat different, and the egg yolk will be less rich.”? (Wikipedia Link)

Yeah, I didn’t either.

Hello World

Fri, 01 May 2015 22:12:03 GMT

This is my first post on my new fake blog! How exciting!

I’m sure I’ll write a lot more interesting things in the future.

Oh, and here’s a great quote from this Wikipedia on salted duck eggs.

A salted duck egg is a Chinese preserved food product made by soaking duck eggs in brine, or packing each egg in damp, salted charcoal. In Asian supermarkets, these eggs are sometimes sold covered in a thick layer of salted charcoal paste. The eggs may also be sold with the salted paste removed, wrapped in plastic, and vacuum packed. From the salt curing process, the salted duck eggs have a briny aroma, a gelatin-like egg white and a firm-textured, round yolk that is bright orange-red in color.

使用v8与js做交互，理解node基本原理

Tue, 28 Apr 2015 14:09:01 GMT

前阶段刚说到全栈的问题，到底要多深，多后期才能算是全栈每个人心中都有自己的看法，我自己感觉多学一些总不是坏事。

最近用 node 遇到了一些障碍，在看 node 的源码了解一下，然后想到网上现在还没有相关的分析，大多数都是开发 addons，而且中途 v8 进行了一次大升级，很多能查到的资料都是错得，所以就在这里简单地写一些自己的经验吧。

众所周知，node 是基于 v8 做的，v8 是什么？简单来说就是一个 javascript 的解析器，他会读取 js 程序，使用 jit 技术实时编译我们写的程序，最后运行的是机器码，所以 v8 运行的 js 特别快。

安装依赖工具

首先我们需要进行环境的配置，首先去 v8 主页https://code.google.com/p/v8/，在wiki中找到BuildingWithGYP这一项，然后发现被移动到另一个页面，我们点击过去

我们发现这个页面提到了一个新的工具 gclient，v8 项目就是用这个管理的，所以我们需要下载它，现在去他的主页https://code.google.com/p/gclient/，我们发现他已经成为 depot_tools 的一个子项目[如下图]，然后我们点击链接跳转过去

由于我是用的 mac，所以直接使用 mac 的安装方式

Installing on Linux and Mac

Confirm git is installed. git 2.2.1+ recommended.
Fetch depot_tools: $ git clone chromium/tools/depot_tools.git - Git at Google
Add depot_tools to your PATH:$ export PATH=`pwd`/depot_tools:"$PATH"
- Yes, you want to put depot_tools ahead of everything else, otherwise gcl will refer to the GNU Common Lisp compiler.
- You may want to add this to your .bashrc file or your shell’s equivalent so that you don’t need to reset your $PATH manually each time you open a new shell.

这里建议提前安装 xcode，这样的话相关的工具都会安装好，不需要自己在配置。

安装 v8

安装使用两个命令

gclient config https://chromium.googlesource.com/v8/v8.git
gclient sync

剩下 gclient 就会全自动的帮我们完成之后的操作，看网速，我大概等了将近 2 个小时

生成 xcode 工程

进入到我们刚才下号的 v8 目录，输入下面的命令

build/gyp_v8 -Dtarget_arch=x64

然后就可以使用 xcode 打开/build 目录下面的 all.xcodeproj

制作简单地 log 函数

我在这里就举一个简单地例子，让大家熟悉 node 的原理，在 xcode 中找到 sample 项目，右键 process 复制一个 target，我们重命名这个复制好的 target 叫 helloV8，然后再 source 这个 group 里面创建一个 cpp 文件，随意起名字，我这里叫做 helloV8.cpp

将下面的代码复制一份到新创建好的 helloV8.cpp 中

#include "include/v8.h"
#include "include/libplatform/libplatform.h"
#include <iostream>
#include <fstream>
#include <sstream>

using namespace v8;

void printjs(const FunctionCallbackInfo<Value>& args) {
  v8::String::Utf8Value v8Str(args[0]);
  Isolate* isolate = args.GetIsolate();
  HandleScope scope(isolate);
  std::cout << *v8Str << std::endl;
  args.GetReturnValue().Set(String::NewFromUtf8(isolate, "from yeanzhi"));
}

void strLength(const FunctionCallbackInfo<Value>& args) {
  v8::String::Utf8Value v8Str(args[0]);
  Isolate* isolate = args.GetIsolate();
  HandleScope scope(isolate);
  int length = strlen(*v8Str);
  args.GetReturnValue().Set(Integer::New(isolate, length));
}

void loadjs(const FunctionCallbackInfo<Value>& args) {
  v8::String::Utf8Value v8Str(args[0]);
  std::ifstream f(*v8Str);
  std::stringbuf buf;
  f >> buf;
  Local<Value> result = Script::Compile(v8::String::NewFromUtf8(args.GetIsolate(), buf.str().c_str()))->Run();
  // Convert the result to an UTF8 string and print it.
  String::Utf8Value utf8(result);
  printf("\n%s\n", *utf8);
}

int main(int argc, char* argv[]) {
  // Initialize V8.
  V8::InitializeICU();
  Platform* platform = platform::CreateDefaultPlatform();
  V8::InitializePlatform(platform);
  V8::Initialize();

  // Create a new Isolate and make it the current one.
  Isolate* isolate = Isolate::New();
  {
    Isolate::Scope isolate_scope(isolate);
    // Create a stack-allocated handle scope.
    HandleScope handle_scope(isolate);
    auto global = v8::ObjectTemplate::New(isolate);
    global->Set(v8::String::NewFromUtf8(isolate, "printjs"), FunctionTemplate::New(isolate, &printjs));
    global->Set(v8::String::NewFromUtf8(isolate, "loadjs"), FunctionTemplate::New(isolate, &loadjs));
    global->Set(v8::String::NewFromUtf8(isolate, "strLength"), FunctionTemplate::New(isolate, &strLength));

    // Create a new context.
    Local<Context> context = Context::New(isolate, NULL, global);
    // Enter the context for compiling and running the hello world script.
    Context::Scope context_scope(context);
    // Create a string containing the JavaScript source code.
    Local<String> source = String::NewFromUtf8(isolate, "loadjs('app.js')");
    // Compile the source code.
    Local<Script> script = Script::Compile(source);
    // Run the script to get the result.
    Local<Value> result = script->Run();
    // Convert the result to an UTF8 string and print it.
    String::Utf8Value utf8(result);
    printf("\n%s\n", *utf8);
  }

  // Dispose the isolate and tear down V8.
  isolate->Dispose();
  V8::Dispose();
  V8::ShutdownPlatform();
  delete platform;

  return 0;
}

这端代码最核心的功能就是下面这段

auto global = v8::ObjectTemplate::New(isolate);
global->Set(v8::String::NewFromUtf8(isolate, "printjs"), v8::FunctionTemplate::New(isolate, &printjs));
global->Set(v8::String::NewFromUtf8(isolate, "loadjs"), v8::FunctionTemplate::New(isolate, &loadjs));
global->Set(v8::String::NewFromUtf8(isolate, "strLength"), v8::FunctionTemplate::New(isolate, &strLength));
// Create a new context.
Local<Context> context = Context::New(isolate, nullptr, global);

众所周知，js 有一个全局空间的概念，这里我们创建了三个函数 printjs，loadjs，strLength，并将他们绑定到全局空间中，这样我在创建好的 app.js 中就可以直接使用这三个函数

然后看这段代码

// Enter the context for compiling and running the hello world script.
Context::Scope context_scope(context);
// Create a string containing the JavaScript source code.
Local<String> source = String::NewFromUtf8(isolate, "loadjs('app.js')");
// Compile the source code.
Local<Script> script = Script::Compile(source);
// Run the script to get the result.
Local<Value> result = script->Run();

这里我们做了两件事，一个是通过 loadjs 加载了 app.js 这个文件，然后编译这段代码，去执行他，下面是 app.js 的源码

printjs("hello world")
function hello() {
  printjs("from yeanzhi")
}
hello()
var patt1 = new RegExp("e")
var myDate = new Date()
var arr = []
arr.push("2fjdsaf")
var i = 5,
  j = 1
var res = i + j
printjs(res)
if (i == 5) {
  printjs(true)
} else {
  printjs(false)
}
while (i < 10) {
  printjs("yeanzhi is supermen")
  i++
  printjs(i)
}
printjs("==============>>>>>>>>>>>>>")
printjs(strLength("yeanzhi is supermen"))
printjs(arr[0])
printjs(myDate.getTime())

loadJS

loadjs 中做了几件事情，首先拿到需要执行文件的内容，然后编译，执行，输出结果，下面是源码

void loadjs(const FunctionCallbackInfo<Value>&args){
    v8::String::Utf8Value v8Str(args[0]);
    std::ifstream f(*v8Str);
    std::stringbuf buf;
    f>>&buf;
    Local<Value> result =           Script::Compile(v8::String::NewFromUtf8(args.GetIsolate(),     buf.str().c_str()))->Run();
// Convert the result to an UTF8 string and print it.
    String::Utf8Value utf8(result);
    printf("\n%s\n", *utf8);
}

运行

运行 helloV8 这个 target，会发现在 js 文件已经成功的执行

总结，v8 就是一个解析器，通过加载 js 文件的内容，在 v8 中编译后就可以执行 js 文件。node 就是基于这个做的，我们会在 node 的 Projects 里面发现 v8 的项目，和我们刚才下载的是完全一致的。

v8 在 node 0.10~0.11 这段时间中进行了一次惨无人道的升级，波及相当多的 api，导致网上能搜索到得大部分内容都不再适用了，如果想了解更多 v8 地内容，可以去这里获得https://developers.google.com/v8，如果以后有时间，我会在写一些 nodejs 的源码分析。

yixi RSS Feed

UI组件库思考

问题定义

选型原则

候选库速览

推荐组合

落地策略

注意事项

结论

AI开发助手-外置知识库思考

AI开发助手

场景1

场景2

场景3

利雅得出差游记

基建&环境

生活习惯方面

人方面

思考

知识管理-AI笔记(AI大脑)

langgraph思考

双向语序

什么是双向语序？

1. Unicode双向算法（UBA）

2. 字符类型分类

3. 方向控制标记

Unicode符号表

1. 文字顺序混乱

2. 嵌套方向错乱

3. 标点符号错位

4. 数字显示异常

各技术栈能力

参考

国际化-RTL

什么是RTL？

RTL适配的核心挑战

1. RTL交互设计

2. 文字混排（Bi-directional Text）

3. 跨端容器适配

4. 自定义控件适配

RTL适配规范与方案

1. RTL切换机制

2. 文字处理

3. 布局适配

4. 图标处理

5. 动效与手势

主流跨端框架的RTL方案

1. React Native

2. Flutter

3. Web方案

国际化（i18n）和本地化（l10n）区别与联系

1. 定义

国际化（i18n）

本地化（l10n）

2. 区别

4. 一句话总结

国际化项目中 ICU 是什么

ICU 的核心功能

1. 文本格式化与解析

2. 字符串比较与排序（排序规则）

3. 字符编码转换

4. 复数规则（Plural Rules）

5. 性别敏感文本（Gender-aware Formatting）

6. 断行（Line Breaking）和文本边界检测

7. 时区和国际化日历

前端（Web）的 ICU 实现

** i18next + 插件**

与普通 i18next 的区别

i18n要素

一、货币本地化

1. 货币符号

2. 货币精度

3. 货币符号位置

二、时间本地化

1. 时制系统

2. 时间格式

3. 剩余时间表达

三、度量衡系统

1. 距离单位

2. 重量单位

i18next + 插件