Posts

1. 前言 《泳者之心》于 2024 年 5 月 31 日上映，这部根据真实故事改编的影片，讲述了 1926 年 8 月 6 日，特鲁迪・埃德尔从法国出发，耗时 14 小时 31 分钟横渡 34 公里英吉利海峡并打破纪录的故事。这一成绩比当时的男子纪录快了近两小时，特鲁迪也因此成为历史上首位成功横渡英吉利海峡的女性。 影片开篇的舒缓配乐十分抓耳，没有高亢或悲伤的情绪，只是静静陈述一段故事，却让人隐约感受到一种隐忍而坚强的情愫。 镜头从远景逐渐拉近，从模糊变得清晰，随即展现女主特鲁迪涂抹油脂的画面，面对波涛汹涌的冰冷大海，观众很容易就代入到故事之中。 2. 电影的主旨 这部电影的内核与《摔跤吧！爸爸》相似，都在探讨女性面临的困境 —— 女性生来似乎就被预设了相同的命运。 《摔跤吧！爸爸》中，爸爸马哈维亚因两个女儿有摔跤天赋，不顾世俗嘲讽，选择跳出这种命运轮回，培养女儿吉塔和巴比塔成为摔跤手。 他希望女儿们能获得奥运金牌，更重要的是让她们能够选择自己想要的人生。 而在《泳者之心》里，扮演引路人角色的是妈妈葛楚。与《摔跤吧！爸爸》不同的是，吉塔曾有过迷茫和放弃，特鲁迪却从始至终从未怀疑过自己的实力。 她坚信自己一定能成功，即便付出生命也在所不惜，展现出更为坚韧的内心。 3. 电影逻辑 影片的整体逻辑，包括情节铺垫和故事发展的流畅性，都处理得合理到位。 开头提到因轮船出事，许多女性因不会游泳而丧生，再加上妈妈的双胞胎姐姐 7 岁时溺水身亡，这些情节为妈妈葛楚一直支持特鲁迪两姐妹游泳提供了充足的理由。 特鲁迪游泳之所以如此厉害，除了自身的努力，还因为她在麻疹这种致命疾病中幸存下来，这从侧面印证了她的坚强。 为了游泳，即便面临不能在室内练习、每天需要搬煤烧锅炉等刁难条件，她也敢于应对，因热爱而迎难而上。 她比其他人更优秀的原因在于，除了上面提到的天赋和努力，她从小就在大海中学习游泳，不断挑战更高难度的副本，强度是不一样的。 还有，最后三个人在海边等待时，裸泳男比尔先发现特鲁迪也合情合理，因为他作为泳者，又经常在海边，对海上事物的敏锐度肯定高于其他两人。 因此，在剧情逻辑方面没有明显硬伤，至少我没发现特别突兀的地方。 4. 有点小瑕疵 但我认为影片存在一些可能的瑕疵，主要有三点：姐夫的笑太过刻意、未体现是否坐船熟悉过路线、遇到水母群时为何不让船先开道。 当特鲁迪在家庭聚餐中宣布要横渡英吉利海峡时，姐夫的大笑显得太过刻意。虽然导演想通过这种不可思议的态度来表达当时人们的普遍轻蔑，但时机选择有待商榷。 起初爸爸听到妈妈要让两闺女加入游泳队时的大笑尚符合逻辑，一来受当时社会背景影响，二来没有成绩支撑，别人不信也正常，表现得直接些也情有可原。 可这次不同，特鲁迪早已今非昔比，她已是当时的世界第一人。从幼时患麻疹幸存，到初学游泳时不被看好，再到后来夺冠，诸多不可能最终都变成可能。她经历了各种磨难，并证明了自己，甚至之前为拿到横渡英吉利海峡的赞助，还打赌要在 3 小时内从纽约游到新泽西，全程约 11.3 公里，她还赌赢了。 所以，姐夫没理由有如此反应，即便再不可置信，也不至于这样大笑，这种反应更像是一个平时跑 1 公里都气喘吁吁的人说自己明天要跑 30 公里时才会有的，这是导演处理的问题了。 特鲁迪都参加过奥运会、拿过各种奖项，想要横渡英吉利海峡，虽然感觉不可思议，但难道就一定是天方夜谭吗？有什么不可能的？那个大笑和整个画面格格不入，显得很割裂。 此外，影片中没有体现为横渡英吉利海峡做更合理的准备。虽然有裸泳者比尔作为导师，展现出专业的规划能力，还认识船长，可谓天时地利人和都具备了。 但我没去考证真实的流程，毕竟电影虽根据真实事件改编，却不一定要与现实完全一致。在影片中，是否应该多一些特鲁迪的练习镜头呢？比如坐船熟悉路线，了解大概位置、可能出现的问题及注意事项，这样是否更合理，还是说特鲁迪每年都去这个海峡，早已习惯？但看起来不像啊，毕竟出发点是在法国。 不然，看完总觉得特鲁迪就在海边练习了几回，也不知道练习时游了多远，然后第一次挑战就是全程了，这感觉不太符合挑战应有的行事逻辑，不过现实中比影视作品不合乎逻辑的情况比比皆是，也未必非得如此。 还有，遇到水母群时，为什么不让船先过去开出一条路，然后特鲁迪在后面跟着游过去，这样是不是就不会受伤了？可能有人会说不能借助外力，但不是还有补给吗？没道理不能这样做，如果怕跟在船后面，海浪卷起把她拖到海里，那就快速前进，稍作等待再游过去就是了，这一点我是没想明白的。 5. 转场 观影过程中，我猜中了两次转场，一次是小特鲁迪从水下冒出来，我就觉得要长大了，结果确实如此。还有一次是特鲁迪第二次横渡英吉利海峡时，弟弟从广播里听到消息，告诉了妈妈，妈妈不相信，说明天他们就回来了，让弟弟关了广播去睡觉。然后，妈妈在厨房做宵夜？我就想着等下就设计成因为邻居开了广播然后听到了吧，结果还真是。不知道在电影里有没有相关术语，只是凭感觉觉得下一秒会是这样。 影片最后，特鲁迪在大海中游泳，从黑夜开始，镜头慢慢右转，最终呈现她向前迎着朝阳的画面。这个转场设计真的太巧妙了。 ...

从 2023 年 10 月 22 日开始，我对自己说：如果能坚持每周更新一篇 ARTS 文章，就继续运营这个公众号并群发。 所以前面 10 篇都没有群发记录，基本是偷偷在写 —— 主要想验证自己能否坚持下来，万一失败了，反正也不会有人知道。 但当时心里一直想着：要做就做好，要么就不做。没有不清不楚、不黑不白、不上不下的中间地带。 这个打卡活动，我从 2020 年 4 月底购买陈皓《左耳听风》课程时就知道了，起初打算试试看，后来不知怎么就不了了之。这次重拾起来主要有三个目的： 平时上班敲代码的机会变少，想通过刷算法题保持对代码的感觉。 我有一份问题清单，记录着工作中遇到的问题、技术点和小技巧，但一直没整理，打算通过 Tip 模块倒逼自己梳理。 老生常谈的英语学习。 前期坚持的效果还不错，印象中没补几次卡，应该就是过年放假时间长了点，其他时候都还好。 起初计划每周阅读 Medium 上的文章，说实话，上面的文章质量真不错，而且这个网站没有广告，阅读体验特别好。 我做 Review 这件事的流程基本是：自己先看一遍，看不懂的用欧路翻译插件一键自动记录到生词本，了解大概内容后自己翻译，再用有道翻译原文，对比两者的差异。 这个模式坚持了一段时间后，我觉得 Medium 上的文章有时太长，自行翻译太费时间，加上需要翻墙，在公司看文章很不方便，于是换成在 Breaking News English 网站翻译新闻短文，一方面文章篇幅短，另一方面不用翻墙，还能了解新闻资讯。 在这个网站坚持一段时间后，有一天我突然觉得自己看英文文章不发怵了，不管多长都能硬着头皮看下去，总觉得自己马上就能看懂了。但这种感觉没持续多久，就又回归正常状态了。 说真的，我很讨厌英语，为什么要学这个东西呢？但后来我想明白了，“师夷长技以制夷” 的前提是你得懂对方在说什么。当然也可以用翻译软件，但学习一门语言就是在学习一种文化，只有了解了文化和风俗习惯，应对问题，才能游刃有余。这是翻译软件无法替代的。 坚持这个打卡活动到某个时间点时，我突然觉得差不多了，就是已经不需要证明什么了。当时计划在 2024 年 10 月 22 日结束这个打卡活动。 但刚好《黑神话：悟空》8 月底开售，我想自己都等了 4 年了，Windows 电脑和游戏手柄都有，装备齐全，没理由不去玩，一玩才发现，这质量也太高了吧，远远超出预期。 9 月初通关《黑神话：悟空》后，我真正对魂类游戏产生了兴趣，想起 2017 年买的《黑暗之魂 3》，每次玩都因为不知道怎么玩，也不看攻略，再加上都是骷髅有点吓人，玩了几次，实在玩不下去，就作罢了。 这次趁热打铁，我把老贼的《黑暗之魂 3》通关了，通关后才感叹这真是艺术品啊。它在我 Steam 游戏库里吃灰快 8 年，直到现在，我才真正体验到这部作品为什么是史诗级别的。接着我又通关了老贼的《艾尔登法环》，这部年度游戏也是神作，就不多说了。 前前后后花了很多时间在游戏上，ARTS 打卡活动就经常断掉，只能攒起来恶补，每周一次的打卡规定也形同虚设。 但我一点都不慌，也不觉得心虚，因为我已经不需要这些来证明自己能坚持这个打卡活动了。 我坚信，即使是现在，我依然可以按严格的每周一更频率坚持打卡，只是已经没有这个必要了。 从 2023 年 5 月 13 日陈皓过世到现在已经 2 年了，时间过得真快。 ...

这个问题最初出现在技术管理沟通群里，有群友提问：自己负责的项目任务已十分繁重，可领导还要安排新任务，不知如何是好。答应吧，担心自己所在的小组即便累死累活也难以完成；不答应吧，又怕惹领导不高兴。 我想起之前看《铁齿铜牙纪晓岚 4》时，有这样一段剧情：乾隆打算在凌烟阁挂上二十四幅功臣图，众人就谁排第一产生争执。乾隆使计让杜小月说出，若让纪晓岚进入军机部，也能像和珅一样出色，所以不同意和珅比纪晓岚厉害。乾隆顺水推舟，安排了角色互换的游戏，让纪晓岚去军机部，和珅去修四库全书。结果两人在处理不同部门事务时，因为缺乏经验，导致处处受阻，只能私下碰头商讨对策。 剧中，纪晓岚说皇上让自己查张廷玉的几块银两用在何处，觉得这点小事不必斤斤计较。和珅则表示，皇上安排的事情，最怕的不是大事，因为大事有章法可循，按章办理即可；最怕的是小事，没有先例，只能琢磨心思、见招拆招，所以对皇上安排的小事，要特别小心。 还有曾仕强先生在一期节目中说道：“如果老板让我去死，我到底去不去呢？” 他给出的回答是，先应承 “好的，老板”，然后自己不去就行了嘛。 从上述事例中，我们能得到什么启发呢？一方面要明白领导的用意，另一方面是不要直接拒绝领导。关键在于不要直接拒绝，而非完全不能拒绝。 其实核心还是 “先肯定后否决” 的策略，这和我们平时常用的标准反驳句式如出一辙 ——“你说的确实有道理，但是……” 如果是我，我会先一口答应下来，尤其是在多人场合。如果只有自己和领导两人沟通，拒绝的影响相对小一些；然而在多人场合直接拒绝，领导可能会觉得没面子。要是领导心眼小、心胸狭窄，日后难免会给你穿小鞋。所以，先痛快地答应 “好的”，然后过半小时左右去找领导，解释目前手头上的任务太多，若新任务时间紧迫，是否可以将其他任务暂缓？如果不能暂缓，多项任务同时推进实在难以完成，恐怕最后会顾此失彼。 这样做既能表明自己有积极完成任务的态度，又能说明客观条件不允许。领导的回应通常有两种：要么让你先暂缓其他任务，要么让你推迟新任务的完成时间，问题往往就能迎刃而解。当然，如果领导听不进建议，仍然一意孤行，直接干他就是了（哈哈哈，你敢信，我就敢说）。 由此可以延伸思考，领导安排任务时，必然有自己的考量。一般有两种情况：一是从当时的实际情况出发，认为由你负责更为合适；二是借此进行测试。培养一个人并非突然委以重任或提拔，而是通过日常工作中的突然考验，时不时来这么一下，看你瞬间的反应，从多个维度综合评估你是否值得信任、能否为我所用。 可能有人会说，公司的组织架构、管理方式和领导的性格等各方面情况都不一样，但我觉得核心逻辑是一样的 —— 先肯定后否决，只是在执行方式上，需根据实际情况调整。比如公司是扁平化管理，上下级没有明显的严格层级划分，而你对自己负责的项目情况又特别清楚，领导安排新的任务时，你完全可以直接当面解释目前的情况，说明加上新任务可能会导致的问题，而不必非要一口答应，等到半个小时之后才去找领导解释，那样做事就太死板了。 不过话说回来，工作和生活本就是一体的，但又不尽相同，人在上面的行事风格差异很大。工作上的这种测试是可以接受的，毕竟只是工作。但生活中类似的测试，真的不能接受，因为很没意思。

Algorithm 本周的算法题为 598. 区间加法 II 给你一个 m x n 的矩阵 M 和一个操作数组 op 。矩阵初始化时所有的单元格都为 0 。ops[i] = [ai, bi] 意味着当所有的 0 <= x < ai 和 0 <= y < bi 时， M[x][y] 应该加 1。 在 执行完所有操作后 ，计算并返回 矩阵中最大整数的个数 。 示例 1: 输入: m = 3, n = 3，ops = [[2,2],[3,3]] 输出: 4 解释: M 中最大的整数是 2, 而且 M 中有4个值为2的元素。因此返回 4。 实现代码如下： const maxCount = function(m, n, ops) { // 如果操作组为空，则表示都是0，直接返回m*n if (ops.length === 0) { return m * n; } // 找到最小的m和n let minM = m; let minN = n; for (let i = 0; i < ops.length; i++) { minM = Math.min(minM,ops[i][0]) minN = Math.min(minN,ops[i][1]) } // 返回最小的m和n的个数相乘 return minM * minN; }; 解题思路： 这道题其实还是很简单的，只是一开始会有点绕，不太清楚要讲什么，但是仔细观察就会发现，突破点就是这个 “矩阵中最大整数的个数”。因为所有的格子都要 + 1，所以，最大的整数只会出现在操作组a1、b1值最小的那个上面。所以，我们要做的工作，就是找出最小值的那个操作组。 Review Carlo Ancelotti leaves Real Madrid to coach Brazil - Breaking News English Lesson ...

现在我们的需求梳理方式，基本上就是一句话。什么意思呢？就是有一个需求文档，项目负责人把要做的事情依次列出，再对其进行评估，如果需要设计原型，就安排产品进行功能原型设计，如果需要提供解决方案，那么就先安排自己或其他开发成员提供解决方案。 好像没有什么问题？其实，真正的产品需求文档，也就是俗称的 PRD 文档，是很规范的，就不说什么形式上的问题，比如文档信息、版本更新历史、名词解释等等。就光内容的要求，就很精细。就拿 APP 的 PRD 文档来说，是需要把原型的图片贴到文档里的，然后要对每个功能和交互进行说明，比如点击这个按钮，会出现什么弹窗，弹窗的布局是什么样子的，内容是什么，文本是什么颜色的，是使用什么字体的等等。比如，XiaoPiu 的官方示例： 这样详细的好处是，在之前的文章《16 - 项目的任务质量如何保证》中已经有过类似的叙述，那就是避免需求边界不清晰，导致后续的返工。 但是，对于我们现阶段而言，项目的需求应该怎么梳理呢？这个怎么说呢？如果是在大公司，分工比较明确，那么这样做无可厚非，精益求精未尝不可，但是，如果是中小型公司，或者只是一个部门，要自负盈亏，考虑到实际工作中的产出，或者说性价比，那么就感觉有点过度精细了，说好听点，是追求极致与差不多这个度怎么把控的问题，说直白点，是怎么利益最大化的问题。 所以，从实际情况出发，虽然 PRD 文档规范化，有诸多好处，但是投入产出比显然很低的，因为没有那么多人手把这个需求做到这么精细的程度，加上平时沟通也很及时，有什么问题及时沟通处理就行，而且，PRD 文档规范化还有一个重要的目的是，为了和其他部门或其他公司进行沟通交流使用的。 可是，只是我们部门内部使用的需求文档，就没必要这么精细了，只要能做好这件事情就行。但是，虽然是一句话需求，但还是有优化空间的，我们做不到整个文档规范化，但对这一句话的需求，可以规范化。 上面说的是 PRD 文档的规范问题，但其实，对于需求的整理，可以遵循需求的 INVEST 原则。需求的 INVEST 原则最早由 极限编程（XP）的倡导者 Bill Wake 提出。这一原则旨在指导敏捷开发中用户故事的拆分与编写，帮助团队更高效地管理需求，确保故事的可交付性和价值性。 INVEST 原则主要用于优化用户故事的描述，使其满足以下特性： 独立性（Independent）：故事之间减少依赖，便于单独开发和测试。 可协商性（Negotiable）：避免过早锁定细节，鼓励通过沟通逐步完善需求。 有价值（Valuable）：每个故事必须为用户或客户提供明确价值，避免资源浪费。 可估算（Estimable）：团队能评估工作量以制定迭代计划。 短小（Small） ：单个故事工作量控制在几天内，以降低风险。 可测试（Testable）：明确验收标准，确保功能可验证。 结合我们部门自身情况，需求来源其实很多的，所以可分为两种，一种是部门外，另一种是部门内，如果是部门外，需要加上角色；如果是部门内，角色可不加。可以简化为，是谁？要做什么？为什么？ 这里就以设备管理功能，写一个示例参考： 深圳客户希望能看到自己有多少台设备，方便统计和日常维护。 是谁：深圳客户 要做什么：看到自己有多少台设备 为什么：方便统计和日常维护 通过这种方式，既能保证需求的清晰性和可操作性，又能在现有资源条件下实现需求梳理的优化，为项目的顺利推进奠定基础。