各位 Soft Job 的版友大家好，我是 Pichu，半年前在这个版征求关于 BBS 后端开发的
人力（#1W1OxYB8 (Soft_Job)），很感谢大家的支持
这篇文章主要是和大家分享这半年来我们大致上做了哪些事情，
影片整理则会于 7/31 释出。
一月中的文章我们列了十三点需要处理的问题：
```
1. 接口/商业逻辑/数据库的程式码混在一起，造成调整使用者体验上以及使用者接口
上调整困难。
2. 程式码缺乏注解，可读性极低。
3. 原先的程式码完全没有 testing code.
4. 程式码完全没有 benchmark 机制，修改架构仰赖设计者的威望而非科学证据。
5. 大部分的架构仍然使用 32 位元的时间表示方式，这会导致 2038 问题。
6. 密码仍采用基于 DES 的杂凑方式，换句话说，强度不足。
7. 过度仰赖共享内存的设计造成服务器分散困难。
8. 索引档储存方式弹性不足，不易新增新字段。
9. 转信机制死亡已久。
10. 站内讯息 （水球）、站内信无法透过手机即时通知使用者。
11. Current PTT 程式码尚不支援 IPv6.
12. 站内文章仍然使用 Big-5 储存，不支援 emoji 或是台罗拼音。
13. 不支援图片上传、音讯或是视讯通讯。
```
而目前大致上处理了这些问题
```
V 1. 接口/商业逻辑/数据库的程式码混在一起，造成调整使用者体验上以及使用者接口
上调整困难。
V 2. 程式码缺乏注解，可读性极低。
V 3. 原先的程式码完全没有 testing code.
4. 程式码完全没有 benchmark 机制，修改架构仰赖设计者的威望而非科学证据。
5. 大部分的架构仍然使用 32 位元的时间表示方式，这会导致 2038 问题。
6. 密码仍采用基于 DES 的杂凑方式，换句话说，强度不足。
7. 过度仰赖共享内存的设计造成服务器分散困难。
8. 索引档储存方式弹性不足，不易新增新字段。
9. 转信机制死亡已久。
10. 站内讯息 （水球）、站内信无法透过手机即时通知使用者。
11. Current PTT 程式码尚不支援 IPv6.
12. 站内文章仍然使用 Big-5 储存，不支援 emoji 或是台罗拼音。
13. 不支援图片上传、音讯或是视讯通讯。
```
这篇文章会以两个大的部分来介绍分别为 协作方式 以及 技术架构
协作方式会以技术上较浅显的方式介绍，技术架构部分则适合想要加快上手时程的工程师
>>>>> 协作方式 <<<<<
※ 引用 #1W1OxYB8 [征才] BBS 后端实作 (全远端)(无薪)：
: 但是我个人有个额外的请求，因为有先前在 Soft_Job 上提到的“东京都新冠肺炎对策
: 网站(https://stopcovid19.metro.tokyo.lg.jp/)”的经验，我还是希望能做到是由社群
: 的多数人共同完成这个专案，而不是如同多数在台湾的开源专案，是由固定几个“大神”
: 来完成的。
: 原则上软件专案人数的增加并不会增加开发效率，反而还会降低效率，但是开发人数过
: 少的专案反而会有公共汽车指数(bus factor)过低的问题，也就是少数几个人离开专案就会导
: 致专案进度停摆或是没有人能继续维护。
: 因此我会希望邀请有兴趣共同开发的工程师加入，大约一周两到四个小时的时间就可以
: 了，而我自己扮演的角色会倾向专案管理的角色，准确有效率的分配任务给贡献者们，同
: 时能确保工作进度和程式码品质。这对我个人而言也算是具挑战性的任务。
上面是这个专案另外重视协作方式的一个初衷，先前在台湾的开源专案中其实不少专案到
后来经常会变成只有一个人的专案，一个人的专案有可能变成什么情形？
: When I wrote this code, only God & I understood what is did.
: Now... only God knows.
可能一开始写的很顺，然后到后来变成自己懂而已，程式码放个半年一年之后换连自己都
不懂了。
那在原本 pttbbs 的 C 程式码中其实他本身是运作良好的程式码，只是到后来变成新进
的大学生其实不是很能完全看得懂上面的东西，也就造成了后人真的有办法大规模去修改
他的人也变少了，因此在确立协作方式上面会是我希望达成的一个目标。
不管是在当时一月出的时候还是现在，我都觉得东京都的 covid19 专案还满厉害的，因
为他可以持续地保持多人协作，这点在台湾的开源专案来说是十分少见的，也因此这个
也是我目前持续投入这个专案的主因，因为我想找出来有没有办法找出一种让专案可以
长期由工程师以及社群，透过个人可负担的成本令这个系统可持续发展的机制。
也就是说，今天说叫一个工程师每天上班几个小时后还要花几个小时在这个专案上，长久
下来是没办法持续的，他还有其他工作，可能随时间过去也会对其他的 side project 有
兴趣。或者是说也不是所有人都和我一样工作时间比较自由，不用上下班打卡，但是长久
下来其实还是有受到影响，像是我没办法花比较多的时间在有付钱的客户上嘛。
可是如果说今天每个工程师都是每周花几个小时，大概两到四个小时这样，这样可以换到
什么？换到一个可以和时代一起进步的 BBS 系统，然后不会说受到政府言论审查或是说
因为商业上的关系比需要做一些折衷的平台，那其实这样换起来很划算不是吗？
不过开源这件事情还真不是把程式码公开在网络上后标示开源版权，接下来就会收到一堆
贡献者提交程式码的，在 Ptt-backend 这个专案之前我至少失败了大概也有四五次，这次
看起来有稍微成功一点，因此在这边和大家分享目前这个专案的协作方式：
首先是这个专案的数据部分，在发文的第一天我收到了极大量的站内信，后来做了基本的
问卷调查。
在第一天有回应的大约有 38 人，前十天从 1/20 ~ 1/30 报名的人数约 97 人，
截至 7/20 总共报名的人数是 119 人。
而参与者的时区除了在台湾以外，还有在日本、美西以及德国的，因此我们的做法是每周
会释出一次影片，然后在影片后面附上问卷让大家问看看本周有什么问题，下周再作分享
目前每周影片到写文时持续了 26 周没间断，下图是各周回复的问卷数据
https://imgur.com/a/tltilZE
┌──┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
│周次│ 1│ 2│ 3│ 4│ 5│ 6│ 7│ 8│ 9│10│11│12│13│14│15│
├──┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤
｜人数│34│48│26│22│23│20│20│18│14│13│11│16│19│11│13│
├──┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤
│周次│16│17│18│19│20│21│22│23│24│25│ │ │ │ │ │
├──┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤
｜人数│ 8│ 8│11│ 9│ 6│ 8│ 6│ 4│ 5│ 2│ │ │ │ │ │
└──┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
图片上另外加了一条对数回归线作为参考，颜色较深的是问卷回收数量较浅的为回归线，
第十三周的部分人数有稍微变多，推测原因是 4/14 的时候因为前两周回收数量即将低于
十人，因此在 4/14 的时候刷了一下存在感，所以有些参与者有另外和我要当周和前一周
的影片，因此在该两周人数有小幅上升。
https://imgur.com/fFKTPjh
图中这个是 Ptt-backend 也就是我本次负责的专案的提交 (Commit) 次数，上面那条线是
40 次，第二条是 20 次，每个柱状单位是每周，因为在每次程式码的修改后都会留下一次
提交纪录，因此他可以代表这个程式码仓库实质上变动的活动量，可作为专案健康度的参
考指标。
https://imgur.com/bWvVJUL
那我们如果将这两图叠合的话就会发现到有微妙的关联性
有关联性的部分是在一开始人多的时候确实提交次数有比较多，但是开始没多久后明明人
数还很多，但是提交次数却下降了，目前的推测是这样：在刚开始专案刚被介绍出去时，
会有许多人提出主观的修改意见，其中包含许多有建设性的修改，因此在专案初期因为一
人专亿造成的问题会得到缓解，举例来说，这个专案一开始的 user id 这的变量名称是用
userId 这样的格式写的，这是我个人平常习惯的拼法，但是有人提出修改建议说应该要用
userID 这样的格式。当然他提出这个意见背后还有提出 Golang 官方的文件作支持，所以
就接受这样的修改了。
另外还有像是调整程式码架构便于未来可维护性等等的。
那像这样的修改本身对于功能推进的实质帮助并不直接，不过确实可以呼应到我们专案一
开始的其中一个目标：“增加可读性、减少技术债”。
不过当这些东西被处理到一个段落后大家就会陷入一种“不知道要做什么”的困境，到了
二月多的时候实际上我们还在探索应该如何进行，然后新增程式码检查工具 (lint) ，然
后又产生大量修改，之后合并回去之后又不知道要做什么了。
https://imgur.com/Clkc6qR
因此在第七周的时候我们最了一份问卷调查，询问是不是需要有人帮忙指派任务这样，大
概有四分之一的参与者回答需要，加上可以的话超过一半，所以后来我们做了一份表来纪
录每个参与者目前状态，例如在忙哪个项目，每周照顺序分配这样。
按照这个方法其实在四月初到五月的时候取得了还不错的效率，因此就把一些简单的功能
完成了。比较困难的部分例如进行整个系统的整合测试以及确认写入文章的做法是从5/18
这周开始，此时在图形上就很明显看到一个洞，那也凸现分配法的大缺点：
如果没人分配工作的话那工作进度会大幅度慢下来。
接着到六月多，六月多开始第一次整合测试完成了，因此测试出一大堆 Bug，
因为分配表名单和影片问卷回复没有连动的关系，所以后面又寄送了一些邀请给分配表的
参与者，所以看到整个提交次数又开始上升了这样。
因此综上所述，我们可以抓到几个目前观察到的小结论：
1. 专案一开始的参与者会时间自然流失，流失曲线大致上会呈现对数下降。
2. 实际上的提交数量和参加者目前的数量似乎只有在刚开始有明显关系。
3. 明确地把任务分配出去确实可以增加专案执行的效率。
接下来在进入技术架构之前我想要先把这专案开始半年以来的贡献者们放上来，
除了做个纪录以外也感谢大家这段时间的配合这样。
https://imgur.com/9DX6qb8
>>>>> 技术架构 <<<<<
接下来的部分会进入这半年来技术架构的简单整理
从这边后面的东西会比较困难，可能会需要有点工程师背景才会比较容易看得懂
这个专案分成两个部分，第一个是做为数据库管理系统 DBMS 的 go-bbs 函式库，
以及作为应用系统的 Ptt-backend 两个部分。
首先先介绍 go-bbs 的部分
Filesystem Controller Backend
Storage (Worker) Web
┌─────┐ ┌─────────┐ ┌─────────┐
│ BBS │ │Ptt-official-app/ │ │Ptt-official-app/ │
│ Content │←────│go-bbs │←──│Ptt-backend │
└─────┘ └─────────┘ └─────────┘
那在 BBS Content 里面纯放的是实际上例如大家的帐号密码以及文章纪录等
你可以把它想像成像是 MySQL 数据库也有个 /var/lib/mysql 的资料夹存放原始资料
因此在业界谣传 BBS 没有用数据库的这个说法基本上是错的，
正确的说法是目前使用 MySQL 或是 Oracle 这类基于 SQL 的数据库系统的 telnet-based
BBS 十分稀少。
那除了 SQL-based 的 RDBMS 以外
https://imgur.com/8s19K2d
┌─────┬──────
│ 名称 │ 资料模型 ...
├─────┼──────
... ...
├─────┼──────
│MariaDB │ RDBMS
├─────┼──────
│MongoDB │ NoSQL
├─────┼──────
│MySQL │ RDBMS
├─────┼──────
│PostgreSQL│ ORDBMS
├─────┼──────
│SQLite │ RDBMS
├─────┼──────
... ...
Src: https://reurl.cc/Nro2p9
这个世界基本上还存在着各式各样不一样的 DBMS ，就已上表为例，像是 MongoDB 我们
不会说他是 SQL 但是他确实也是一种数据库，那他就是非关联式数据库架构的 DBMS。
因此在目前大多数的 telnet-based BBS 系统当中，其实数据库是以索引档和文章档的方
式井然有序地放这著的，只是目前并没有特别去开发一个程式接口来存取这些文字档而已
因此我们需要一个抽象的程式接口让大家能够存取 BBS 系统中的这些档案，这个就是
go-bbs 这个专案的目的。
顺带一提，也不是所有的 BBS 都排斥不使用关联式数据库，有些 BBS 系统还是有用到
SQLite 的喔。 eg: https://reurl.cc/3aQk4O
那在 go-bbs 里面定义的基本上是操作 BBS 数据库所支援的 Golang 接口，举例来说像是
读取文章、新增文章纪录、读取使用者资料等等的，并不包含实际上的权限管控。
另外在 go-bbs 的设计也不是只支援 pttbbs 这一套 telnet bbs 系统而已，在一开始的
设计预想中是希望他可以去支援其他种类例如 maple 3 的 bbs 系统。
这样的设计和 Golang 的 database/sql 套件设计类似
https://imgur.com/Wlv6uMX
src: https://pkg.go.dev/database/sql
一个套件来定义接口含基本的操作，然后再由其他套件来实作符合这个接口的 driver ，
因此只要其他种类的 telnet bbs 实作了 go-bbs 的接口之后，基于 go-bbs 设计的应用
程式就能够套在他上面了。