跳转到主要内容

需求驱动

TL;DR

— 无法明确表述新功能要解决的目标？或者问题在于任务本身没有被明确表述？重点是方法论有助于揭示任务和目标定义中的问题

— 项目不是静态的 - 需求和功能在不断变化。随着时间推移，代码变成一团糟，因为在开始时项目只是为了初始的需求印象而设计的。好架构的任务也是要为不断变化的开发条件做好准备。

为什么？​

要为实体选择一个清晰的名称并理解其组件，你需要清楚地理解所有这些代码要解决什么任务。

@sergeysova: 在开发过程中，我们试图给每个实体或函数一个清楚反映代码执行意图和含义的名称。

毕竟，如果不理解任务，就不可能编写覆盖最重要情况的正确测试，在正确的地方放置帮助用户的错误提示，甚至不能避免因为可修复的非关键错误而中断用户流程。

我们在谈论什么任务？​

前端开发为最终用户开发应用程序和界面，所以我们解决这些消费者的任务。

当一个人来到我们这里时，他想要解决自己的某个痛点或满足某个需求。

管理者和分析师的任务是明确表述这个需求，开发者在考虑Web开发特性（通信丢失、后端错误、拼写错误、鼠标或手指操作失误）的情况下实现它。

用户带着的这个目标，就是开发者的任务。

一个小的已解决问题就是Feature-Sliced Design方法论中的一个功能（feature）— 你需要将项目任务的整个范围切分为小目标。

这如何影响开发？​

任务分解​

当开发者开始实现任务时，为了简化代码的理解和支持，他在心理上将其切分为阶段：

  • 首先_分解为顶级实体_并_实现它们_，
  • 然后将这些实体_分解为更小的实体_
  • 以此类推

在分解为实体的过程中，开发者被迫给它们起一个能清楚反映他的想法的名称，并在阅读代码清单时帮助理解代码解决什么任务 同时，我们不要忘记我们正在努力帮助用户减少痛点或实现需求

理解任务的本质​

但要给实体起一个清晰的名称，开发者必须充分了解其目的

  • 他将如何使用这个实体，
  • 它实现用户任务的哪一部分，这个实体还能在哪里应用，
  • 它还能参与哪些其他任务，
  • 等等

不难得出结论：当开发者在方法论框架内思考实体名称时，他甚至能在编写代码之前就发现表述不清的任务。

如果你不能很好地理解一个实体能解决什么任务，如何给它起名？如果你不能很好地理解一个任务，又如何将任务分解为实体？

如何表述？​

要表述功能（features）解决的任务，你需要理解任务本身，这已经是项目经理和分析师的责任。

方法论只能告诉开发者产品经理应该密切关注哪些任务。

@sergeysova: 整个前端主要是信息显示，任何组件首先是显示，然后"向用户显示某些东西"的任务没有实际价值。

即使不考虑前端的特性，也可以问"为什么我必须向你显示"，这样你可以继续问下去，直到找到消费者的痛点或需求。

一旦我们能够找到基本需求或痛点，我们就可以回过头来弄清楚你的产品或服务如何帮助用户实现他的目标

你跟踪器中的任何新任务都旨在解决业务问题，而业务试图在解决用户任务的同时从中赚钱。这意味着每个任务都有特定的目标，即使它们没有在描述文本中明确说明。

开发者必须清楚地理解这个或那个任务追求什么目标，但不是每个公司都能完美地构建流程，虽然这是另一个话题，但开发者完全可以自己"ping"合适的管理者来了解这一点，并有效地完成自己的工作部分。

有什么好处？​

现在让我们从头到尾看整个过程。

1. 理解用户任务​

当开发者理解用户的痛点以及业务如何解决它们时，他可以提供由于Web开发特性而对业务不可见的解决方案。

但当然，所有这些只有在开发者对自己在做什么以及为什么做不漠不关心的情况下才能起作用，否则_为什么还需要方法论和某些方法？_

2. 结构化和排序​

随着对任务的理解，在头脑中和任务以及代码中都有了清晰的结构

3. 理解功能及其组件​

一个功能就是为用户提供的一个有用功能

  • 当在一个功能中实现多个功能时，这是边界违反
  • 功能可以是不可分割的和不断增长的 - 这并不坏
  • 坏的 - 是当功能不能回答_"对用户的业务价值是什么？"_这个问题时
  • 不能有"地图-办公室"功能
    • 但在地图上预订会议、搜索员工、更换工作场所 - 可以

@sergeysova: 重点是功能只包含实现功能本身的代码，没有不必要的细节和内部解决方案（理想情况下）*

打开功能代码只看到与任务相关的内容 - 不多不少

4. 收益​

业务很少会彻底改变其方向，这意味着在前端应用程序代码中反映业务任务是一个非常重要的收益。

然后你不必向每个新团队成员解释这段或那段代码做什么，以及为什么添加它 - 一切都将通过已经反映在代码中的业务任务来解释。

这就是领域驱动开发中所谓的"业务语言"

回到现实​

如果在设计阶段理解了业务流程并给出了好的名称 - 那么将这种理解和逻辑转移到代码中就不是特别有问题的。

然而，在实践中，任务和功能通常是"过度"迭代开发的，和/或没有时间思考设计。

结果，功能在今天是有意义的，如果你在一个月后扩展这个功能，你可能需要重写项目的一半。

[来自讨论]：开发者试图提前思考2-3步，考虑未来的需求，但在这里他依赖于自己的经验

有经验的工程师通常立即看到10步之前，并理解在哪里分割一个功能并与另一个功能结合

但有时会遇到必须面对经验的任务，而无处获得如何正确分解的理解，以便在未来产生最少的不幸后果

方法论的作用​

方法论帮助解决开发者的问题，以便更容易解决用户的问题。

没有仅仅为了开发者而解决开发者问题的方案

但为了让开发者解决他的任务，需要理解用户的任务 - 反之则不行

方法论要求​

很明显，需要为Feature-Sliced Design确定至少两个要求：

  1. 方法论应该说明如何创建功能、流程和实体

    • 这意味着它应该清楚地解释_如何在它们之间分配代码_，这意味着这些实体的命名也应该在规范中确定。

  2. 方法论应该帮助架构**轻松适应项目不断变化的需求**

另请参阅​