Bison 重构计划备忘

[AzideCupric]

起因

bison 经过多年的发展，项目起步以及后续开发过程中的一些设计和实现逐渐产生了一些异味，为了后续的维护与开发过程中能够实现对项目的更好维护，因此决定对 bison 现有结构和内容进行一些整理和规范，以求更好的提升后续开发体验
这位开发者你也不想在屎上雕花吧

规划

• 规范项目中的变量名
  目前项目中存在着许多相似乃至相同的变量名指代着不同含义、不同功能变量的情况，这容易造成不必要的混淆, 例如target一词
• 规范项目文件的命名
  项目中部分文件或目录的命名易导致疑惑，例如config与plugin_config指代数据库操作与项目配置两种截然不同的事物
• 重新整理项目的单元测试
  项目现有的单元测试安排在逐渐增添的功能中变的越发杂乱无章，重新整理单元测试显得非常必要
• 考虑更精细的可配置项的实现
  在项目越发复杂的现在，现有的plugin_config结构难以满足使用上的多样需求，按platform, post甚至target(发送对象)进行配置的需求日益必要
• 考虑能否缩短一些过分长的类
  例如DBConfig类
• 考虑整理 bison 现有的项目结构
  项目现有文件结构的安排时候合理，有待继续探讨
• 后台整体重构

以考虑一词开头的项是否进行有进一步讨论的必要

[AzideCupric]

或许我们还需要一个术语表，来明确其特定的指代(

术语	解释	补充
RawPost	从平台获取的原始数据	Bison 对新推送的处理和去重都在此基础上进行
Post	推送数据抽象	包含推送来源，内容（可选的网址，图片）
Theme	推送主题	将 Post 渲染成特定样式
Shipper	发件人，需要推送其消息的目标，类似于B站的up	原名为 Target
ShipAddr	发件人所在的平台，类似于up所在的B站	原名为 Platform
ShipStub	发货存根，登记在数据库里的Shipper信息，包括发货地	原名为 db_target
Receiver	收件人，需要发送给的目标，比如某个QQ群	原名为 Target(在发送部分)
ReceiveAddr	收件人所在的平台，类似于QQ群所在的QQ	原名为 Platform(在发送部分)
Subscribe	寄件人、收件人、货物要求（cats，tag）的记录	或许可以叫 承运凭据?
WayBill	运单，Shipper、Subscribe的组合	原名为 SubUnit

Note

术语表的术语名还在讨论阶段，目前只是一个暂定的值，如果有更好的方案欢迎提出

[AzideCupric]

add #487

[AzideCupric]

add #478

[AzideCupric]

add #688