各位 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 設計的應用
程式就能夠套在他上面了。