-
Notifications
You must be signed in to change notification settings - Fork 16
Roadmap
这里是 Ficus 软件发展路线图（Roadmap），我们在这里会介绍 Ficus 这款软件在未来一段时间内的主要发展方向。
路线图由多个“阶段”组成，每个“阶段”表示软件开发的一个时间段，用一级标题表示；每个“时期”中会有多个不同的开发“方向”，用于分类在此阶段的多个开发“任务”，“方向”用二级标题表示；每个“方向”有多个具体的开发“任务”，“任务”依靠列表展现，存在多种状态，如下所示：
| 符号 | 含义 |
|---|---|
| 🌑 | 任务尚未开始 |
| 🌓 | 任务正在进行 |
| 🌕 | 任务完成 |
| 🌔 | 任务搁置 |
| 🌘 | 任务意外终止 |
对于需要讨论的部分，我们会附上 github discussion 链接，方便开发人员和用户进行讨论。
这个时期是在 2023.03 ~ 2023.08 。在这个时期 gg=G 团队从零搭建了 Ficus 这款软件。确定了这款编辑器以“Ficus Core Structure”为中心结构，具有“结构化编辑展示，多平台适配，本地化”的特点。截止版本是 v0.2.1。
但是因为开发时间过于紧张，这个时期的产品具有“边缘情况考虑不足，性能较差，交互打磨不充分，运维形式大于实质，没有完全体现 Ficus 设计”等缺点，希望在之后的阶段加以改进。
因为这个时期在撰写这篇 Roadmap 之前，所以暂时不罗列这个时期的任务了。
这个时期是在 2024.01 ~ 2025.01 。这个时期我们对于 Ficus 软件新特性的开发步伐会放缓，开发的重点是对于原有成果的完善。这是因为在刀耕火种时期，由于敏捷开发的原因，导致有许多开发中的“隐疾”存在，我们要在这个时期将这些开发中不太 Solid 的地方更换成更加得体的实现，就像忒修斯之船一样，在航行的过程中将原本陈旧的船体完全更换成新的船体。
原本我们嵌入的 markdown 编辑器是 vditor，但是嵌入手段较为生硬，bug 频发；而且因为不了解 vditor 源码，所以我们将其修改得更符合 ficus 特点也较为困难；再加上 vditor 本身的一些安全漏洞和性能问题。考虑再三，我们决定自己开发一款编辑器来代替 vditor。这是忒修斯之船时期最为重要和困难的事情。
- 🌓 阅读其他开源编辑器代码，设计实现方案
- 🌑 实现新的编辑器
- 🌑 将新编辑器接入 Ficus
之前的运维为了符合课程设计的要求，所以做了许多的“表面文章”，在新的时期要让运维真正发挥作用（规范开发行为，吸引用户讨论，确保软件质量），去掉之前那些华而不实的设置。
- 🌑 删减官网，将一些开发守则搬到 github wiki 中，同时去掉一些强行吹牛的竞品分析
- 🌑 采用新的打包和构建工具，原有工具过于陈旧且不再维护了
- 🌑 提出新的 Code Review 规范，之前的规范过于局限于代码风格，对于语义部分的实现并没有详细检查
- 🌑 新的 README，新的 README 应该是更加具有功能性，之前 README 的展示性过强了
- 🌑 提出新的贡献规范，包括 wiki，issue，discussion，pr 等
- 🌑 整理仓库结构，可以将多个仓库都放在同一个 group 下
TODO: 将筛选出的 feature 罗列到此处。
这个部分主要涉及对于原有编程中出现的风格问题或者 bug 进行修改和修复，但是对于大型 feature 的开发，并不在此考虑之列。
- 🌑 去掉硬编码等低质量代码
- 🌑 issue 中提到的 bug 复现和修复
- 🌑 筛选 issue 中提到的小型 feature
这里罗列一些 Ficus 的可能的 feature，有可能实现，有可能短期内搁置，可以在 discussion 中讨论：
- 🌑 将 Ficus 改成 qt 框架，这是因为 Electron 的性能堪忧，内存占有率高，而且在设计上有些“脏”（一个浏览器内核被嵌入到程序里了），有人建议可以换一个简单的浏览器内核。
- 🌑 换掉 mindmap 插件，目前的修改也非常的隔靴搔痒，和 vditor 类似
- 🌑 目前的 UI 风格偏向 mac 圆角风格，我想弄得更加朴实一些和有特点一些
- 🌑 开放更多的配置选项：字体，导出 html 的 css 配置，快捷键配置
- 🌑 在下个阶段可以考虑向用户暴露一些稳定的 API，方便用户写脚本和配置，但是这个设计难度很大，还需要仔细讨论
- 🌑 在 docker 中完成开发和部署