duangsuse::Echo

#Telegram 不管怎么说，我觉得 SCP 的开发者们很有水平，包括是项目最开始『元设计』（把设计的缘由和要点，真正的需求写出来）、项目作者的公钥和联系方式、每个项目的详情（作为博文发布，且有一个包含大概需要的列表）

他们的架构设计也很有意思，虽然基本上完全是 Python 写的，但有趣的地方是：他们利用了 Telegram Bot 和平台本身的集成度，把每个步骤/流程都解耦合划分给了单独的 Bot 实例，通过 boardcast message 来实现数据交流
这不仅仅意味着一切对管理者来说更加可见，还增加了机器人们的灵活性（比如，处理某种消息的机器人可以在某个 Telegram 频道和其他平台模块「对接」，从而在更大的范围里处理消息、群主可以随意引入需要的机器人同时节约计算资源、模块高内聚低耦合无须考虑内部实现、不必在一台主机上运作）

当然，在某些方面也有不好的地方（增加了计算资源开销，因为每个机器人都要遍历消息一遍，如果文本处理结果的复用没做好，开销会稍微大、机器人文本传输给 Telegram 增加了一点点负担、项目结构虽然易读模块化低耦合但略微臃肿）

也有一些我没法理解的地方，比如说 SCP-079 的 HIDE 机器人，其功能就是接收有发布消息广播功能机器人的信息转发请求，做一个『发布代理』（当然，只是二次转发，其出处可以是在一个私有群组/不知名广播里）
而这个代理存在的理由只是「帮助隐藏管理机器人的身份，免得 spammer 认出它们」
可是「spammer」就算是认出了机器人又能怎么办呢？
如果 spammer 认出机器人就不发垃圾消息，可如果机器人保证自己会检查每个人的消息并且提供群成员手工检查渠道，广告就不能存在，而且经常给机器人换马甲也比较麻烦。

HIDE 机器人的代码质量很高，文件划分得也很不错，但是隐隐约约也能感到它划分得有些过头了，因为 HIDE 使用的文件数目相对于它的功能 — 仅仅是按照某频道里的请求转发消息实在是多得过分
— channel.py 是拿来管理交换的，可其中和模块 HIDE 有相当大关系的只有 exchange_to_hide。 format_data 和 share_data 里有不少代码都是和这个模块本身完全无关的，本来应该多划分一个 SCP079-COMMON Python3 包，却采取了每个项目复制一遍的方式来管理
— 为了保证良好的异常安全性，几乎是所有的函数都加上了 try/except，即便有些函数根本不可能抛出异常（比如序列化用的 dumps）
— 同样是异常安全性：

from threading import Thread
from json import dumps

'''
Thread helper function
要我写会这么写
'''
def thread(routn: callable, argv: tuple, nam: str = None,
  catcher: callable = lambda e: log.warn(f"Thread fail: {e}", exc_info=True), daem = False) -> Thread:
  try:
    thr = Thread(target=routn, args=argv)
    thr.name, thr.daemon = (thr.name if nam is None else nam, daem)
    thr.start()
    return thr
  except Exception as e:
    catcher(e, thr)
    return None

'''
那 SCP 写的时候一些辅助函数是怎么写的？
'''
def bold(text: Any) -> str:
    # Get a bold text # 注释而不是文档
    try:
        text = str(text) # 强制类型转换
        if text.strip(): # 尝试在不应该失败的调用上异常安全
            return f"<b>{escape(str(text))}</b>" # 太「空」的缩进语义，应该用 return ... if 写在一行内
    except Exception as e:
        logger.warning(f"Bold error: {e}", exc_info=True) # 极端情况（比如内存耗尽）下，logger 也不一定可以正常工作
    return "" # 控制流不直接（当然也没办法...）

def format_data(sender: str, receivers: List[str], action: str, action_type: str,
                data: Union[bool, dict, int, str] = None) -> str:
    ....
    except Exception as e: # 在不应该失败的情况下处理错误
        logger.warning(f"Format data error: {e}", exc_info=True)

SCP 写的时候有点太过拘泥于某种特定的格式了，也没有用代码块(block) 来进一步抽提逻辑
总之，虽然 SCP 很注重模块化细分，但复用却做得不是很好（必要的模块居然被称为插件！），一个项目里居然能看到 7 个文件全是冗余可共享代码的情况...

附：HIDE 的文件
channel 数据交换管理，其中三个函数皆可复用而无必要放在特定模块里
etc 辅助函数（诸如文本格式化），其中绝大部分函数为无异常(noexcept)甚至纯函数，但全都被加上了

except Exception as e: logger.warn(f"{e}", exc_info = True)

还包含一个 thread 辅助函数和一个 flood_wait 函数，其中 flood_wait 为串行(serial) 阻塞线程的函数，且使用了不必要的 random.uniform [min, maxI), 应考虑将消息发布转为 async 函数来提升便利性和并发量
filters 包含 Pyogram 的两个 Filter（大概是 Telegram 支持机器人只处理特定消息，可这好像完全是在客户端处理的）
from_user, exchange_channel, hide_channel, test_group 其中一个冗余（在使用元编程的情况下四个均冗余），可用 1~2 个函数抽提逻辑
逻辑表达式（兼控制流断言）代码质量欠佳、在不可能失败的情况（0 分配布耳表达式）下依然 except:...

        if message.chat:
            cid = message.chat.id # 代码质量不佳
            if glovar.should_hide:
                if cid == glovar.hide_channel_id:
                    return True
            elif cid == glovar.exchange_channel_id:
                return True

should be:

xchannel_id = glovar.hide_channel_id if glovar.should_hide else glovar.exchange_channel_id
  is_exchange_channel = ptgfilt(lambda m: m.chat && m.chat.id == xchannel_id)

receive 也是两个可共享逻辑
telegram 的 forward_messages 属于可以共享的范畴，可以考虑抽提。 send_message 属于应该共享的子程序
其中，Telegram 的 FloodWait 可以利用函数装饰器抽提
不可能出错的函数不应该异常安全处理

try: / if text.strip():

对 None 的判断应该显式标记

if text.strip():

在 Python 里，使用提前返回而不是嵌套 if
对于单个 Flag 的 while 循环，使用 break / next 比 flood_wait = True... 要强
如果可以不用 ret 系变量仅仅用于临时存储返回值，就不用或者最小化限制其作用域 result = None ... return result，这里 result 可以更名为 lastresult 以强化重试到成功的逻辑

backup: 简单的 ping 逻辑，完全可以在所有 bot 间共享，但却每个 bot 复制了一份

文档里经常出现这样的代码实例：

exchange = format_data(sender = 'LONG', receivers = ['MANAGE'], action_type = 'request', action = 'leave', data = /groupReason/)

也恰恰证明了这是一个协作有方的团体，尽管并不大。
包括 Telegram 上明确的文件列表和叙述、清楚的模块细分，也是高水平程序员的标杆

51 viewsduangsuse /'dʊɔːŋ sjuːz/ | [⃪PLD, FPλ], edited 13:14