search

ecodeclub / eorm

简单 ORM 框架
Apache License 2.0
194 stars 64 forks source link

为大功能点提供issues依赖关系图/顺序图 #171

Closed longyue0521 closed 1 year ago

longyue0521 commented 1 year ago

仅限中文

使用场景

最近看到有小伙伴mark issue，我猜他（及后继者）都有这样一个需求——如何回溯找到一个功能的实现轨迹。像分库分表这样的大功能，会被拆分为多个小的功能点，每个人只能完成一部分，所以必须要去看其他人的代码，而代码只是一个”果“，而得到这个果的过程——各种设计、决策、弯路的讨论过程其实还挺重要的，也有助于理解代码的。

我知道在Issues选项卡中可以搜索但这会遇到一个问题——没有相关功能的完整/全局issue依赖图（顺序图），在不付出过多努力的情况下提供这种issue依赖图的方式：

  1. 对issue的命名进行模式化，比如"功能点名称-子功能编号：子功能需求” —— 分库分表0101：批量merger", ”分库分表0102：排序merger“，“分库分表：0201 Selector”；可以利用搜索功能，快速查找；一旦思考不全面编号要调整，需要级联改动。
  2. 总issue + 子issue，先创建一个总issue比如：分库分表需求分析/任务分解（可以讨论/展示功能点拆分的权衡、思路）再创建各个子issue比如：分库分表:merger，然后利用总issue的timeline的顺序性关联各个子issue或者markdown人工维护也行，这种方法灵活性好一点，调整顺序方便，不用预先编号但需要一些人工操作。

提供这种与某种功能相关的issue依赖图/顺序图，不但利于他人学习、参与开源，我想这也可以作为项目的特色属于另一种“文档完备”的表现形式，让他人更愿意使用。

如果这个思路可行，希望ekit/ecron也能获益。

行业分析

如果你知道有框架提供了类似功能，可以在这里描述，并且给出文档或者例子

可行方案

如果你有设计思路或者解决方案，请在这里提供。你可以提供多个方案，并且给出自己的选择

其它

任何你觉得有利于解决问题的补充说明

你使用的是 eorm 哪个版本?

你设置的的 Go 环境?

上传 go env 的结果

flycash commented 1 year ago

可以是可以，就是对于我们来说，管理成本有点高了。创建 issue 的时候其实很难预计到将来我还会创建多少的 issue。不管是命名级联，还是用一个总的 issue 里面告知大家所有的相关的 issue，管理起来都很麻烦。

总的 issue 的问题就是，你什么时候关了这个 issue 呢？比如说 merger，如果有一个 issue 来放所有相关的 issue，那么可能永远也关不了这个 issue，毕竟你会不断创建新的不管是 BUG 还是 feature 的 issue。

还有一种思路，就是我们在每一个 issue 里面引导过去前置任务，然后在合并请求里面也关联上相关的 issue，包括各种前置的，可能也有助于社区成员追溯。

不然，也可以考虑就是在一个大功能完成之后，比如说 merger 全部完成之后，我们就整理好相关的 issue，丢过去 discussion 里面？

longyue0521 commented 1 year ago

还有一种思路，就是我们在每一个 issue 里面引导过去前置任务，然后在合并请求里面也关联上相关的 issue，包括各种前置的，可能也有助于社区成员追溯。

不然，也可以考虑就是在一个大功能完成之后，比如说 merger 全部完成之后，我们就整理好相关的 issue，丢过去 discussion 里面？

两者结合一下呢？每个issue中引导前置任务，大功能结束后对相关issue做一次整理算是梳理、复盘、归档再丢进discussion中

flycash commented 1 year ago

可以=。=问题就是如果全靠我一个人来维护，我属实是有点忙不过来=。=

longyue0521 commented 1 year ago

可以=。=问题就是如果全靠我一个人来维护，我属实是有点忙不过来=。=

你负责为每个issue设置前置任务吧,整理我或者其他小伙伴来吧

flycash commented 1 year ago

我在 discussion 里面开始搞了一个。我们先试试，我觉得应该会比较琐碎，但是做出来效果还是很大的。

longyue0521 commented 1 year ago

@flycash

我研究了一下github提供的两个功能 About task lists 和 Converting an issue to a discussion 发现配合使用这两个功能+总issue模式能提高效率并减少工作量.

大致步骤如下:

  1. 需要具备owner权限
  2. 在总issue中使用 - [ ] task 10 新的待创建的子issue 创建task lists, 提交并创建出总issue后github自动追踪已存在的子issue,如果子issue已关闭需要用- [x] task 1 已关闭的子issue来确保进度显示准确.
  3. 将鼠标移动到上面“task 10“所在位置在其右侧出现小圆圈,点击“covert to issue“. 创建出来的子issue会自动与总issue关联且显示进度.
  4. 还可以通过编辑总issue的留言添加新的task,再利用covert to issue功能创建子issue
  5. 关于之前提到的何时关闭总issue的问题,我觉得可以在发版时关闭. 为总issue添加当前迭代(milestone)的版本号标记一下,然后点击总issue最右下角的“Convert to discussion"——在关闭总issue的同时归档到discussion. 总issue中的讨论也会全部保留,详见 .

我创建了一个测试项目可以点击看一下效果.

  1. 总issue正常追踪效果 https://github.com/longyue0521/task-feature-test/issues
  2. 归档总issue后效果 https://github.com/longyue0521/task-feature-test/issues?q=is%3Aissue+is%3Aclosed 当你进入总issue时会提示归档到哪个discussion很方便
flycash commented 1 year ago

我草很牛逼啊！

flycash commented 1 year ago

我给你提升了权限你试试这个权限够不够了

longyue0521 commented 1 year ago

我添加了一个实验性的Merger相关总issue 效果如下:

image

优化后的工作流,以分库分表: Merger总issue为例:

  1. 创建分库分表: Merger总issue v0.0.3,带上milestone [issue内部能指定不用带了]
  2. 在总issue中通过编辑issue细化、分配子任务,在评论里讨论设计、思路等
  3. 方法一
    • 发布v0.0.3时,将总issue关闭并转化为discussion归档
    • 在导论区 #178 以评论的形式添加刚才转化的discussion链接即可
  4. 方案二
    • 发布v0.0.3时, 直接关闭总issue
    • 在导论区 #178 以评论的形式添加总issue链接

为此付出的努力与之前大致相当就是多了一个需要将总issue链接添加到归档discussion的步骤.这个步骤也可以通过添加标签优化掉——添加两个标签即用"主题标签,比如:分库分表:merger" + "总issue“这两个标签过滤找到相关主题的总issue, 每个总issue带着版本号且有时间序,这样就不用维护discussion中那个各个版本的总issue了.

还有就是你需要适应一下这种通过总issue分配子任务的方式

longyue0521 commented 1 year ago

@flycash

我按照自己的理解创建了四个总issue并将其中三个总issue“钉住”,还添加了一个新标签epic用来表示总issue.(来自敏捷社区,一个epic包含多个feature;一个feature包含多个user story).

你可以按需调整,直接编辑总issue添加feature就行了