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）：明确验收标准，确保功能可验证。 结合我们部门自身情况，需求来源其实很多的，所以可分为两种，一种是部门外，另一种是部门内，如果是部门外，需要加上角色；如果是部门内，角色可不加。可以简化为，是谁？要做什么？为什么？ 这里就以设备管理功能，写一个示例参考： 深圳客户希望能看到自己有多少台设备，方便统计和日常维护。 是谁：深圳客户 要做什么：看到自己有多少台设备 为什么：方便统计和日常维护 通过这种方式，既能保证需求的清晰性和可操作性，又能在现有资源条件下实现需求梳理的优化，为项目的顺利推进奠定基础。

1. 前言 项目发起测试时，首先要在 OA 填写软件测试申请单。填好之后，由项目负责人准备当前版本的测试用例，交给测试部门，同时沟通确定测试周期，之后才正式开始项目功能测试。 2. 线上版本出现明显的问题 最近有个线上平台，客户反馈说平台里有个列表的按钮怎么点都没反应，而且弹窗的样式也错乱了。可这个版本明明是测试通过才上线的，这就说明测试环节肯定出问题了。 3. 问题产生的原因分析 为什么会出现这种情况呢？ 主要还是测试流程有漏洞。因为项目负责人提供给测试部门的测试用例，只包含了当前迭代的需求。所以测试的时候，测试人员就只测了新增加的功能，而出问题的那个功能是旧功能，因为不在迭代的需求范围内，所以压根就没测。 按理说，这个旧功能没做任何改动，怎么会出问题呢？ 后来发现，在开发当前迭代需求的时候，有可能开发人员不小心动到了这个功能的代码，或者是在修复其他小问题的时候影响到了它。 还有可能是当前迭代需求其实和这个功能是有关联的，但我们只关注了迭代功能有没有完成，根本没管那些关联功能，这才导致问题在实际使用的时候暴露出来。 4. 测试流程改进办法 为了解决测试覆盖不全，又不想每一轮都全部测一遍浪费时间的问题，我们优化了测试流程： 项目负责人这边要提供完整的测试用例，还要标注清楚当前版本里哪些功能必须测试，哪些不用测试。 测试人员分三轮进行测试： 第一轮，不管标注的是不是必须测试，把平台所有功能的测试用例都过一遍； 第二轮，专门验证已经修复的 Bug，同时再把那些必须测的功能测一遍； 第三轮，等所有 Bug 都修好了，确定没什么大问题了，再把平台全部功能的测试用例再过一遍。 这样一来，既能保证测试全面，又不会做太多无用功。

我为什么要跑步？ 这个问题一下难住我了，我突然不知道怎么回答，也不知道是从什么时候开始，对跑步有一种说不上的喜爱，喜欢跑步好像挺代表一个人积极向上的精神面貌？兴许就是这样吧。 以前的跑步安排是有问题的，哪怕一段几百米的路程都要记录到行走分类中，这些太精细的做法，直接导致这个事情是一个不容忽视要认真对待的事情，这么精神紧绷专注的做法，只能给自己增加难度，跑步不是一个任务，不是你每天下班回来，还要像工作时，那么用心专注解决的难题，而不容任何疏忽，我现在觉得这个做法太过于苛刻了。 人毕竟不是机器，要像弹簧一样，松弛有度，有紧有松，这样在工作和生活中才能做好调整，如果一直高度专注的投入，可能会有弹簧崩断的时候。 跑步应该是一种恩赐，是一种享受，有时我在想，我已经足够幸运了，还能跑步，有的人连自己身体健康都是一种奢求，而对于我而言，我还能跑步，没有什么比这个更让我感恩的了。 在去做这个事情的时候，要放松身心，该步行的步行，该浪费的时间就应该浪费，每时每分每秒都要计较，那么真的太累了。 用心去感受它。

是紧扣主题，还是东拉西扯？ 开门见山 抛砖引玉 冰山理论 吊胃口