Maeiee的2023

一、建立跨端 FT，带领技术团队

我的团队原本只有 2 个人（加上我），今年 Leader 成立一个跨端 FT 让我带，会有 5+ 同学交给我带，加上合作方，能有 10 人的一个大团队。

我属于技术流，管理是我的弱项，我准备借着这次机会，磨练一下自己的管理能力。具体目标包括：

1. 搭建跨端 FT，建立完善的制度，保障 FT 稳定运转
2. 学习管理相关的知识，建立管理方法论
3. 学会放权，不要什么都自己干，给同学们成长的机会
4. 与合作方持续建立良好合作关系

这将是一个低情商 Geek 笨手笨脚学管理的故事。

二、Flutter 动态化技术研究

这是我今年研究的重点。在公司里我们有自研项目（起个代号吧，后文中都叫做 A 项目好了），目前是不对外公开的，我也不会在博客中透露关于内部项目的任何细节。

我更多的是围绕互联网上已有的开源项目，以及编译原理课程知识来进行介绍，这些都是不涉密的。

具体目标包括：

1. 参与 A 项目的共建，在其中从小白演进为项目核心开发者角色
2. 将 A 项目在我们的业务中成功落地，并成功拿取业务收益
3. 彻底掌握 A 项目的原理，有能力进行重构
4. 读《Crafting Intercepters》的后半部分
5. 学习 dart_eval 和 flutter_eval 这两个库
6. 学习 C/C++ 语言
7. 研究 DartVM 源码

这将是一个大型技术项从研发到落地的故事。

三、刷题看看外企机会

我有 7 年工作竟然，从头到尾只在 1 家公司呆过，堪称奇迹。今年萌生了看看外面机会的想法。

我主要想了解的是外企，外企互联网或者外企传统软件开发。

主要原因在于，国内的互联网实在是太卷了。而且在我看来，卷的毫无意义。随着互联网的退潮，这种感觉更加强烈。我想有更多的个人时间，我不想那么卷。我想做一个按照正确方法做事的事情，不需要那么极致，不需要分秒拥抱变化，有稳定的预期，把该做的做好就好。

具体目标包括：

1. 刷 LeetCode：因为我没跳过槽，所以我也没刷过 LeetCode，我毕业找工作的时候，正赶上移动互联网泡沫，也幸运躲过了这一劫。出来混，迟早是要换的，这不，躲不过了吧
2. 了解市面上外企的机会
3. 准备简历：最基本的，不必多说

这是一个刷题加了解市面外企行情的故事。

四、量化炒股

我很纠结要不要搞量化炒股，因为我自诩为终身学习者，有点看不上这种投机倒把。但话说回来，这年头能干的事情是在是太少了。做独立开发者吧，一大堆规章制度、许可证，将个人拒之门外。搞自媒体吧，作为社恐，也没那口才。做海外吧，收款也费劲。

思来想去，合规合法的，那就是炒 A 股了，对个人参与者也友好。

我这么说是很大言不惭的，我也没问问 A 股，我惦记它的收益，它惦记我的啥？（本金）

还有一方面，是量化炒股其实比较纯粹，基于 Python 科学计算技术栈，清洗清洗数据，搞搞数学计算。我其实把它当作一个放置类游戏，因为我本身玩游戏比较少，平时只玩 Android 登山赛车2、PSP 实况足球 2014、铁血联盟2（极少玩了），需要有个娱乐杀杀时间。从游戏角度来看，炒股瞬间成为高级趣味了。

具体目标包括：

1. 跟随牙医小赵的脚步：复现他的量化之路，感谢牙医小赵接近 200 篇专栏的积累，他真的是一个牙医，并且代码都是在手机上敲的，这是我知道的第2个用手机写代码的神人（第1个是雪碧虾）
2. 写一个量化专栏：我发现我的探索也可以是一个很有趣的故事，比起挣钱来说，我对写这个故事更感兴趣

这是一个小韭菜量化炒股（被割）的故事

五、学习计算机基础知识

料想外企面试的时候，计算机基础知识考察会更多一些吧。今年我会减少造蹩脚的车轮，多读几本书，多学点理论知识，别瞎折腾了。

还有一个原因，是年初这场家中变故，打散了我的心气儿。现在的我，一心只想读点纯粹、纯净的知识。

具体目标包括：

1. 学习 Linux：使用 Gentoo Linux（以前用过），翻译 Gentoo Wiki（以前也参与过翻译）
2. 学习网络知识
3. 学习 Git

Gentoo 是我多年的夙愿，年轻时候忙着挣钱没时间捣鼓，现在虽然也是忙着挣钱，但是没心气儿了，有时间捣鼓它了。

这是什么故事呢？权当作资深老社畜挑灯夜读的故事吧。

六、健康养生

经过疫情越发感受到健康的重要性。

具体目标包括：

1. 每天自带午饭
2. 学习营养相关知识
3. 锻炼审题

1.0 找本管理的书

准备挑选一本管理相关的书，趁过年这段时间充充电。

相中的有：

• 《掌控自己：轻松构建高效的个人管理模型》：这本书特别偏生活化，特别接地气
• 《目标：简单而有效的常识管理》：物理学家写得，他设计了一个软件，这本书相当于软件的说明书，这一点比较吸引我
• 《授权：如何激发全员领导力》：这本书名字击中了我的痛点，我就只会自己干，不会把活分给别人干

于是第一本书确定了《授权：如何激发全员领导力》！

1.1 《授权》 评语笔记

“领导者——追随者”模式 →“领导者——领导者”模式

全书的主旨。也是我对跨端 FT 的期望。因为我是 FT 的虚线 Leader，对同学没有强管控手段。我只能给到同学成长的机会，激发他们的自驱力，自己谋求成长与成绩。

让决策权遍布团队

什么叫做放权，把决策权给到负责的同学，并且自己少插手。

我总是担心别人能力不行，事情做不好，因此过问各种细节、层层把关。到最后事情成为我一个人的，参与同学哪怕是“负责人”，但实际的负责人还是我自己。由于缺乏责任感，同学们也会变得相当被动，最终变为纯粹的执行，进入一个恶性循环。

美国海军圣塔菲号核潜艇的故事

一个美军核潜艇上的故事，马凯特艇长带领全员，通过管理革新，焕然一新。从而总结出的方法论。

如何调动员工积极性

满足建功立业的需求，恰当的奖赏、团队归属感、自尊心、支配感、达到标准的能力。

1.2 《授权》 献词笔记

只对重大决策进行确认，完全不参与 95% 的决策

定量参考。

每个人都认为自己能发挥更多的才智和价值

我所在团队目前并不是这样。规划是从上到下分发的，由于上层对具体细节不完全掌握，制定出来的仅仅是迎合上层，但是不接地气。层级还不只一层，等最终落到执行的同学时，只会是张大嘴巴说不出话的无力感：这都什么啊？行吧，领导说啥就是啥。想要争辩，想想还是算了。

工业时代的“控制”→ 智能时代的“释放”

时代在进步，生产力不断提升，原本需要多人的工作，现在一个人就能完成（比如在 ChatGPT 加持下）。这不仅是工作量的变革，有更加深化的意义。

领导力理解：通过高超的交流技巧，让人们意识到自身价值、潜力，使他们拥有强烈的意愿。

能激发出来吗？我不太相信。回顾我自身成长经历，我更多是通过主动争取机会，赢得领导的信任，展示出可胜任的能力后，领导才放权给我的。如果在缺乏主动性、能力担当前提下，硬放权，能行吗？

比如说，我跟跨端 FT 同学说，我们的目标是开圣塔菲号潜艇，我相信大家的能力和潜力，大家放手去开吧，我相信大家！能行吗？隔行如隔山，这种忽略现实约束，强行打鸡血，我不排除能够调动大家积极性，翻船了怎么办呢？

1.3 《授权》 前言笔记（1）

久而久之，我们会停止尝试，变得循规蹈矩，浑浑噩噩。我们终将递上辞呈，逃离这样的厄运。

道出了我内心的想法，要不是我觉得研究管理比较新鲜好玩，我自己也准备打退堂鼓了。我想组内高潜力的同学也是这样想的吧。

由于员工们缺乏激情和担当意识，你想做的事会处处受限。你可能试图激励他们使用决策权，却发现他们更倾向于服从命令。虽然许多授权模式都有不错的出发点，却无法持续推进。

想法是好的，落不了地。为啥落不了地呢？跟人性和大环境有关。责任伴随着风险，尽管负责意味着升值加薪，但是搞砸意味着贬值甚至滚蛋。同时在业界行情不好之下，机会没有那么多，大家会趋向于保住一份稳定的工作。

选择循规蹈矩，即选择平庸，最起码不会犯错。相当于把风险转回了上级，而上级拥有更多的话语权，在更上级那里有更多周旋的余地。最终结果就是，尽管循规蹈矩，上上级也无可奈上级何，上级也无可奈下级何，最终大家相安无事，平稳度过这一年。

“领导者—追随者”模式：领导者拥有权力，指导他人的想法、计划、行动，并通过这种方式获得他人的服从、信任、尊敬和精诚合作。

我就是在这个模式下成长起来的。我自驱力强，成长性高，并且能与领导交心。只要领导不亏待我，我们之间就能建立良好合作关系。

在跨端 FT 里这个模式行不通。因为我是虚线 Leader，我没有权力去“亏待谁”、不“亏待谁”。在我这干得好，是很难换来真金白银的，这是由各个同学的实线 Leader 所决定的。我对此完全理解，并且认同，打工挣钱天经地义。也有重感情的同学想跟我大干一场，我都会全对方先满足他们实线领导的要求，再考虑我，不要“主次不分”。因为我知道，这不能感情用事，得按规矩来。

1.4 《授权》 前言笔记（2）

领导者—追随者：适用背景是体力劳动，能够最大限度地攫取人们的体力劳动。

体力劳动和脑力劳动有什么区别？体力劳动生产力方差更小，可替代性更强。脑力劳动反之。

为什么脑力劳动不适用这一模式呢？我的看法：决策需要创造力，创造力来自于独立思考。而追随服从会降低独立思考，限制创造力，从而无法自主决策。由这一矛盾造成。

反过来，体力劳动用领导者-领导者模式会怎样？体力劳动重在集体执行，不需要多想，想太多反而耽误干活。

换个角度，我团队的工作是体力劳动还是脑力劳动？80%是体力劳动，20%是脑力劳动。体力劳动指做业务需求，脑力劳动指服务底层的技术架构。意识到现状后，我团队应当使用一种混合模式：参与体力劳动的同学，需要有有魅力的领导者带领，希望有更多挑战的同学，加入到领导者-领导者模式，大家共同冒险。

授权失败的原因：所传达的信息和所采取的方法内部矛盾。表面信息是“授权”，但具体措施是“由我来授予你权力”。从根本上看，这实际上是剥夺了员工的权力，淹没了信息中着重传达的内容。

授权与放权有什么区别？区别在监督的强度。我还能插手管得了你，这就是授权。我不插手了，好自为之，这就是放权。

剥夺了员工的什么权力？剥夺了员工的决策自由、信任感、加重压力焦虑，导致害怕出错。

淹没了什么重要内容？淹没了自由和源动力，淹没了是否发自内心。犯错是不好的，发自内心地试错是好的，发自内心地在试错中成长是最好的。

“领导者—追随者”模式中，组织的表现与领导者的能力联系紧密。领导靠短期成就、关注、赞赏吸引追随者。他们一旦缺席，将会给组织的表现带来巨大影响。从领导者的心理来看，他们会将此看作是一种自我成就，极具诱惑力；从追随者的心理来看，这是一种削弱集体智慧的做法。

没有领导者能够一直成功，领导者也不需要一直成功。好胜心和胜负欲会诱惑领导者走这条路，止于犯傻事的那一刻。

这种事对于领导者有诱惑力，尤其是处在众星捧月的位置上，最终一定会摔下来，除非自己是神不是人。对最随者来说，尤其是出色的追随者，未必服气，因为他们的才华被压制，屈才不说，还培养了虚伪。

为什么不直接说“我计划”呢？“我计划……”“非常好！”

我很少问同学“你计划什么”，我说的最多的是“我计划什么”。怎么这么像黄晓明的名言，而且我我是他的同乡……

这句话我记住了。当我放权以后，我就问对方“你计划什么”，然后我鼓励地说“非常好”，给同学传达到“亲自负责”的感觉。

“亲自负责”的感觉：对我来说，亲自尝试负责制订瞭望团队训练计划的能力和决策权成为我的一股强大的推动力。我抱着期待的心情“拥抱”瞭望台的值班时间。工作结束后，我会花几个小时研究和设想训练瞭望团队的新方法。

我工作中的成长即来自这种“亲自负责”感觉的正反馈。区别在于我像作者那样主动，组内同学并不主动，因此需要我来激发。未来在周会上，我会重点问大家有何计划。

在勇于担当的前提下，剥离传统组织中对团队成员不必要的控制。我们发现，“掌控”的达成需要称职尽心的员工清楚地了解组织目标。因此，当组织控制剥离后，“才能”和“阐明”需要相应地被加强。

这段话道出了全书的主旨。放权后如何掌控全局，避免一放就乱，或者一放就坏。关键在于还是需要人才（称职尽心、才能）以及阐明目标。其中后者是我能做的，前者是客观情况决定的。

我能做很多很难得事情，团队内同学可能做不到。但问题是：是否要做很难的事情才能成功？答案是不见得。我想，只要大家各自为战，各自酣畅淋漓，形成的收益比一两件“难事”更大，而且更接地气。

1.5 对放权的首次尝试

组内周会时，我跟组内同学（就1个）同步明年规划。

我说：“明年（年后）成立跨端 FT，我打算彻底放权，打算把各个方向完全交给同学们，各自负责，我不多插手。有没有哪个方向是你想承接的？”

这是一个开放性问题，让我没想到的是，对方立刻就给了我答复。

同学：“某项目最近工作原因，经手比较多，这个项目就放在我这里吧。”

我没想到立刻就能给到我答案，其中有感情元素，因为我们已合作多年，但我想这对我是一个极大的鼓舞。

1.6 第一部分 重启（1）

我给部门长官宽泛的指导并让他们准备任务清单供我参考，而不是我自己给他们罗列详细任务清单。我会询问他们应该如何解决一个难题，而不是告诉所有人他们应该做什么。我让各部门军士长直接沟通，而不是指望我扮演协调各部门的中心枢纽。

这段话堪称 How-to，我每一项都没有做好。列举下来：

1. 下达模糊、宽泛的目标
2. 由负责人给出任务计划，自己不越俎代庖
3. 向负责人提出问题，而不是具体指导
4. 让相关方直接对接，自己不做中心枢纽

这 4 条准则清晰准确，后续按照这个来，试一试。

虽然我想让我的团队掌控更多的权力，但是我之前对此深信不疑的想法已消失殆尽。虽然我给予团队决策权，但是他们总是做出糟糕的决定。

我最担心的事情就是它，这也是我为何坚持“领导-追随”模式。因为我知道，只要我一放，整体质量一定会下降，一定会出乱子、出岔子。

好在我的 Leader 给了我信心，他跟我说：“你尽管放，出乱子就出乱子。”他都不怕，我还怕什么呢？我逐渐明白，团队要走的是最适合团队的道路，而不是最适合我价值观的道路。适合团队的道路是由同学们一起谱写的。哪怕出乱子在所难免，车停在路口，也是选择道路的机会，这是一场暂时且必要的迷茫，之后我们会找到正确的路，并且避免沿着错误的路走到黑。

我感觉权力的来源是内心深处，授予权力的尝试有一种操纵某人的感觉。

对应一种心理，一件事，自己想要做，跟别人要求自己做，是不一样的。哪怕这件事自己感兴趣，别人一说就没意思了。哪怕是打游戏，如果别人说：晚上你玩某某游戏吧。我第一反应是我为啥非要玩这游戏？我玩别的不行吗？一股无名火涌上心头，哪怕晚上玩这个游戏确实如我所愿，我也想都不会想。这是一种逆反，不喜欢别人操控自己。

1.7 如何成功发起跨部门合作项目的 Kickoff？

总架构组喊上相关方，为 2023 年的一个项目进行 Kickoff，效果不太成功，大家都一脸懵逼。我的 Leader 借此机会，与我们讨论了：如何成功发起跨部门合作项目的 Kickoff？

1. 会前：Core 层面，提前拉齐，达成共识
   1. 与上层对齐目标，Why？What？How？优先级、里程碑、资源投入
   2. 与干系人对齐目标，背景/上下文对齐，达成合作一项（必要时找老板站台）
2. 会中：大规模达成公式、认可、分权到人，
   1. 整体背景介绍
   2. 现状，包括：
      1. 整体现状
      2. 各部分现状
      3. （共建项目，要肯定共建方的成绩）
   3. 规划：
      1. 各干系人规划提炼，汇总规划
      2. 项目规划，以及与各方规划的节奏匹配
   4. Owner：确定项目对接 Owner
   5. Next Todo：确定最高优事项，作为下次主题，同时 FT Run 起来
   6. 挂大王：Cue 老板站台

我的感悟：

1. 天时：战略层面，经历灵魂拷问，达成共识
2. 地利：顺应老板/部门战略，获得老板支持、站台、资源投入、关注
3. 人和：
   1. 协调相关方，合并需求同类项，达成主动合作意愿
   2. 调动团队人才梯队，微观层面为同学们带来意义、成长与发展机遇

1.8 学 Fibery（1）：Smart Folders

简单来说，在 Spaces 下，在左侧菜单中添加目录。但这不是简单的目录，Smart 的含义是，基于 Database，由用户设计多层级目录，并且支持排序与筛选功能。

这个工具给我带来的惊喜太多了，设计地真好！

相关笔记：《Fibery：SmartFolders》

1.9 学 Fibery（2）：Context Views

Context Views 与 Smart Folders 一起使用。这是一种函数化思维：数据库相当于 Data。Smart Folders 相当于 Lambda，Context Views 用于对 Smart Folders 这种 Lambda 进行可视化。

我的感受：① 清晰（函数式思维）② 优雅（领域模型）③ 优美（富体验的低代码搭建）

受此启发，我在构思一个东西：

• 在文件系统中，存在多种文件（Markdown、Org、Excel、PDF、图片、视频、网页……）
• 每个文件相当于一个对象。设计一种协议，让它们之间可以拼接、组合，并且协议本身也是一个文件。
• 每个对象有一个 Render，比如一个 WebComponent。拼接就是对这些 WebComponent 的组装。
• 基于对象衍生一套查询系统：Tagging、Query……
• 以及一套事件驱动系统：on_create、on_update
• 以及对对象元数据的支持与扩展

跑题了，跑题了……

相关笔记：《Fibery：Context Views》

1.10 学 Fibery（3）：Report 低代码生成图表

使用 Fibery 通过低代码搭建了一个图表，对我的博客流量进行可视化，整体操作跟 Excel 差不太多。（图中的广告收益是真实的，当个乐子看就好，不必当真）。

但是，我突然意识到，博客流量这个 Database，它是可以与其它模块打通的，我想到几个场景：

1. 比如通过 Fibery 可以搭建 OKR 系统，假设博客运营是一个 Objective，OKR 的 KeyResult 可以直接连接到博客流量 Database。并且用户可以给 OKR 添加大盘式的 Metric，直接转化为达成率。
2. 再比如可以和项目管理交互，比如上线一个功能，可以通过函数自动计算出该功能上线后的流量变化，用来评估收益。
3. 再或者，比如还有一个营收模块，可以自动对各个子 Database 中的收益、开销汇总，形成更加聚焦的盈亏统计系统。

我不打算投入精力研究博客运营，每天就这么胡写我自己已经很开心。

我将 Fibery 与我们公司内部正在用的项目管理做对比，结果让我感到震撼，简单来说，我们内部的系统弱爆了。具体来说：

1. 内部系统是一个枷锁，将流程固化。这会带来问题：谁规定的流程？流程合理吗？流程操作效率？整合度？
2. 内部系统由专门的效率团队研发，由效率团队的 PM 规划。这导致，一个入门产品经理教全公司的技术专家做事。
3. 也许会说，有需求你可以提嘛。但问题是，业务千变万化，大家有各种各样的定制化需求，这是满足不过来的。效率团队疲于奔命，只是积累债务，难以自恰。
4. 最终，这套枷锁卡住了所有人的生产力，造成损失后被废弃，我想这是它的归宿。
5. 问题出在哪里？问题出在系统的设计理念上：一个好的系统，不是要约束用户，而是要给与用于自主权，激发用户的创造力。
6. 不要理想地追求银弹、一招鲜，让大家和而不同，百花齐放。
7. 系统设计的关键，在于建立共识，建立共同语言。让不同的花之间，可以交流，可以借鉴、继承，可以相互整合演化，形成一个丰富有活力的生态。

1.11 第一部分 重启（2）

当上级确立目标而给予我广阔自主权去考虑具体做法时，我的表现是最好的。

我快速成长的背后，我的上级就是这么做的。现在我也要这么做，给同学们提供空间。

将领导者的技术才能与组织表现挂钩的做法令我感到困扰。

并不是说，领导者不需要业务能力突出。

而是说，一个团队，如何把每个人的才能叠加起来。而不是仅有领导者一个人的才华。

要知道，领导者也是从小白一步步走过来的。

如果团队无法执行一个计划，那么无论该计划多么巧妙，都是毫无意义的。

我与 LD 之间，在很多事情的讨论上，总是对不齐。这句话使我茅塞顿开，原来大家立足的视角不一样。

从我个人视角，我是从自己能力出发，一是自己做厉害的事情，而是从这个视角看团队中的同学，希望大家都做厉害的事情。前者需要占用团队的大量资源，后者有些要求过高，难以实现。

从 LD 角度，他是从团队视角来看待的。团队的整体能力是决策基础。如果一个巧妙计划，只是占用我一个人力资源的时候，他是能够接受的，并且这也是他期望的，即能够以小博大、开疆拓土。但如果涉及到更广范围，让更多同学做更难、更有挑战的事情，他会犹豫，会选择风险更小，收益更稳（也更小）的项目。这是合理的。

回到我个人角度，我要明确边界，首先是我一个人力资源下，如何以小博大、开疆拓土，这是 LD 对我的最大期待。第二点，是在跨端 FT 上，我不能强求什么，而是努力给组内同学提供提高的机会，如果有同学愿意试，或者 LD 愿意投，那么上马，否则，机会错过就错过，不要偏执。

1.12 上班首日与 Leader 项目沟通

年前因为家里事情，很多事情没有来得及沟通。年后回来第一天，跟所有相关方聊了一圈。挺有意义，值得一记。几个相关方：

与 Leader 沟通：

• 明确了今年的重要规划：Flutter 动态化 + 跨端 FT。动态化项目 LD 对我技术放心，没有多聊。主要聊了跨端 FT 如何安排人力资源，涉及到人和事的关系单独说。
• 跟 LD 明确了我今年放权的管理思想。由于我之前是偏执把控的管理类型，LD 对我的转变还是很惊讶的。我的回答是不同的发展阶段需要不同的管理方式。
• 目前最高优的是确定跨端 FT 要做哪些事情，具体见人和事的关系。
• LD 对去年年底我们走的一次技术弯路不断复盘，那是另一个故事，教训概括成一句话：一定要审时度势，认清现实。
• 跨端 FT 的 Kickoff 要提上日程了，要不然赶不上 OKR 节点。

我的感悟：

• 我觉得目前最关键的，是草拟出跨端 FT 的章程，通过制度来保障整体框架、整体决策的正常执行。
• 我作为 FTO，最大的责任就是让整个 FT 在科学的制度下可靠运行，同时实践我的放权管理制度，激发同学们的潜力。

关于放权管理对答：

• L 简称领导，M 简称我自己
• L：FT 人给你了，你怎么管？
• M：今年我准备采取充分放权的方式，同学们认领项目后，我会将项目完全移交给他们，由同学们自主决策。
• L：方法没问题，但是不能放任不管，跑偏了还是要把控。
• M：执行过程、方案评审还有要由我来把关，但是我只对重大问题管控，其它的我不会插手。
• L：那如何保证同学们最终执行落地的质量呢？
• M：首先要看对质量的标准。如果按照我的标准，来衡量同学们，一定是过于严苛的，按照我的标准，大家大概率达不成，最终演变为我下场主持。既然今年打算放权，我会把衡量视角更换，更换到具体的同学身上，从同学的能力本身出发，首先他要做自己力所能及的事情，做力所能及的产出，自己有了成长，那我就可以认可他的质量。
• L：你这么放权的话，根据我的经验，初期的认知拉齐非常重要，我很担心同学们要么跑偏了，要么最后做不出东西。
• M：初期认知拉齐确实很重要，我近期主要在做这件事情。对于后者，我主要是给同学们提供机会，帮助大家起步，并通过 FT 机制维持各项进展持续。当一件事情经过讨论立项后，会写入同学们的 OKR，之后的阶段，由各个同学们根据自身努力去争取了。
• L：这些都是理论，等进入实践的时候，根据我的经验，你会发现很多事情会不一样。
• M：是的，我对这次管理工作挺兴奋的，期待进入实践环节。

根据对话深挖一层：

1. 圈同学们进入 FT，是没法实现把我复制成没人一份的，LD 的期望是我能带领他们，扩大整体产出
2. 这里面有个问题，书中说道：“领导者—追随者：适用背景是体力劳动，能够最大限度地攫取人们的体力劳动。”简单来说，研发团队是脑力劳动，堆人对于深度提升有限，我的知识和经验没法复制给他们。
3. LD 既怕我完全放任不管，又怕我管得太细。但是经过谈话，我想他对后者已经不再担心了（他对我的这个转变很意外），反而是担心前者。
4. 这里面有个躲不开的话题，人召齐了，干啥呢？

关于人和事的关系：

• 人召齐了，干啥呢？
• 跨端 FT 中的工作，主要分为几类：
  • 多年运作下来的经验模式（引擎升级、疑难 Bug 修复、混合路由迭代）
  • 业务迭代过程中产生的需求：图片库、将 WebView 封装到 Flutter 里面去、业务架构、状态管理……
• 今天我跟骨干同学聊完之后，我发现一个问题：实打实的事情，大家啃不动，不敢接。
• 比如说 Flutter 引擎升级，没人敢碰，也没人愿意碰，导致我想收个徒弟传承收益都没办法。我也跟 LD 明说了，要是哪天我走了，这个部分缺失是致命的。但是他并不担心，也不知道是不怕我会走呢，还是不怕这块出问题。
• 在今年事情的确立上，主要分两部分：一部分是那些必须做的（经验模式）。关键是第二部分要发动同学们了，如果我自己提需求，同学们认领，那还是领导者—追随者模式（说实在的，我离着业务比同学们更远，他们在这方面比我更加务实）。
• 因此，跨端 FT 当中，必须有一种机制，是能让同学们畅想，并引导他们构思业务收益，然后在跨端 FT 机制下，建立一个评审专家委员会机制，对项目进行商讨立项工作。而我的主要任务，就是让这件事情发生。当然，我也需要给同学们提供一些背景，我去年准备了一张 Flutter 全景图，给同学们一些输入，让大家根据自己的兴趣选择。

1.13 两个方向成功放权

昨天与今天，两个核心项目，我分别放权给了两个核心同学。因为大家都已合作多年，阻力会相对小一些。

放权沟通方式：

1. 项目认知拉齐：背景、上下文、目标要求。
2. 管理方式拉齐：说明我管理方式的转变，重点介绍放权，强调我这是真放权
3. 说明利弊：项目经过评审立项后，写入 OKR。最大的变化在于，失败了就是失败了，我不会救。
4. 启发主动性：说明后续的规划和讨论都由负责人主动发起，我不主动过问，自己负责。

两位同学聊下来，相较于往年我布置任务，明显感觉，今年放权方式：

1. 对待问题明显认真了：看戏和唱戏的区别
2. 压力值明显升高：升高不只一个量级

也产生了好的效果：

1. 第2天，负责人就提出了一些见解，是我没想到的，特别好。我按照书中讲到的，以“非常棒回应”。
2. 真的激发出了负责人的主动性

这跟 PUA 有什么区别？这是我心底一直存在的一个问题，所谓放权，说的很好听，到底是不是 PUA？

什么是职场 PUA：

• 经过查阅资料，指一系列精神控制方法，让下属失去自我，摧毁自信心和判断力，最终对公司唯命是从
• 常见手段：
  • 一：不断否定：一味否定，不给建设性建议。PUA 无疑，目的是降低自尊，调教出听话员工，无条件服从。
  • 二：人身攻击：通过否定摧毁自尊，使对方失去反抗甚至认同。
  • 三：制造焦虑：制造焦虑、恐惧，“大环境不好”、“裁员”、“绩效”。
  • 四：设置无法实现的目标：根本完不成的目标，且时间紧，且不给申辩机会。剥夺员工个人意志。
  • 五：美化压榨：打着“给机会”、“看重你”，理所当然地压榨你。

妈呀好可怕，我感觉跟放权之间，可能一念成佛，一念成魔。就像鲁迅说的，读死书害己，一出口就害人。如果我读书读个半吊子，执行走了样，表面是放权，实际变成了 PUA，那我不会轻饶自己这个傻X。

我想做一个正常地管理者，如何反其道而行之？

1. 尊重下属：这是最基本的。能力好不好另说，人格是平等的，不能否定别人。更不能打击别人的自尊心，这是做人的底线。人身攻击更是恶劣地不必多说了。
2. 不贩卖焦虑：这一点倒是还好，我管理方式属于有事干事，没事大家哪舒服哪呆着。这也导致凝聚力差点，但也少了很多社交压力，我也不会贩卖焦虑。
3. 从人本的角度设定目标：这一点我觉得对我挑战最大，也是我今年的一大转变
   1. 我对自己有着很高的目标要求，加上性格原因，在他人看来，过于严苛
   2. 权是放出去了，如果还拿我这一把尺来卡大家，这就是给大家设立不可能实现的目标，这会把跟我征战多年的战友们坑了
   3. 怎么办呢？根据每个人的实际情况，按照他们的实际能力和特点，因人而异，指定适合他们、且他们也擅长的
4. 压榨：这一点如何避免呢？我想是给大家拒绝我的权利，不想做可以不做，就这么简单。并且这是不带贬义的，不想做这个，再看看想做哪个，做想做的。当然这里面也有人情的成分，总有一些不得不做的棘手事情，总有有情有义的伙伴帮你抗下，恩怨分明即可。

该尊重的都尊重了，标准也降低了，不想干的也不干了，年底的成绩如何保证呢？

对这个问题，我想说的是，在我的价值管理，成绩是在团队与人的健康发展下达成的。如果说一些成绩，需要通过压榨他人去实现，这样的成绩我宁可不要，另请高明吧。

不折腾是关键。这两天章程制定了一大堆，但我希望章程是这样的：

1. 写的时候多，做的时候少。大部分文字都是顺理成章的。
2. 就像房子一样，动线设计的好，大家就不会老是撞墙，甚至感受不到墙。但是也不能随心所欲，有墙做约束。
3. 牢记到时候做的时候，制度负担越少越好。太重就玩不起来了。

1.14 管理者的 NAT 打洞

作为负责人，自己就像一个网关，内部团队和外部团队的消息都在我这里汇聚，需要通过我来分发。

“最讨厌这样的领导了，整天啥实事不干，就会抢功劳、摘桃子、合并周报！”我也讨厌这样的领导，所以我也极力避免成为这样的人。我自己承担最难的技术项，自己是架构主程为所有业务架构负责，自己从在最前面解决底层 Flutter Engine 崩溃。

但是事情汇聚在我这里是个事实，当然，抢功劳、摘桃子这种事情我是不会干的。

在尝试放权之后，我的下面有了一个个独立运转的子系统，于是我会把外部的链路，第一时间对接到对应子系统上，是不是很像 NAT 打洞？

比如今天，外部门同学找到我，希望就某某系统聊下细节，我第一时间就把放权给的责任人推了出来，甩锅速度堪称光速，我自己都乐了。

虽然显得我这人不太抗事，但我觉得这是必要的：

1. 真放权：如果消息经过我过滤一道，再给到对应负责人，那我就是干预了，这不是真放权。我撒手不管，不负责任，反而是真放权。
2. 该同学应对地非常出色，一切考虑周全、按部就班。
   1. 这么想想，我以前把事情都揽在自己手里，的确没必要。同学们依然能按照自己的做事方式做好。甚至，做得比我更好，这一点我是承认的。
   2. 同学们确实得到了锻炼的机会，很多人，就缺这些锻炼机会，把机会给到有需要的人。注：要允许并尊重拒绝，不要强制、打压，否则就成了职场 PUA。
3. 该同学主动约我沟通：主动与被动关系完全扭转了，一位同学的领导力被焕发了出来，可喜可贺。

很好，这样各司其职，我也可以关注到我的事情上：跨端 FT 筹备，Flutter 动态化技术上面。

1.15 章程生效 + 把管理方式说出来

随着 FT 筹备脚步地加快，实践的程度不断加深。这两天我草拟了一个跨端 FT 章程，因为想到无规矩不成方圆，要有章可循，果然发挥了效果：

1. 章程的核心解决天时、地利、人和：
   1. 天时：搭建需求池，开放提案机制，任何同学可以带着想法找到评审委员会评审
   2. 地利：项目管理机制，从立项、OKR 拆解、进度同步，都有固定机制维持组织健康运行
   3. 人和：设计虚拟组织架构，划分角色，为同学们提供适合自己的参与方式
2. 在具体讨论时，很多问题都能落到章程的已有流程中，降低了交流成本。比如想做一件事情，变成发起提案，评审通过即可立项。达到了自由度与科学性之间的平衡，并且也合理，同时保持了参与同学的积极性。

我今年转换了管理风格，怎么能传达给大家呢？我采取了最简单直接的方式：把管理方式直接说出了：

1. 对 Leader：今年我采取完全放权的方式，给到同学的权责是对等的，我要维护负责人的权责对等的完整性，保护他不被摘桃子，让他有安全感，才能发挥出领导力，说白了，干成了是自己的
2. 对同学：章程里明写着，项目失败或者出现线上事故我都不会出手，由负责人自行承担。只有这样才是真放权。当然，失败与事故对我个人的成绩也会有影响，我愿意冒这个风险，给同学们提供施展机会。最终如果干砸了，我有不可推卸的连带责任，该我承担我就承担。

把管理方式明说之后，效果正向大于负向的。

1. Leader 内心里担心，但是他也没法表露出来，只能先走走看，怕失败只是一方面，他担心的东西更多
2. 同学们的主动性倒是真的焕发出来了，今天又有同学领导性思考，特别好。看到大家开始独当一面，我觉得这些都值得。

1.16 负责人带着方案找我聊，开心！

周一把项目授权出去就没在管，今天周四，对应负责人就带着规划来找我聊了！我很惊喜，很开心。

这也印证我之前犯了大错：该同学，在我们过去管理的认知中，认为主动性不强。今天的事实狠狠打了我的脸，事实上就是我过去不会管，不会带人！

这件事，教会了我：

1. 人人都有主动性。什么是主动性，是意愿、兴趣、难度、冒险、挑战、成就感、性格契合、感性、环境、生存等多种因素结合下，个人的一种选择。
2. 人人都有喜欢的事情，都有喜欢的做事方式，做喜欢的就有兴趣干，感到不喜欢了，就没兴趣干。
3. 每个人都有自己的兴趣特点、擅长的事情、做事的方式，要按照各自舒服的方式做事
4. 要给人以足够的尊重与信任，给他施展的空间和自由，给他自主决策的权力与机会

我是怎么应对的呢？

1. 我对现实满意（规划产出速度快，规划方案写得非常好）：直接夸赞，写的好，速度快，相关方沟通到位，写得好，比我想得还好（实话实说）
2. 建议：作为管理者，在规划阶段该提的建议要题，该定的要求要定
3. 约下次沟通：更好地交流方式是，我对规划非常感兴趣，希望你能继续完善，下周可以约我继续聊

防职场 PUA，我很怕自己一念成魔，一错再错，今年把大家坑得更惨。回顾职场 PUA 的 5 大手段：

• 一：不断否定：我没有否定，该夸就夸，该完善的就提建议，就事论事。沟通完对方的自尊是上升的
• 二：人身攻击：同上，充分尊重对方，给对方提出不同意见的空间，给对方拒绝的权力（我的建议可以讨论、可以拒绝）
• 三：制造焦虑：沟通完全建立在轻松愉悦基础上，双方完全不焦虑。
• 四：设置无法实现的目标：高目标可以题，但不作为硬杠杠。脑暴的想法可以题，实际按照每个人实际情况出发，只要体现出工作量、体现出思考、体现出成长，就是好的工作。只要从个人情况出发，做的好，那就是好。至于那些高目标，只是奋斗的方向。务实、实证。
• 五：美化压榨：怎么理解压榨？我想剥夺自主权是一种压榨。强迫透支工作也是一种压榨。一种是精神上的压榨，一种是肉体上的压榨。我想，我给了自主权，同时也让负责人自主安排实践，应该不算压榨。

我还是担心自己压榨了别人。什么是工作？工作是付出合理的劳动换取对应的薪水。我作为管理者，对为同学们规划合理劳动的场景，舒心工作的心境，开放开明的交流环境。并且通过内省，识别出自己不切实际、不好的想法，并以章程的方式保障决策的合理性。我还是要努力提高，还是那句话，读死书害己，一出口就害人。

1.17 成员参与精力碎片化下，如何维持跨端 FT 可持续

我负责的跨端 FT，FT 的全称是 Feature Team，是一个虚拟组织架构，组员是从各个团队中，按照 0.5 个人力抽调而来的。所以说，我这个“Leader”是要打引号的，我的掌控力是低于实线管理者的。

其中，最大的问题是组员的精力投入。大家平时主要工作是业务开发、版本迭代，在发版后才有精力投入到 FT 中，也就是说，大家的精力是碎片化的。

精力碎片化和频繁上下文切换，要重点关注，因为我们之前犯过这个错：

• 安排一个业务同学排查一个 Flutter 引擎底层问题，研究这个问题需要对 Flutter 引擎的底层代码有了解，需要对 C/C++、OpenGL 有了解。但是该同学大部分时间被业务占用了，只能隔上半个月投入一两天、隔上半个月投入一两天。
• 业务开发是非常复杂、烦人的，我自己就是业务出身，深有体会。再加上头顶悬着一个大问题，学基础知识吧——根本学不完，研究问题吧——也搞不清楚，再加上 Leader 每周都关注进展，你就说窒息不窒息吧！
• 运作了一段时间后，我们发现我们犯错了，赶紧终止掉。不是说同学不行，完全是管理者的错，对不起这个同学。

精力碎片化和频繁上下文切换，这是现状，要基于事实出发，如何应对呢，我的思考如下：

1. 做力所能及的事情：不要强人所难。要从同学的实际出发，做符合他的能力特长、时间精力的事情。这也就是说，实际的目标并不是管理者制定的。
2. 由同学自己提出目标：自己最了解自己，管理者提供的是方向，在该方向下，大家根据自身实际情况，制定目标。
3. 自行安排时间：这也是基于对同学们的尊重，尽可能地减少不必要地压力。提出不切实际地目标，让大家失去理智，疲于奔命，结果就会好吗？我不这么认为。

管理这么松散大家干不出成绩怎么办呢？

1. 首先，跨端 FT 是在大家完成本职工作后，作为附加项提出的，属于 Better to Have。要分人看待：
   1. 对于职级高，有责任参与跨端建设地同学，如果结果不 OK，需要给出理由，如果是因为更高优事情导致的计划变更，这没有问题。并且我作为 FTO，应当及早发现资源冲突，即使搁置目标，使同学精力能够聚焦于更加高优事项中。
   2. 对于向前一步，勇于迎接挑战的同学，只要付出了，虽败犹荣，甚至仍然有奖。勇气与主动承担本身就是一种美德，需要提倡。
   3. 对于在职级范围内，该做的没做好的，这部分是需要关注的。但是由于跨端 FT 是一个 Better to Have 的事情，最终还是要根据本职工作成果综合考量。

让大家提出目标是不是领导不作为？

1. 什么是领导不作为？ChatGPT 告诉我：领导不作为是指领导在有责任和义务时却不采取行动或不履行职责，导致工作失败或组织问题不得到有效解决。这种情况通常对员工、团队和整个组织产生不利影响。
2. 我觉得作为领导者得给方向，在方向下制定目标。而不是让同学们自己想方向，自己定目标。领导者负有领导与规划的责任，不能自己不动脑子，从同学们那里白嫖。
3. 我想这一点我在跨端 FT 中有做到，因为我规划了一系列跨端核心项目，这些项目的目标是确定的，并不是漫无目的地把责任推卸给大家。
4. 但是同时，我也想把跨端 FT 打造成一个创意孵化器，当然，这个是 Better to Better to Have 的，并不是一个硬指标，更不是白嫖大家的幌子。
5. 在具体执行方面，我给大家提供了空间，让大家自主决策。但是从我自己来说，我的主要精力依旧是承担全年最难的技术项目（跨端 FT 同样分担我一部分精力，但是只占 30%），所以我依旧奋战在第一线，同时该我承担的管理责任我也尽力承担，我我想我应该不算不作为。

1.18 继续摇人，摇齐了

今天又聊了 2 个同学，将跨端 FT 的核心同学聊完了。两位同学聊的过程分别如下：

A 同学，年轻，技术潜力大：

• 更加习惯上级指派的工作方式，对我的放权方式有些迷茫。我如何应对呢？
  • 坦诚：坦白我也从来没试过这种方式，对我来说也同样迷茫
  • 同心：我们一起学习，一起探索。比起立威，我更希望立心，因为我是利他心的。
  • 科学合理的制度：走心的缺点是过于主观，因此还要靠完善的制度来保障，所以说我还是要完善制度建立。
• 双方都比价内向：
  • 我们合作多年，但是因为双方都比较内向，工作上交集较少，导致没有深交
  • 随着加入 FT，我要给更多、更加主动的交流

B 同学，经验丰富，工作年限长：

• 对各方面的规划，没有提出太多的看法
  • 这也是工作经验的体现，因为从我自己看来，我都知道细节上还存在很多问题
  • 所以我索性就把我工作中存在的问题直说了，该我的问题我不逃避
  • 打消顾虑，还是要我把各个细节想清楚，避免大家多做多错的情况

1.19 我开始犯不作为地错误了

再给 B 同学布置方向的时候，我因为对这个方向规划得不清晰，犯了不作为的问题（1.17）。我给了一个大方向之后，没有给出具体要做哪些事情，就让对方规划。

这一点我做的不好，我要弥补、改正。

1.20 跨端 FT 成功 Kickoff

今天成功举办了跨端 FT Kickoff 启动会议，效果比较成功，也算开了一个好头。也得到了 Leader 的认可。

趁热总结下经验，这次筹备一个项目组，我做对了哪些事情？

1. 制定章程：事不预不立，我把怎么立项、立项考虑哪些因素、参与同学的精力碎片化、周会制度、甚至不用订会议室，事无巨细，尽可能全部考虑清楚
2. 利他精神、换位思考：读死书害己，一出口就害人，我时刻牢记这句话。好心办坏事比害人更坏。利他不是形式，是真心、是信任。
3. 事前沟通：Kickoff 之前，我跟 FT 中每个核心同学都进行了 One One 沟通，坦诚、真诚，其实，在 Kickoff 之前，我已经与每个人达成了共识
4. 建立共识：会议的目标是达成共识，什么是共识，让每个人认可某个事情是这样的。有多种方式可以达成共识，比如凭感情，跟随某个老板多年，相互信任，哪怕这老板平时不太着调，他说是啥就是啥吧，并且拥护，这也是一种共识。但我追求的是，做事的正确方法、舒服方法，在事实层面的认可、共识。
5. 语言表述：同一句话，怎么说，效果有天壤之别，这是语言的艺术。由于我只想当一个 Geek、一个 Hacker，不想当所谓大厂高层技术领导，这种艺术我就不过多钻研了。我的目标就是，有话直说，相互尊重，不要伤害到对方，控制好情绪，克制不要胡说八道就可以了。
6. 承上启下：在会议的末尾，要对会议后续做什么事情达成一致，为下次会议要准备什么，都要确认好。就像链表一样，要把 next 指针指向下一个 Node，并如此迭代。

1.待定 如何建立高效有序的周会制度？

作为 FTO，一项基本工作是维持跨端 FT 的有序进行，周会是日常运作的基础。我有两个想法：一是高效，不搞没用的，少折腾。二是有序，有章可循，不混乱。

流程：会前周报填写，会中进度同步，会后问题讨论。

轮流主持人制度：

• 会议主持是一项辛苦活：预定会议室、周报建立、会前摇人、会上主持、会议纪要记录
  • 本着不折腾原则，能省就省：
    • 改成线上会议：省去预定会议室，好处是更加开放，更多同学可以参与
      • 添加小喇叭摇人机制：
        • 按下“提前通知”按钮：跨端 FT 周会快要开始啦！各方向负责人请更新周报及讨论议题
        • 按下“开会通知”按钮：跨端 FT 周会开始啦！请同学们上线，欢迎大家围观！
        • 按下“沙龙通知”按钮：跨端 FT 周会进入自由讨论环节，欢迎对 Flutter 感兴趣的同学上线参与沟通，交流~
        • 分发到不同的群里面，这些按钮不需要手动按下，跑脚本就可以了
        • 在搞一个自动化脚本，把这些东西全部自动化
• 培养大家的参与感与 Owner 意识，更加认同是 FT 的一份子

每个同学都是 0.5 人力投入，会出现如下情况：有事冲突，或者近期没有 FT 工作，无需参与，如何应对：

• 对主持人制度的影响：
  • 没法保证公平的付出，没请假同学多承担请假同学的工作
  • 主持人是必须的吗？主持人的作用是什么？可不可以没有主持人？
  • 弱化主持人环节，有事说事，无事散会

2.0 dart_eval 的 Compiler 编译器类

compileSource 方法包含了 Dart 代码如何通过 Dart Analyzer 转为 AST 的过程，并且解析了 Library 之间的相互依赖关系，比较复杂一下子看不懂，需要慢慢梳理。

今天只挖掘了一点点，主要是对各个实体类的了解。具体包括两类：Dart Analyzer 的实体类和 dart_eval 的实体类。

笔记：《Dart eval：Compiler 类》、《Dart Analyzer：Declaration 实体》、《Dart eval：BridgeDeclaration 实体类》、《Dart eval：DeclarationOrBridge 实体类》、《Dart eval：DartCompilationUnit 实体类》

2.1 dart_eval 的 Compiler 编译器类（2）

继续研究 Compiler 编译器类。

_buildLibraries 方法：该方法可以简单认为是，Dart 中源文件就是一个 Library，完成从 DartCompilationUnit 到 Library 的最终转化。

_expandDeclarations：declarations 表示声明，声明内部可能还有声明（如类声明内部包括成员声明），给方法将其全部解析打平，结果的 Pair 的 key 是打平后声明的唯一表示，Value 是对应的声明实体 DeclarationOrBridge。

Declarations 的继承关系梳理：bridge 体系下的梳理。

_resolveImportsAndExports：在依赖解析上，我还是没搞明白，给我整蒙了。

在进行依赖分析时用到了很多图相关的算法，我之前没有接触过。

在读代码时发现一处代码问题，提 issue：《Duplicate else if statement in _expandDeclarations function》

笔记：《Dart eval：Compiler 类》、《Dart eval：Library 实体类》、《Dart import 语法》、《Dart Analyzer：ImportDirective 实体》、《Dart eval：exportGraph 概念》

2.2 dart_eval Compiler 类流程梳理

过年期间一个月没看，回来发现都忘了……看着很陌生……只好循着过往笔记，对 Compiler 再梳理、提炼一番。

Compiler 类：

• 入口是 compile 方法，传入一个 Map，key 是 uri，value 是代码字符串，方法内使用《Dart eval：Dart Source》实体进行包装。
• 之后传入 compileSources，核心工作都是在这里完成的：
  • compileSources 中进行了各种各样的处理（这里我还没有看懂）
  • 最后返回了一个《Dart eval：Program 类》

梳理完，进度接上了，还在梳理 compileSources 中的各种处理。我发现梳理《Dart eval：Program 类》简单一些，先搞好搞的。

从 Program 类中的组成部分进行倒推会更好一些：

程序顶层声明编译逻辑：

• 对应于 ctx.topLevelDeclarationPositions
  • 赋值处：
    • compileMethodDeclaration
    • compileFunctionDeclaration
    • compileDefaultConstructor
    • compileConstructorDeclaration
  • 这几个方法有规律性，值得研究：
    • 《Dart eval：compileDeclaration》
      • compileSources 中有两处调用
      • compileClassDeclaration 中有一处调用

2.3 compile 系列方法的调用链

在 dart_eval 中，包含一些列 compile 方法，这是 Compiler 中最为核心的代码，它们负责将 Dart Analyzer AST 转换为 dart_eval 的 AST。

为什么不能直接用 Dart Analyzer AST 呢？有两个原因，一是编译器要输出 ByteCode，通过裁剪可以使得语法树结构更加精炼，减小体积的同时，Runtime 执行也会加快；而是需要考虑 Bridge，这一点原生 AST 是没有考虑的，只有 DartVM in DartVM 场景下，才会考虑互操作性。

笔记：《Dart eval：compile 系列方法的调用链》

2.4 Statement 与 expression 有什么区别？

ChatGPT：

• Statement：performs an action, doesn't return a value
• Expression：returns a value, can be used as part of a larger expression or statement.

2.5 dart_eval 我悟了

梳理完 compile 之后，我好像摸到了门道，一下子搞懂了很多东西。

这种顿悟时刻真让人高兴。

从笔记上也能看出今日的收获：《Dart eval：Compiler populateLookupTablesForDeclaration‎‎》、《Dart Analyzer：TopLevelVariableDeclaration‎》、《Dart eval：CompilerContext 编译器上下文‎》、《Dart eval：compileIdentifierAsReference‎‎》、《Dart eval：CompilerContext 编译器上下文‎‎‎》、《Dart eval：compileIdentifier‎‎‎》、《Dart Analyzer：Identifier‎》、《Dart eval：compile 系列方法的调用链‎》

2.6 dart_eval 作者竟然找到了我

这段日子研究 dart_eval 项目，得到了超乎预料的收获——项目作者居然找到了我！

他读了我博客中关于 dart_eval 的文章，称赞说阿妹子婴！还说没想到有人如此深入地研究他的代码（我才刚开始研究，还没上深度呢）。

还夸我对代码理解的好，我的文章甚至还帮他理解了他很久以前写得代码（放太久原作者都忘了，我成了最熟的了）。

作者还想把我的文章翻译成英文，作为官方文档，征求我的同意。

这件事可把我高兴坏了，真的是但行好事，莫问前程，只要付出，好运会自动找上门。

我准备这么回复：文章翻译成官方文档这事，我可太同意了。不仅如此，我还想一起参与到官方文档的建设中来，我对 dart_eval 很感兴趣，希望未来能参与到开源项目的维护与贡献中来。

2.7 近期 dart_eval & flutter_eval 开源参与

最近一周在参与这两个项目，跟作者保持密切沟通，间隔已经提升到 8 小时（中美时差），就好像一个上白班，一个上夜班，233333

都干了啥？

• 引子：我写了一堆 dart_eval 源码研究文章，引起到作者注意，顶着机翻愣是把我博客内容合进源码注释里了（我看到这位老兄也是一个热爱技术、热爱交流的人。我很愿意与他成为朋友，因此也打算更多参与这个项目
• 小试牛刀：读代码过程中，我发现一个多余的判断语句。我不好意思直接提 PR，因此先提了个 issue：Duplicate else if statement in _expandDeclarations function #83，由另外一个小伙伴提 PR 完成这一修复。（我一看我也能提啊
• 添砖加瓦：随着理解深入，我发现 flutter_eval 这个项目，好多功能还没有实现，这个工程都是体力活，按照一个套路对框架封装，没有太多技术含量。于是补充了一个方法封装：add dispose to StatefulWidget #43，顺利通过！
• 来点认真的：
  • 我创建了一个演示工程 flutter_eval_gallery，遇到一个问题：在我的 Windows 电脑上能运行，在 macOS 电脑上运行不了
  • 通过对源代码一顿 Debug，我提了一个 PR：try to fix compile error in DeferredOrOffset #87
  • 但是！这一次 PR 修错了！作者耐心给我讲解了其中关键类的工作原理。但是他对问题是认可的，给出了一些分析思路。
  • 问题看似陷入了僵局，但是我没有放弃！在我的持续研究下，我找到了稳定复现的路径，并将问题缩小到出错的变量，并保留了问题现场的关键变量值
  • 在我将问题范围缩小后，作者直接锁定了有问题的代码。相当于我从调试上，以及作者从原理上，双双锁定到同一处。作者给出了确信的修复思路，说我可以按照思路修改 PR，改好后他就可以 merge。
  • 我按照作者修复思路，调整 pr commit。
  • 最新状态：再等 8 个小时，等作者起床差不多就合进去了。

以上记录了我这段时间参与开源项目的过程，这是一个开端，是不是很有趣。随着我对这俩项目理解加深，后面可做的好玩的事情还很多，后续还会很有趣。

3.0 LeetCode 1813 句子相似性 III

没做出来，为什么呢？我没有理解相似的本质。

在没理解本质的情况下，我是怎么做的呢？我给长句子装入一个 List，短句子一个 List，然后遍历，对单词进行匹配，长句子 List 转换成一个有空洞的连续序列，然后再分析空洞与连续序列的关系。代码写得很长，最终被各种边界条件打败了。

相似的本质是什么呢？短句子添加一个部分可以变成长句子，该部分可以位于开头、中间、结尾。使用两个双指针。假设 s1 为长句，s2 为短句，在符合相似的句子中，短句子总是那个左右指针交换的：

1. 要么是左指针超过右指针：头部重叠、尾部追加
2. 要么是右指针超过左指针，头部追加、尾部重叠
3. 要么两者同时发生：相等，或者头尾重叠，中间追加

参照时叔的代码：

class Solution {
    public boolean areSentencesSimilar(String sentence1, String sentence2) {
        String[] words1 = sentence1.split(" ");
        String[] words2 = sentence2.split(" ");

        int left1 = 0, right1 = words1.length - 1;
        int left2 = 0, right2 = words2.length - 1;

        while (left1 <= right1 && left2 <= right2 && words1[left1].equals(words2[left2])) {
            left1++;
            left2++;
        }

        while (left1 <= right1 && left2 <= right2 && words1[right1].equals(words2[right2])) {
            right1--;
            right2--;
        }

        return left1 > right1 || left2 > right2;
    }
}

实现非常巧妙。如果不相似情况，短句子头尾碰不到一起去。

看到这类题目，要想到双指针，这是这道题带来的收获。

3.1 LeetCode 1814. 统计一个数组中好对子的数目

这题一看我就知道有诈……我还是选择了最忠实的实现方法，果然炸了（超时），跟我想的一样。

问题就变成了，如何看出其中的“诈”？苦思冥想半天，也没想出来，看了时叔的解答才顿悟。

巧妙利用了 HashMap 用来进行判等。将两重循环简化为一重。

其实，我第一反应想到了 HashMap（有进步），但是被那个数学等式给困住了。有一念我想过对等式进行变换，但没有贯彻。还是审题不够细致，匆匆去写那个忠实版本去了。我发现算法题审题很重要。

3.2 LeetCode 1817. 查找用户活跃分钟数

这道题还是比较常规的，HashMap 操作我也比较熟悉，因此一遍就通过了。尽管空间效率不高（运行速度还行）。

看到其它小伙伴的流式操作比较酷炫，有时间我也得学学。

3.3 LeetCode 1824. 最少侧跳次数

这道题只能说是照着官方题解抄了一遍，在代码中加了些“表面”注释，其实我自己还是不理解。

关于【动态规划】，后续要专门进行学习。

3.4 LeetCode 1828. 统计一个圆中点的数目

采用基础做法（双重循环）还是很容易做出来的，但是效率和空间都比较差。

按照基础做法一次对我就满足了，不纠结进阶的优化思路了。

3.5 LeetCode 1663. 具有给定数值的最小字符串

我在审题方面有进步，通过认真审题，搞明白了字典序的含义，进而想出了倒序排布字母，最终一遍通过，并且效率和空间表现都不错。

有进步，满意。

3.6 LeetCode 2309. 兼具大小写的最好英文字母

审题明显比以前有进步，题目审明白了，正确率也提升了。

这道题自己设计了一个小协议，并通过查表法进行规则匹配，自己还是挺满意的。最终一遍过，runtime 47.76%，memory usage 75.37%。

看到大家的做法中，采用了位运算，效率更高，妙啊！

3.7 LeetCode 1664. 生成平衡数组的方案数

又是一道中等题！这要是放在以前，我是做不出来的。现在，尽管最终执行效率比较低，但是我已经能成功做出来了，这就是进步。

由于审题能力提升，对题目的理解也更加透彻，按照互联网黑话，就是上下文拉齐了。围场打猎，剩下的就是构思算法。

我这道题的实现尽管效率比较低，但是比较符合我的思维方式，比较容易掌握。

3.8 LeetCode 2315. 统计星号

简单题，快速搞定，一次成功。

如果在面试中遇到这种难度的题目，已经能够轻松应对了。给自己点个赞。

3.9 LeetCode 1669. 合并两个链表

看到这是一道中等题，担心里面会不会有诈。结果发现只是一道常规的链表操作题。

我对链表还是比较熟的，因此轻松搞定。被题目绕多了，生怕里面有诈。

3.10 LeetCode 2319. 判断矩阵是否是一个 X 矩阵

简单题，现在的简单题已经难不住我了，轻松搞定，欧耶！

3.11 LeetCode 2325. 解密消息

简单题，同样轻松过关。我使用了一个 HashMap，在内存开销上有点大，看到大家的解法，其实用一个数组就可以了。

4.0 复现牙医小赵：《量化投资学习笔记188——实现经典交易策略——通道》

牙医小赵：一个持证牙医，业余坚持研究量化两年多，发表近 200 篇文章。我今年的一大目标，就是复现其研究成果。

参考书目《151 Trading Strategies》ZuraKakushadze,JuanAndrésSerur.

目标：① BackTrader 策略吸收进策略库 ② 复现回测效果 ③ 借鉴可视化结果 ④ 学参数优化及可视化。感谢作者将成果开源。

不开单问题：用 20 日最低价突破，我发现开不了仓，即每日的收盘价，通常不会低于 20 日最低价。周期调小后开始交易，但效果不太理想。

序列边界条件问题：应该从前一交易日开始统计，而不是从当前交易日开始。

笔记：《BackTrader 通道策略》

4.1 数据获取模块

如何获取股票数据困扰了我很久。作为一个软件工程师，我本能的想法是开发一套数据完整、完备、准确的系统，为此做了一些努力。

直到我看了牙医小赵（此后简称小赵）的代码，只有一个函数，寥寥几行，不过是免费数据 SDK 一个 API 的简单封装。

我深感震撼。数据不一致怎么办？不同股票数据周期不一致怎么办？错乱了咋办？

答案很简单：乱了就乱了，重拉一遍就是了。我逐渐领悟了小赵的思路，他把程序部署在服务器上，因此隔三岔五花上一个小时拉取全盘数据是一件没有成本的事情（机器放在哪里，不用白不用）。另外，小赵是以实验的模式在探索：准备数据、做实验、回收结果，如此往复。数据的生命周期只绑定在一个实验上，用完即抛。

如此看来，我是被我的职业经验给束缚住了。实实在在体验了一次：手里拿着锤子，看什么都是钉子。

基于我的试错，夸张一下，就好像：在量化团队里，一套量化交易系统，作为一个前端工程师，我惊慌失措道：“出大事了！这个按钮的 margin 没对齐！”

最后 70 多行代码搞定。又走弯路了！

笔记：《量化交易系统之数据模块》

4.2 历史数据增量更新

在《量化交易系统之数据模块》中，介绍了如何拉取单只股票一段时间内的数据。在本文中，介绍如何拉取全盘某一年的数据，并支持增量更新。所谓增量更新，在数据拉取时，自动跳过已经存在的文件，只拉取不存在的文件。功能拆解：

• 拉取全盘数据
  • 从命令行中读取年份
  • 获取股票列表
  • 生成标识/文件名：股票名称_起始日期_截至日期
  • 查看本地是否存在：存在，跳过；不存在，下载

代码完成后，代码量很少，且效果令人满意。

4.3 复现策略全盘回测

复现了小赵 TradeSys 中的 Research 全盘回测功能。在运行中报了一些异常，可能是数据完整性问题。总之，向前迈出了一大步。

下图是 Research 绘制的，策略在全盘回测场景下的总体性能：

我只跑了200种股票，没有全跑，全跑得耗费大约20分钟，不过有优化空间。

4.4 quantstats.stats.r_squared 决定系数

用来评判拟合的程度，quantstats 中提供了这个指标，用于衡量策略收益，与基准收益之间的拟合程度。

在我的全盘回测中，这个指标报错：对问题原因我有一个思路，我把基准指标掺在股票数据里了，导致出现基准与基准自身对比，完全重合。

问题原因记录：ValueError: Cannot calculate a linear regression if all x values are identical

4.5 第一次跑通全盘策略回测

将策略在所有股票上进行回测，并对回测结果进行统一评估。这也是基于小赵老师的框架，在我的二合一平板上跑了十几分钟。

可以看到某些指标可视化的时候，绘图还存在一点问题，后续分别调一调。这是一个里程碑！给自己点赞。

5.0 准备转移到 Gentoo 系统

十年前我曾是 Gentoo 用户，后来由于精力原因中断了，但我心中依旧惦记着它，希望有精力能够重启。十年之后，我觉得条件成熟了，于是准备重新我的 Gentoo 之旅。

我打算将系统安装在一个外置 SSD 中，这样有额外的好处：变成了便携系统。这个外表跟 U 盘一样的 SSD，插在主机上、插在二合一平板上，会进入同一个工作空间，并且能够充分利用不同硬件。更加厉害的是，在二合一平板的 Windows11 系统上，可以在 VirtualBox 虚拟机中挂载启动，兼顾了虚拟机场景，可谓一举多得。

5.1 VirtualBox 挂载物理硬盘

VirtualBox 常规用法是在文件系统中创建一个文件，作为虚拟机的磁盘。而本文中的做法，是直接将物理硬盘挂载到虚拟机上。这样做的好处，是硬盘上的 GNU/Linux 的系统，可以脱离虚拟机，电脑冷启动直接进入。

笔记：《VirtualBox 挂载物理硬盘》

5.2 Portage make.conf

Portage 在运行时会读取 make.conf 中的设置项，比如全局编译参数等。

照着手册传入 -march=native：让编译器根据 CPU 架构优化生成的代码。能为计算密集型代码带来巨大速度提升。Gentoo 用户中普遍使用这一选项。由于生成的代码仅针对本机，不易分发，在外界应用并不广泛。

后续规划：该从 livecd chroot 进去，安装 base 系统了。TODO：全局 USE Flag 还没有设置。

笔记：《Gentoo Portage make.conf.example》

5.3 ChatGPT 网络不稳定问题

我已经离不开 ChatGPT，但是在使用过程中，频繁遇到网络问题，导致使用效率很低。

有没有什么办法，能稳定可靠地使用呢？

网络资源：《ChatGPT 常见错误原因及解决方案》、《acheong08/ChatGPT》、《rawandahmad698/PyChatGPT》

发现一个 ChatGPT 的 VSCode 扩展：ChatGPT by Ali Gençay。跟 VSCode 结合做的很好，但是还是无法解决网络不稳定的问题。

经过探索，我发现这事关键还是跟不可描述的网络原因有关系。我尝试用不可描述的方面改进了一下，再观察下效果如何。

最终还是期待 ChatGPT 能早日开放 API，然后买一个付费会员，看看能不能解决这一问题。

5.4 Gentoo Wiki 翻译

过年期间碎片时间多，抽空翻一下文档：

• 《AMD64/常见问答》：翻译完善

• 《手册：片段/网络/模块化网络》：这篇目前只翻译了 3%，我提升到了 7%。

6.0 996社畜如何自备午饭？

这是我 2023 年目标的之一：每天自带午饭（我的+媳妇的）。但我每天下班很晚，并且很累，怎么能用最短的时间、花最少的精力，做一顿营养均衡的午饭呢？

这个题目很难，但是对于 Hacker 来说，难不是问题，Happy Hacking。

笔记：《996社畜如何自备午饭》

6.1 食材盘点，为第一周最准备

28、29 日我仍在休假，第一周（0130~0203）我就准备付诸实践。BootStrap 过程，我打算优先使用家中已有食材。于是对冰箱进行盘点：

7.1 放弃分布式

之前 Punk OS 搞得分布式过于复杂了，我准备把这些代码统统删掉，回归到最简单场景：一台单机的笔记本，在上面运行一个应用系统即可。