各位 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 设计的应用 程式就能够套在他上面了。 ---------------------- 接下来是 Ptt-backend 的部分 Filesystem Controller Backend Storage (Worker) Web ┌─────┐ ┌─────────┐ ┌─────────┐ │ BBS │ │Ptt-official-app/ │ │Ptt-official-app/ │ │ Content │←────│go-bbs │←──│Ptt-backend │ └─────┘ └─────────┘ └─────────┘ 这是这个专案比较属於应用层的部分，他负责商业逻辑判断、转成下一个客户端听得懂的 介面格式以及和 go-bbs 或是其他新的资料库拿资料的任务。 那基本上 Ptt-backend 也会是新进来的参与者推荐先入门的地方。 如果要读 Ptt-backend 程式码的话，会推荐从 internal 这边作为起点 Internal ───┬─── Delivery │ ├── Usecase │ └─── Repository internal 是在 go 1.4 开始的一个 feature ，在 internal 里面的套件只能被他上层的 套件或是同个 internal 的套件给 import 进来，因此我们不用担心修改了 internal 内 的程式码会导致其他人 import Ptt-backend 这个专案时发生不相容或是 breaking change 的状况。 上面有提到 Ptt-backend 最重要的三个任务 存取 go-bbs 资料库 商业逻辑 把资料转给 Client 端 因此在进行功能开发或是修改的时候，可以先想一下这个功能牵涉的是 Ptt-backend 的 哪个任务，然後再点进去那里面。 会这样切的细节原因请参考 Ptt-backend 的 ISSUE#16 ，里面原始的设计者有提到完整的 想法。 https://github.com/Ptt-official-app/Ptt-backend/issues/16 整体而言我们不会排除说未来的开发者有可能找到新的 repository 的储存方式来取代掉 原有的 go-bbs ，举例来说，可能把它改成分散式的系统。 Delivery 的部分则是实作目前的 RESTful API，不过我们也希望他可以回头支援原本用上 下左右 VT100 的 BBS 介面，否则我们就没有真正可以取代掉原有 C 程式码的一天。 再来是目前其实也有效率比传统 RESTful API 还要好的介面被发明了，像是 gRPC ，或者 是不断有人希望使用特定的 HTTP Framework，这部分可以透过新增新的 Delivery 套件来 实现。 Usecase 切开的话则是我们就可以比较简单的针对商业逻辑去写 Unit Test 而不会被 HTTP 套件困住。 -------- Internal ───┬─── Delivery │ ├── Usecase │ └─── Repository Delivery * 实作文件上的HTTP 介面 * E-tag, Authorization Header, if-not-modified * 依照 HTTP 本身的特性去做流速限制 * 建议从 route.go 的第八行 build Route 开始看 * 文件档案部分可以参阅 RESTful API 文件 (Google Docs) https://reurl.cc/R0o849 Delivery 目前是先实做 HTTP 的介面，因为 HTTP 的 RESTFul API 目前可以说是业界共 通语言了。 在 HTTP 的设计理念当中最重要的部分是快取机制，也就是 Body 在原文没有更新的前提 下不需要重送，那目前在 Telnet BBS 系统中，即使是用 WebSocket 来浏览 PTT 文章， 使用者还是要左左右右进进出出才知道有没有人在下面有新的回应或是在看板上发文，那 在这边左左右右进进出出其实有很多资料是重覆传送的，透过一些快取机制的话， HTTP 请求在同个资源第二次发出时会多几个 Heade，和伺服器说「如果这个资源什麽时候以来 都没有改变过，那就不用再送了，我这边已经有了」 如果要读这份套件的话，建议从 route.go 的第八行开始看，另外可以同时参考上面的放 在 Google Docs 的RESTful API 文件 -------- Internal ───┬─── Delivery │ ├── Usecase │ └─── Repository Usecase * 实作权限检查 * 检查 repository 来的东西是否需要型别转换 * 串接不同的功能 Usecase 里面主要做权限检查以及实作商业逻辑，例如说把文章转寄回自己信箱、或者是 判断某个文章发文 P 币应该要如何计算等等的。 在这个地方的档案会以功能来进行分类，像是 article, board, mail, user 这样。 -------- Internal ───┬─── Delivery │ ├── Usecase │ └─── Repository Repository * 检查 repository 来的东西是否需要型别转换 * bit 操作 * 资料库层的快取 Repository 的部分主要是串接 go-bbs 然後把原本的东西转回成 Ptt-backend 内部的资 料结构，例如在这边做 bit 操作等等的。 另外由於 go-bbs 和 Ptt-backend 开发上的时间差，因此目前在 repository 中有不少 函式还是处於回传假资料的状况，需要有人帮忙串接实际上 go-bbs 已经开好的介面。 ================================== 接下来是另外一个刚进入这个专案的常见问题： 为什麽 Ptt-official-app 下面会有这麽多 repo https://imgur.com/uOH8mAx 间单来说就是发生了「一个中台各自表述」，一中各表的兢争状况... 首先这个问题本身是有历史因素的，最早来说 PTT APP 的专案并没有打算采用 Golang ，而是透过 ASP.Net 架设一个「中台」来暂存资料，接着手机 APP 发文的资料不一定会 写回原有的 PTT 的站上，而是滞留於中台。主要原因在於当时没有人可以帮忙读懂 pttbbs 的 C 程式码，再来是原本的系统站长比较忙，不一定会有时间帮忙处理 PTT APP 的计画。 因此最初打算在不更动後端的前提下透过中台的机制去实作这个 PTT APP 计画。 後来 CodingMan 加入，他是知名的 Ptt Python 函式库 PyPTT 的作者，因此中台的实作 就从原本的 ASP.Net 变多一个由 chhsiao1981 (老萧) 用 Python 实作的中台，差不多我 是在这个时候我这边加入。 因为先前管理 Formosa BBS 的关系，很早以前就认为 BBS 程式码需要大的重构，因此就 提出用 Golang 来实作读取 BBS 硬碟上档案的计画。 只是在这边的计画并不一定最终会被 PTT 系统站长那边认可采用，因为直接读取硬碟上 的档案需要将程式跑在原有 PTT 的主机上面，因此一旦这套程式有漏洞的话，造成资安 上危害的风险相对来说也会比较大。 但是就如同最初提到的问题，包括 32-bit 的时间格式以及基於 DES 密码系统导致强度 不足等问题，如果希望PTT能够持续活下去的话，go-bbs 这个专案还是有发展的必要。 再加上初步测试从登入到读取文章，证实基於 Golang + HTTP 的架构效能确实比 C + VT100 快一点点之後，好像就更有投资的价值了？ 後来老萧也来帮忙送 PR 到 go-bbs 的 repo 来，不过基於他送的部分可以说是只是单 纯的把 C 程式码用 golang 改写过，在可读性上没有改进多少以及大量不确定有没有被用 到的变数还是被送入 PR 的前提下，在 code review 的时候变得十分尴尬，具体可以参见 go-bbs ISSUE#8 https://github.com/Ptt-official-app/go-bbs/pull/8 而在老萧质疑说为什麽不把 go-bbs 的 Repo 移动到後来才开立的 Ptt-official-app orgname 底下，最後他就直接从 go-bbs fork 出一份 go-pttbbs 了。 那原先老萧要用 python 开发的中台变成了老萧用 go 开发的中台，叫做 go-openbbsmiddleware 这个 repo ，串接老萧自己的 go-pttbbs Pichu Chen: | go-bbs | <-- Golang function call -- | Ptt-backend | Protocol 文件在 Google Docs 上 开发机： pttapp.cc chhsiao1981: | go-pttbbs | <-- go-pttbbs protocol -- | go-openbbsmiddleware | 文件在 https://api.devptt.site:8080/ 文件在 https://api.devptt.site:5000/ 开发机： www.devptt.site 所以大概是这样，原先希望的架构是老萧那边用 Python 写的中台可以直接透过 CodingMan 的 PyPtt 串接 PTT 主机的资料，後来变成了两个「中台後端」的竞争状况。 那两套後端系统也各自有自己的开发测试环境，目前这个文章介绍的的主要是上面 Pichu Chen 的版本，他的开发机是在 pttapp.cc 上面，下面老萧的版本是在 devptt.site 上 面。 =========================================== 那就目前的开发进度以及开发速度而言，要决定出采用何者的版本应该还需要半年到一年 以上的时间，毕竟现有的 C 程式的版本大致上还可以活至少十年 (到2038)，如果希望提 早测试新的版本的话，可以到 pttapp.cc 上面注册资料发文测试，1注册时请注意严禁使 用真实个人资料，包括密码也请不要和现有密码相同，因为上面的资料会作为开发使用让 大家自由下载，同时也有可能有漏洞导致资料外泄这样。 目前我们能做的基本上就是维持每周都有小进度的节奏，然後把这个专案推广出去，用这 样的方式去达成这个新一代的BBS程式码的永续开发目标。 -- 我得了一种在BBS上发完文後会打:wq的病... :wq --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.230.206.42 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1627460397.A.2DB.html