summaryrefslogtreecommitdiff
path: root/2025/05
diff options
context:
space:
mode:
authormuqiuhan <[email protected]>2025-05-27 06:06:45 +0000
committermuqiuhan <[email protected]>2025-05-27 06:06:45 +0000
commit4da1dc74954fafe4d21841892bafc955a37ac805 (patch)
tree85a1dfa32a37c0cbf63b7d6b3735ab854d707efb /2025/05
parentbb19987062af9a28aa5dea93cc0eba9ac3a7e1ab (diff)
downloadblog-4da1dc74954fafe4d21841892bafc955a37ac805.tar.gz
deploy: 74a1d57ead41454de540829cd6de5ba1f5702bd6
Diffstat (limited to '2025/05')
-rw-r--r--2025/05/07/nestjs-bullmq-mail-business/index.html16
-rw-r--r--2025/05/08/Multiplayer-Collaborative-Systems-tips/index.html8
-rw-r--r--2025/05/27/vertical-slicing-practice/index.html44
3 files changed, 34 insertions, 34 deletions
diff --git a/2025/05/07/nestjs-bullmq-mail-business/index.html b/2025/05/07/nestjs-bullmq-mail-business/index.html
index 33c566c5..0315b2b9 100644
--- a/2025/05/07/nestjs-bullmq-mail-business/index.html
+++ b/2025/05/07/nestjs-bullmq-mail-business/index.html
@@ -196,14 +196,14 @@
<ol>
<li>队列(在 NestJS 里由 <code>@Processor</code> 装饰的类)会被一个底层的 <code>Worker</code> 订阅。 </li>
<li>有新任务(job)进来时,Worker 会调用写在该类里的 <code>async process(job: Job)</code> 方法。 </li>
-<li>如果 <code>process()</code> 正常返回(即没有抛异常),Job 就被标记为 <strong>completed</strong>,然后才会去触发所有注册了 <code>@OnWorkerEvent(&#39;completed&#39;)</code> 的回调。</li>
+<li>如果 <code>process()</code> 正常返回(即没有抛异常),Job 就被标记为 completed,然后才会去触发所有注册了 <code>@OnWorkerEvent(&#39;completed&#39;)</code> 的回调。</li>
</ol>
<p>也就是说:</p>
<ul>
-<li>**<code>process</code>**:是真正“干活”的地方,收到 job 之后立刻被调用,任何主业务逻辑(发邮件/写数据库/第三方请求等)都应该放这里。 </li>
-<li><strong><code>onCompleted</code><strong>:只是一个事件监听器,</strong>在 job 已经成功完成之后</strong> 才会被触发,不会影响 job 的重试逻辑(也就是说,在这里抛错,job 已经算完成了,也不会重试)。</li>
+<li><code>process</code>:是真正“干活”的地方,收到 job 之后立刻被调用,任何主业务逻辑(发邮件/写数据库/第三方请求等)都应该放这里。 </li>
+<li><code>onCompleted</code>:只是一个事件监听器,在 job 已经成功完成之后 才会被触发,不会影响 job 的重试逻辑(也就是说,在这里抛错,job 已经算完成了,也不会重试)。</li>
</ul>
-<p>而我在此处的业务目的是 “用队列来做可靠的、可重试的邮件发送”,那么<strong>一定要把发送邮件的逻辑写到 <code>process()</code> 里</strong>,这样在 <code>commandBus.execute(new SendMailCommand(...))</code> 抛错时,BullMQ 会根据创建 JOB 时的重试策略(retry、backoff 等)自动重新入队。而把它放到 <code>onCompleted()</code>,只相当于 job 成功完成后的“事后通知”,一旦失败不会再重试,也无法利用 BullMQ 的锁、超时、重试机制。</p>
+<p>而我在此处的业务目的是 “用队列来做可靠的、可重试的邮件发送”,那么一定要把发送邮件的逻辑写到 <code>process()</code> 里,这样在 <code>commandBus.execute(new SendMailCommand(...))</code> 抛错时,BullMQ 会根据创建 JOB 时的重试策略(retry、backoff 等)自动重新入队。而把它放到 <code>onCompleted()</code>,只相当于 job 成功完成后的“事后通知”,一旦失败不会再重试,也无法利用 BullMQ 的锁、超时、重试机制。</p>
<p>举个最简化的调整示例,删掉 <code>onCompleted</code>,把真正的发信放到 <code>process</code>: </p>
<figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br><span class="line">28</span><br></pre></td><td class="code"><pre><span class="line">// ... existing imports ...</span><br><span class="line"></span><br><span class="line">@Processor(process.env.MAILER_QUEUE_NAME || &quot;gcpm-mailer&quot;)</span><br><span class="line">export class BullMQMailerProcesser extends WorkerHost &#123;</span><br><span class="line"> constructor(</span><br><span class="line"> private readonly commandBus: CommandBus,</span><br><span class="line"> private readonly logger: LoggingService,</span><br><span class="line"> ) &#123;</span><br><span class="line"> super();</span><br><span class="line"> &#125;</span><br><span class="line"></span><br><span class="line"> // ① 当有新 job 拉取到时,这个方法会被调用</span><br><span class="line"> public async process(job: Job): Promise&lt;void&gt; &#123;</span><br><span class="line"> const mailAggregate = new Mail(job.data.mail);</span><br><span class="line"> try &#123;</span><br><span class="line"> await this.commandBus.execute(new SendMailCommand(mailAggregate));</span><br><span class="line"> &#125; catch (err) &#123;</span><br><span class="line"> this.logger.error(`邮件发送失败,jobId=$&#123;job.id&#125;`, err);</span><br><span class="line"> // 抛出错误,触发重试或失败</span><br><span class="line"> throw err;</span><br><span class="line"> &#125;</span><br><span class="line"> &#125;</span><br><span class="line"></span><br><span class="line"> // ② onCompleted 仅在 process() 正常返回后触发,</span><br><span class="line"> // 不建议在这里执行核心业务(也无法触发重试)。</span><br><span class="line"> // @OnWorkerEvent(&quot;completed&quot;)</span><br><span class="line"> // async onCompleted(job: Job) &#123; … &#125;</span><br><span class="line">&#125;</span><br></pre></td></tr></table></figure>
@@ -213,9 +213,9 @@
<li>“Events → OnJobCompleted”:completed 事件只是一个监听钩子,不会参与重试。</li>
</ul>
<hr>
-<p>而 <strong>重试次数本身并没有一个硬性上限</strong>,完全由添加 Job 时通过 <code>attempts</code> 这个选项来控制:</p>
+<p>而 重试次数本身并没有一个硬性上限,完全由添加 Job 时通过 <code>attempts</code> 这个选项来控制:</p>
<ul>
-<li>默认情况下,如果不传 <code>attempts</code>(或不在 <code>defaultJobOptions</code> 里配置),Job <strong>不会自动重试</strong>(相当于 <code>attempts = 0</code>)。 </li>
+<li>默认情况下,如果不传 <code>attempts</code>(或不在 <code>defaultJobOptions</code> 里配置),Job 不会自动重试(相当于 <code>attempts = 0</code>)。 </li>
<li>如果在 <code>queue.add()</code>(或全局 <code>defaultJobOptions</code>)里设置了 <code>attempts: N</code>,那么 BullMQ 最多会让该 Job 运行 N 次(也就是初始执行 + N−1 次重试,或者根据文档含义最多触发 N 次失败) ,失败后才算真正移入失败集合。 </li>
<li><code>attempts</code> 可以是任意的正整数(受 JavaScript <code>Number</code> 范围限制),BullMQ 本身不会再做额外的上限检查。</li>
</ul>
@@ -224,13 +224,13 @@
<hr>
<p>还有一个需要注意的地方,在我的业务中,邮件发送的是一种时间区间报告,这个报告包含了过去二十四小时的一些系统中的事件,但如果重试有延迟策略或重试本身就有计算成本的话,这封邮件就不是 “过去二十四小时” 的了,因为重试带来了一个真空期。</p>
-<p>换言之,这个问题本质上是——<strong>重试导致「发送时刻」与「原始 24 小时窗口」错开</strong>,从而让邮件里报出来的数据不再精确。常见的解决思路就是:<strong>把「窗口定义」或者「报表内容」在调度时就固化下来,真正的队列任务只负责发送</strong>,而不再实时去重新计算时间区间。</p>
+<p>换言之,这个问题本质上是——重试导致「发送时刻」与「原始 24 小时窗口」错开,从而让邮件里报出来的数据不再精确。常见的解决思路就是:把「窗口定义」或者「报表内容」在调度时就固化下来,真正的队列任务只负责发送,而不再实时去重新计算时间区间。</p>
<p>我想到了两种解决方案:</p>
<p>一、任务参数里带上「时间区间」<br> 在 enqueue 的时候,就算出 windowStart&#x2F;windowEnd,然后把它放到 <code>job.data</code> 里。无论后面 <code>process</code> 什么时候真正跑,都是基于同一个时间区间去查询:</p>
<figure class="highlight ts"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br><span class="line">28</span><br><span class="line">29</span><br></pre></td><td class="code"><pre><span class="line"><span class="comment">// 调度时</span></span><br><span class="line"><span class="keyword">const</span> now = <span class="keyword">new</span> <span class="title class_">Date</span>();</span><br><span class="line"><span class="keyword">const</span> windowStart = <span class="keyword">new</span> <span class="title class_">Date</span>(now.<span class="title function_">getTime</span>() - <span class="number">24</span> * <span class="number">60</span> * <span class="number">60</span> * <span class="number">1000</span>);</span><br><span class="line"><span class="keyword">await</span> <span class="variable language_">this</span>.<span class="property">mailerQueue</span>.<span class="title function_">add</span>(</span><br><span class="line"> id,</span><br><span class="line"> &#123;</span><br><span class="line"> <span class="attr">mail</span>: <span class="keyword">new</span> <span class="title class_">Mail</span>(&#123;</span><br><span class="line"> ...options,</span><br><span class="line"> id,</span><br><span class="line"> <span class="attr">sentAt</span>: now,</span><br><span class="line"> <span class="attr">status</span>: <span class="title class_">MailStatus</span>.<span class="property">PENDING</span>,</span><br><span class="line"> windowStart,</span><br><span class="line"> <span class="attr">windowEnd</span>: now,</span><br><span class="line"> &#125;),</span><br><span class="line"> &#125;,</span><br><span class="line"> &#123;</span><br><span class="line"> <span class="attr">attempts</span>: <span class="number">3</span>,</span><br><span class="line"> <span class="attr">backoff</span>: &#123; <span class="attr">type</span>: <span class="string">&#x27;exponential&#x27;</span>, <span class="attr">delay</span>: <span class="number">1000</span> &#125;,</span><br><span class="line"> &#125;,</span><br><span class="line">);</span><br><span class="line"></span><br><span class="line"><span class="comment">// process 里</span></span><br><span class="line"><span class="keyword">public</span> <span class="keyword">async</span> <span class="title function_">process</span>(<span class="params"><span class="attr">job</span>: <span class="title class_">Job</span></span>) &#123;</span><br><span class="line"> <span class="keyword">const</span> &#123; windowStart, windowEnd &#125; = job.<span class="property">data</span>.<span class="property">mail</span>;</span><br><span class="line"> <span class="comment">// ① 只查询 [windowStart, windowEnd] 的事件</span></span><br><span class="line"> <span class="keyword">const</span> events = <span class="keyword">await</span> <span class="variable language_">this</span>.<span class="property">reportService</span>.<span class="title function_">findEvents</span>(windowStart, windowEnd);</span><br><span class="line"> <span class="keyword">const</span> reportHtml = <span class="keyword">await</span> <span class="variable language_">this</span>.<span class="property">reportService</span>.<span class="title function_">renderReport</span>(events);</span><br><span class="line"> <span class="keyword">await</span> <span class="variable language_">this</span>.<span class="property">commandBus</span>.<span class="title function_">execute</span>(<span class="keyword">new</span> <span class="title class_">SendMailCommand</span>(job.<span class="property">data</span>.<span class="property">mail</span>, reportHtml));</span><br><span class="line">&#125;</span><br></pre></td></tr></table></figure>
<p> ➜ 这样无是马上执行还是几次重试后才执行,数据规则都不会变。</p>
<p>二、预先生成「静态报表内容」,挂到队列里<br> 如果计算成本很高,或者怕重复查询数据开销大,也可以在调度时就把最终的 HTML&#x2F;Text&#x2F;附件 都先打好,然后作为 <code>job.data</code> 传进去,真正的 <code>process()</code> 只做一次“发送”即可:<br> <figure class="highlight ts"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br><span class="line">28</span><br><span class="line">29</span><br><span class="line">30</span><br></pre></td><td class="code"><pre><span class="line"><span class="comment">// 调度时:先生成报告</span></span><br><span class="line"><span class="keyword">const</span> now = <span class="keyword">new</span> <span class="title class_">Date</span>();</span><br><span class="line"><span class="keyword">const</span> windowStart = <span class="keyword">new</span> <span class="title class_">Date</span>(now.<span class="title function_">getTime</span>() - <span class="number">24</span>*<span class="number">3600</span>*<span class="number">1000</span>);</span><br><span class="line"><span class="keyword">const</span> events = <span class="keyword">await</span> <span class="variable language_">this</span>.<span class="property">reportService</span>.<span class="title function_">findEvents</span>(windowStart, now);</span><br><span class="line"><span class="keyword">const</span> reportHtml = <span class="keyword">await</span> <span class="variable language_">this</span>.<span class="property">reportService</span>.<span class="title function_">renderReport</span>(events);</span><br><span class="line"></span><br><span class="line"><span class="comment">// 把静态内容塞到队列</span></span><br><span class="line"><span class="keyword">await</span> <span class="variable language_">this</span>.<span class="property">mailerQueue</span>.<span class="title function_">add</span>(</span><br><span class="line"> id,</span><br><span class="line"> &#123;</span><br><span class="line"> <span class="attr">mail</span>: <span class="keyword">new</span> <span class="title class_">Mail</span>(&#123; <span class="comment">/*…*/</span>, windowStart, <span class="attr">windowEnd</span>: now &#125;),</span><br><span class="line"> reportHtml, <span class="comment">// &lt;- 预渲染好的文本/HTML</span></span><br><span class="line"> <span class="attr">attachments</span>: […], <span class="comment">// &lt;- 如果有附件也一并塞</span></span><br><span class="line"> &#125;,</span><br><span class="line"> &#123; <span class="attr">attempts</span>: <span class="number">3</span>, <span class="attr">backoff</span>: &#123; <span class="attr">type</span>: <span class="string">&#x27;fixed&#x27;</span>, <span class="attr">delay</span>: <span class="number">5_000</span> &#125; &#125;,</span><br><span class="line">);</span><br><span class="line"></span><br><span class="line"><span class="comment">// process 里只关注发送</span></span><br><span class="line"><span class="keyword">public</span> <span class="keyword">async</span> <span class="title function_">process</span>(<span class="params"><span class="attr">job</span>: <span class="title class_">Job</span></span>) &#123;</span><br><span class="line"> <span class="keyword">try</span> &#123;</span><br><span class="line"> <span class="keyword">await</span> <span class="variable language_">this</span>.<span class="property">mailService</span>.<span class="title function_">send</span>(&#123;</span><br><span class="line"> <span class="attr">to</span>: job.<span class="property">data</span>.<span class="property">mail</span>.<span class="property">to</span>,</span><br><span class="line"> <span class="attr">subject</span>: <span class="string">`系统 24h 报表`</span>,</span><br><span class="line"> <span class="attr">html</span>: job.<span class="property">data</span>.<span class="property">reportHtml</span>,</span><br><span class="line"> <span class="attr">attachments</span>: job.<span class="property">data</span>.<span class="property">attachments</span>,</span><br><span class="line"> &#125;);</span><br><span class="line"> &#125; <span class="keyword">catch</span> (e) &#123;</span><br><span class="line"> <span class="keyword">throw</span> e; <span class="comment">// 触发重试</span></span><br><span class="line"> &#125;</span><br><span class="line">&#125;</span><br></pre></td></tr></table></figure><br> ➜ 重试带来的任何延迟,都不影响邮件正文,始终是一份「事先约定好、并且静态化」的报告。</p>
-<p>这两种模式都能保证<strong>最终发送时的数据窗口</strong>或<strong>内容</strong>,与当初调度时的预期完全一致,不会因为重试延迟而出现“数据真空”或“多算&#x2F;少算”问题。</p>
+<p>这两种模式都能保证最终发送时的数据窗口或内容,与当初调度时的预期完全一致,不会因为重试延迟而出现“数据真空”或“多算&#x2F;少算”问题。</p>
<h2 id="参考文档:"><a href="#参考文档:" class="headerlink" title="参考文档:"></a>参考文档:</h2><ul>
<li>“Retrying failing jobs” · BullMQ Guide<br><a target="_blank" rel="noopener" href="https://docs.bullmq.io/guide/retrying-failing-jobs">https://docs.bullmq.io/guide/retrying-failing-jobs</a></li>
<li>BullMQ Guide &amp; Patterns · Process Step Jobs (completed event only fires after process resolves)<br><a target="_blank" rel="noopener" href="https://docs.bullmq.io/patterns/process-step-jobs">https://docs.bullmq.io/patterns/process-step-jobs</a></li>
diff --git a/2025/05/08/Multiplayer-Collaborative-Systems-tips/index.html b/2025/05/08/Multiplayer-Collaborative-Systems-tips/index.html
index 27e0b74a..1838c49a 100644
--- a/2025/05/08/Multiplayer-Collaborative-Systems-tips/index.html
+++ b/2025/05/08/Multiplayer-Collaborative-Systems-tips/index.html
@@ -194,7 +194,7 @@
<div class="post-content">
<p>最近碰到一块业务:在系统中可以存在多个用户同时对某个项目信息进行编辑,这种多人协作的场景挺有意思的,不过在我们的业务中,并不需要实时协作,只需要保证不会出错就行,话虽如此,但也可以探索一下实时协作的实现方案,防止老年痴呆。</p>
<p>先来看看第一个方案 —— CRDT(Conflict-free Replicated Data Type,无冲突可复制数据类型)是一类数据结构,它保证了在分布式节点(或多客户端)上进行离线&#x2F;并发更新后,无需中心协调、也无需人工干预,通过“合并策略”就能得到一致的最终状态。 </p>
-<p>核心思想是:所有并发操作都是<strong>幂等</strong>(idempotent)、<strong>可交换</strong>(commutative)的。</p>
+<p>核心思想是:所有并发操作都是幂等(idempotent)、可交换(commutative)的。</p>
<p>常见类型有:<br>一、G-Counter(只能增计数器)<br>二、PN-Counter(可增可减计数器)<br>三、LWW-Register(最后写入胜出)<br>四、结合 JSON 的树型 CRDT(如 <a target="_blank" rel="noopener" href="https://github.com/automerge/automerge">Automerge</a> &#x2F; <a target="_blank" rel="noopener" href="https://yjs.dev/">Yjs</a>) </p>
<p>更多原理可参考 Decipad 博客“Collaborative and Offline Editing Using CRDTs”[^1]。</p>
<blockquote>
@@ -237,7 +237,7 @@ await prisma.$transaction(async tx =&gt; &#123;
<p>前端的话,大概就是:</p>
<p>在进入编辑前请求一下 <code>/api/project/:id/lock</code> 之类的 API,失败则提示“被占用”;<br>在 <code>onbeforeunload</code> 时执行 <code>/unlock</code>;<br>超时后后端自动允许新锁。 </p>
<hr>
-<p>第二个方案是乐观并发控制(Optimistic Concurrency) :记录资源的<strong>版本号</strong>或<strong>时间戳</strong>;客户端提交更新时带上自己的版本号,后端检查版本是否一致,不一致则认为冲突,返回 409,由客户端告知用户“数据已过期,请刷新后合并”。 </p>
+<p>第二个方案是乐观并发控制(Optimistic Concurrency) :记录资源的版本号或时间戳;客户端提交更新时带上自己的版本号,后端检查版本是否一致,不一致则认为冲突,返回 409,由客户端告知用户“数据已过期,请刷新后合并”。 </p>
<p>具体实现中,可以尝试在 <code>project</code> 表加上 <code>version INT NOT NULL DEFAULT 1, updated_at TIMESTAMPTZ</code> ,然后更新项目时:</p>
<pre><code class="ts">async updateProject(parent, &#123; id, version, input &#125;, ctx) &#123;
const result = await prisma.$executeRaw`
@@ -257,7 +257,7 @@ await prisma.$transaction(async tx =&gt; &#123;
<p>前端捕获到冲突错误可以用一个弹窗提示“另有用户已更新此项目,是否合并&#x2F;重新加载?” 之类的玩意儿。</p>
<hr>
<p>第三个方案是:操作转化(Operational Transformation,OT) </p>
-<p>也就是记录用户每次的“操作”(insert&#x2F;delete at position),服务器根据历史操作序列对并发操作做<strong>转化</strong>(transform),确保先到达的操作调整后再应用后到达的。 </p>
+<p>也就是记录用户每次的“操作”(insert&#x2F;delete at position),服务器根据历史操作序列对并发操作做转化(transform),确保先到达的操作调整后再应用后到达的。 </p>
<p>有一些实现案例:<br>一、ShareDB(Node.js)<br>二、Google Docs 中的同步算法 </p>
<p>具体实现的话,可能要现在前端逐字符&#x2F;块地包装成操作并 WebSocket 推送,服务器再维护一个“操作历史队列”,每来一个 op 就 transform 并 broadcast,而客户端收到广播后,按顺序 replay 保证视图一致。</p>
<hr>
@@ -267,7 +267,7 @@ await prisma.$transaction(async tx =&gt; &#123;
<hr>
<p>总结来说,</p>
<ul>
-<li>CRDT 最擅长 <strong>去中心化</strong>、<strong>离线编辑</strong>、<strong>自动合并</strong>; </li>
+<li>CRDT 最擅长 去中心化、离线编辑、自动合并; </li>
<li>若不引入 CRDT,可根据业务侧重点选用: <ol>
<li>悲观锁 → 强制串行编辑,简单粗暴; </li>
<li>乐观并发 → 适合大多数业务场景,成本低; </li>
diff --git a/2025/05/27/vertical-slicing-practice/index.html b/2025/05/27/vertical-slicing-practice/index.html
index 325c7a76..2c73a860 100644
--- a/2025/05/27/vertical-slicing-practice/index.html
+++ b/2025/05/27/vertical-slicing-practice/index.html
@@ -192,43 +192,43 @@
</div>
</div>
<div class="post-content">
- <p><strong>垂直切片 (Vertical Slicing)</strong> 是一种在敏捷软件开发中将产品需求(通常是用户故事)拆分为可独立交付的、具有端到端功能的小块的方法。这意味着每个“切片”都包含了从用户界面 (UI) 到底层数据库,以及中间所有业务逻辑层所需的工作。</p>
+ <p>垂直切片 (Vertical Slicing) 是一种在敏捷软件开发中将产品需求(通常是用户故事)拆分为可独立交付的、具有端到端功能的小块的方法。这意味着每个“切片”都包含了从用户界面 (UI) 到底层数据库,以及中间所有业务逻辑层所需的工作。</p>
<p>与水平切片(即按技术分层,如先完成所有 UI,再完成所有后端逻辑)不同,垂直切片的目标是尽快交付一个虽小但完整可用的功能。</p>
<hr>
<p>想象一个蛋糕,垂直切片就像切下一块完整的蛋糕,包含从顶部到底部的每一层。在软件开发中,这意味着一个任务或用户故事的完成会涉及到:</p>
<ul>
-<li>**用户界面 (UI)**:用户能看到并与之交互的部分。</li>
-<li>**业务逻辑层 (Business Logic Layer)**:处理数据和执行核心功能的部分。</li>
-<li>**数据访问层 (Data Access Layer)**:与数据库或其他数据存储交互的部分。</li>
-<li>**数据库 (Database)**:存储数据的部分。</li>
+<li>用户界面 (UI):用户能看到并与之交互的部分。</li>
+<li>业务逻辑层 (Business Logic Layer):处理数据和执行核心功能的部分。</li>
+<li>数据访问层 (Data Access Layer):与数据库或其他数据存储交互的部分。</li>
+<li>数据库 (Database):存储数据的部分。</li>
</ul>
<p>所以一个垂直切片代表了一个可以独立运行、测试和向用户展示的小功能。</p>
<hr>
<p>在实践中,用垂直切片进行任务拆分或许可以按照如下步骤来实现:</p>
-<p>一、**从用户故事开始 (Start with User Stories)**:明确用户需要什么功能以及这个功能为用户带来的价值。例如:“作为一个注册用户,我希望能用我的邮箱和密码登录系统,以便访问我的个人资料。”</p>
-<p>二、<strong>识别涉及的技术层面 (Identify Affected Layers)</strong></p>
+<p>一、从用户故事开始 (Start with User Stories):明确用户需要什么功能以及这个功能为用户带来的价值。例如:“作为一个注册用户,我希望能用我的邮箱和密码登录系统,以便访问我的个人资料。”</p>
+<p>二、识别涉及的技术层面 (Identify Affected Layers)</p>
<p>对于登录功能,需要考虑:</p>
<ul>
-<li><strong>UI 层</strong>:登录表单(输入邮箱、密码的地方)、提交按钮、错误提示信息。</li>
-<li><strong>API&#x2F;服务层</strong>:接收登录请求、验证用户凭证的接口。</li>
-<li><strong>业务逻辑层</strong>:校验输入格式、查询用户信息、验证密码、生成会话(Session)或令牌(Token)。</li>
-<li><strong>数据访问层</strong>:从数据库中读取用户信息。</li>
+<li>UI 层:登录表单(输入邮箱、密码的地方)、提交按钮、错误提示信息。</li>
+<li>API&#x2F;服务层:接收登录请求、验证用户凭证的接口。</li>
+<li>业务逻辑层:校验输入格式、查询用户信息、验证密码、生成会话(Session)或令牌(Token)。</li>
+<li>数据访问层:从数据库中读取用户信息。</li>
</ul>
-<p>三、<strong>创建可交付的小功能块 (Create Small, Deliverable Chunks)</strong></p>
+<p>三、创建可交付的小功能块 (Create Small, Deliverable Chunks)</p>
<p>就是将一个大的用户故事拆分成更小的、但仍然是垂直的、可独立交付的故事。例如,可以将“用户登录”进一步细化:</p>
-<p>**切片1 (基础登录)**:用户可以使用正确的邮箱和密码成功登录。这包含了 UI 输入、后端验证和数据库查询。</p>
-<p>**切片2 (错误处理)**:用户输入错误的邮箱或密码时,系统给出明确的错误提示。这可能只涉及 UI 和业务逻辑层的少量修改。</p>
-<p>**切片3 (“记住我” 功能)**:用户可以选择“记住我”,下次访问时自动登录。这可能涉及 UI、业务逻辑和客户端存储。</p>
-<p>四、**确保每个切片都有价值 (Ensure Each Slice Has Value)**:每完成一个切片,都应该为用户或产品带来可感知的价值,并且理想情况下是可以演示给利益相关者看的。</p>
-<p>五、**保持切片足够小 (Keep Slices Small Enough)**:每个切片的工作量应该小到可以在一个迭代周期(例如 Sprint)内完成。这有助于团队保持专注,并快速获得反馈。</p>
+<p>切片1 (基础登录):用户可以使用正确的邮箱和密码成功登录。这包含了 UI 输入、后端验证和数据库查询。</p>
+<p>切片2 (错误处理):用户输入错误的邮箱或密码时,系统给出明确的错误提示。这可能只涉及 UI 和业务逻辑层的少量修改。</p>
+<p>切片3 (“记住我” 功能):用户可以选择“记住我”,下次访问时自动登录。这可能涉及 UI、业务逻辑和客户端存储。</p>
+<p>四、确保每个切片都有价值 (Ensure Each Slice Has Value):每完成一个切片,都应该为用户或产品带来可感知的价值,并且理想情况下是可以演示给利益相关者看的。</p>
+<p>五、保持切片足够小 (Keep Slices Small Enough):每个切片的工作量应该小到可以在一个迭代周期(例如 Sprint)内完成。这有助于团队保持专注,并快速获得反馈。</p>
<hr>
<p>这里有一些拆分技巧:</p>
<ul>
-<li><strong>按操作流程拆分</strong>:例如,一个复杂的表单提交可以先实现基本信息的提交,后续再添加高级选项的提交。</li>
-<li><strong>按业务规则拆分</strong>:先实现核心的业务规则,再逐步添加次要的或复杂的规则。</li>
-<li><strong>按数据类型或参数拆分</strong>:先支持一种数据类型或最常用的参数,再扩展到其他类型。</li>
-<li><strong>按用户角色或权限拆分</strong>:先实现某个核心角色的功能,再实现其他角色的特定功能。</li>
-<li><strong>简化错误处理或用户体验</strong>:先实现基本功能,再完善错误处理和用户体验细节。</li>
+<li>按操作流程拆分:例如,一个复杂的表单提交可以先实现基本信息的提交,后续再添加高级选项的提交。</li>
+<li>按业务规则拆分:先实现核心的业务规则,再逐步添加次要的或复杂的规则。</li>
+<li>按数据类型或参数拆分:先支持一种数据类型或最常用的参数,再扩展到其他类型。</li>
+<li>按用户角色或权限拆分:先实现某个核心角色的功能,再实现其他角色的特定功能。</li>
+<li>简化错误处理或用户体验:先实现基本功能,再完善错误处理和用户体验细节。</li>
</ul>
</div>