刚 bootstrap 一个小公司的私有项目，来说说这里头的坑点，其实很多的。

重要性排序：

1. 目前根本没有完善简单的一站式方案，你能做的仅有「取舍」
2. 多人协作需要一大堆套件： 源码库、权限、文档管理、任务 /缺陷与需求池管理、迭代管理、CI 、测试服务器群，你全都得考虑。
3. 几个候选对比：
- 首先开源的「代码库项目」不予考虑，因为最多只能满足一两项需求。
- 然后 github ，满足源码库和 CI ，勉强管理一下文档和缺陷，其它的就没有了。
- gitlab ，与 github 类似，但还得自己运维服务器，不如 github 。云上版与 github 也没有明显优势
- 重点来了，最后我们选了 gitee 企业版。注意 gitee 的企业版与开源版是完全不同的。除了 CI 无法实现（它自己的 CI 产品要交高额使用费，自建则限制很大），其它的 文档管理、需求池、迭代看板、服务器群管理（虽说很简陋）、 全都是集成好的可以相互引用。虽然用起来没有 精心调教过的 Atlassian 全家桶顺手，但调教 Atlassian 全家桶是非常非常非常费时间的，你一开始根本没有精力和时间去搞这些。gitee 企业版可以快速凑合用，而且几乎无成本
4. 关于为什么选一站式而不同时使用多个协作平台，主要还是考虑人员组成和权限管理的问题。不同平台的权限分层机制很可能不一样，会额外带来很多心智负担。而且跨平台引用也是很头疼的问题，会导致组员根本不看任务板，他只看代码库。多人协作会严重 fallback 到口头传递任务。
5. 「说没就没」的问题， 请问你是在国内试图开发挑战「合规」边缘的产品吗？ github 会由于你不可控的政治原因删掉你的账户且无法沟通，国内的平台删掉你项目的原因是你在作死。而你要开发的是企业产品，好好想想。


6. 终极方案 & 看看就好： 一个 10 人的运维团队+实体机房的虚拟机集群上跑 gitlab+Atlassian 全家桶，再下一步你的公司已经在开发私有全功能平台了



放一个企业版配置列表
https://i.imgur.com/OzdeRJ0.png

protonmail 有个 @pm.me ，用这个地址发邮件要收订阅费，但接收是不用的。我一般对外邮箱会用这个

然后，@linux.com 这个地址是可以买的

https://docs.linuxfoundation.org/lfx/my-profile/purchasing-linux-email

[email protected]

整天见到一群人喷「自我阉割」，怎么一讨论到 idea 就都上来先「审查！！」

----

说几个硬伤

1. 对于 IM 来说，长链接是非常不经济的，server 和 client 都一样。大多数 im 都会保持一个流量或者负载很小的长链接来同步一些服务器状态，然后消息体用 UDP/短会话连接来发。这个设计里「除非退群否则还会一直保持连接」，我 client 关了群聊还要同时保持数十个群服务器的连接？意义何在？而且根据这个架构，这些群连接是不可能多路复用的，我真的 **必须保持几十个 TCP 连接，占掉几十个端口**。

2. 群服务器之间并不相互通信，所以「任何一个人服务器毁灭不影响整体」纯属无稽之谈，如果服务器=社区，一个服务器没了整个社区都会消失。请务必注意你现在的设计里，社区是运行在单独一个「群服务器」上的，并不运行在整个网络上，这点前面的人说过了但我强调一下，这是与你根本目标「去中心化」最背道而驰的一个设计谬误。

3. 当新孤立用户加入网络的时候，他如何发现全网的群服务器？跟问题 2 类似，假设极端情况两个大「 _群服务器_ 群」间仅有很少的共同用户，当这些共同用户离线后，两个「群服务器群」之间就无法互相发现了。想象一下很少人会同时上 A (cfun)站 B (ilibili)站，当某些用户离线之后，新孤立用户发现 B 站在服务器列表上消失了，what?

4. 还是孤立用户的问题，如果有两个可通过其他方式联系的用户（比如现实好友），他们怎么在这个网络上开始通信？先扫到一个共有服务器？如果两边的网络环境不一样扫不到公共服务器呢？

5. 无法 invalidate 某用户过去发过的消息，这与隐私性极度相悖。由于群服务器和叶子结点客户端都是非官方、非自己控制的，因此不存在可靠机制能确保服务器或结点删除用户的数据。注意「群服务器」是社区搭建的，它完全可以私自镜像所有用户的聊天数据，而你没有任何手段去管控。设想我通过营销手段搭起了全网最大的群服务器，然后偷偷镜像所有聊天记录卖给黑产——没有任何人能管控得到我。请注意这不是个审查问题，这是 **安全问题**。 不过这点可以用与你设计中的朋友圈相同的机制解决：发出的消息只存本地，中转只中转公钥


还有这些相互矛盾的话（红）和无足轻重的特性（青）…… 建议别当成纲领性 feature 来宣传
https://i.imgur.com/gkj4gsh.png





----

大多数的 idea 根本走不到验证阶段
开始实践的 idea 也有相当一部分走不到运营阶段
运营阶段的 idea 大部分也会被现实因素否决
建议「先跑起来再说」

@chaleaochexist

我之前的想法是： 当你要定义一个新 Job 的时候: Schedule(Callback,time) Callback 必然已经是一个静态的函数了，而要持久化，callback 又不能是闭包。那么比如要求 Callback 写成固定名 struct 的 method ，类似这样：

https://go.dev/play/p/cUw99-T55v8


然后又想能不能根据类型信息反射出一个类实例，然后类实例包含一个重写掉的 Run method ，这样函数名就是固定的了，而且定义 Job 的方式能更灵活。 问题集中在怎么得到这个有类型的实例上——


然而研究了大概 6 个小时之后我发现
1. reflect.Type 也是一个接口，意味着就算把类型信息 dump 出来了，我也没法轻易构造出一个实例化的 Type
2. reflect.rtype 是 reflect.Type 接口最重要的实现，这个结构是有办法 dump 的（ unsafe pointer 读），但不能存在覆写一个现存 reflect.rtype 的办法。 通过反射写这个结构会被 reflect.Value.SetXXX 的实现拒绝（有 flag 阻止写回去）；而直接得到这个结构的 unsafepointer 尝试给它赋值会触发访问违例，原因不明。由于我也没用更 low level 的调试器去调（ goland 而已），所以我也不知道是赋值语义还是类型转换语义的问题
3. 不像 C/++ 有函数地址就可以强制转换出一个函数； golang 是无论如何都先得有 reflect.Type 的（光有地址没有用）。由于 2 ，reflect.Type 不能自由构造，因此在语言范围内能想到的 tricky way 都堵死了。




有点蛋疼，前几天才有其他人说 golang 动态性差，确实是不得不承认的

@mengzhuo 不可能的，还会有 goroutine 和 GC 的问题

----

OP 换个思路：
在静态语言中，所有函数都是「已持久化」的、嵌在程序中的。借助反射，函数的地址可以通过函数名查到，所以执行体存个名字就好了
job 的另一个组成部分是参数，而保存参数还是比较简单的，毕竟有反射，如果你想，可以把 runtime 对象整个扫描一遍再用反射造回来

@villivateur

#2L 挺准确的，我就属于第三条，写第一行代码花了一天左右。当然后来又花了两三天时间把官方文档全看了一遍，不过上手开始写之前其实也不用全看完，关键概念和机制 get 到就够了

别语言羞耻，中文文档放心看，没有雷
https://v3.cn.vuejs.org/

说实话我不太建议学习阶段用开源项目作为学习材料

一来很多开源项目架构真的太复杂没法入手
二是学习阶段并没有能力分辨库质量好坏

业务代码就更别看了，世界上没有几行业务代码是精炼过的

我编程学得很早，但也是工作后才逐渐看得进开源大项目的代码的。因为写业务代码会有人告诉你整个系统的架构包含哪些部分和抽象层次，我们现在正要写的东西在哪一层什么功能；你可以从两三个文件入手逐渐摸到整个系统的其它部分。

读代码有点像走迷宫，你得有一个起点然后摸着墙（沿着调用关系链）走，一个文件里包含的数十个函数像是迷宫里并排的几个通道，你看过去了好几个通道（函数），但很可能跟你要走的这条（ API 的调用链）并没有什么关系，会晕是必然的。



个人经验是如果真要评估一个库或者开源项目，就从它的 quick start 或者 bootstrap 看起，观察都有哪些 essential 步骤，每个步骤的目的是什么，然后你自然会考虑每个步骤能不能实现我要的更多需求或目标，逐渐翻阅官方文档和实现，就能慢慢理清楚一部分了。

好的项目模块之间都是很松散的，你完全可以只理解你需要的一小部分然后马上开始针对这一部分做修改。

我只看了一周 vue 的文档也能重写一遍 element plus 的组件——前端组件的组织单位是很小的，一个组件只有几个文件，尽管整个库非常大，但理论上来说我都已经能贡献新组件的代码了，无非是照着原样把文件布置好而已，库的规模并不影响你 **先认知一小部分** 。我想学到一个预期功能需要哪些界面元素、绑定怎样的数据结构、暴露哪些部分，那我其实只需要找到一个组件来看对不对

我也看了很大一部分 gorm 的代码，gorm 充满了各种 interface{}接口和 function dispatch table ，要直接啃源码我敢说根本不可能有几个人能看下来。但如果你只跟着一个 Create 函数进去就会发现结构其实很清晰：一层链式 API 接口，里面一层通用数据结构处理过程（判断 session 、配置、寻找构建器、判断传入值类型等等），再里面一层 clause 构建器（ create 的构建器），再里面是按数据库划分的「构建 driver 」，然后在比如 mysql 的「构建 driver 」里就能看到它怎么拼接 create 和值的字符串、它做了哪些判断和额外操作。这个过程如果我看到不科学的地方比如对关系字段的处理不够好，那我也能开始着手自己的修改。尽管我现在对 ALTER 都干了什么还一无所知，但我已经掌握这个库的一部分架构层次和设计概念了，无非是时间和取舍问题没有对库里所有的东西都摸全覆盖全而已

还有那种更大型的微服务项目，尽管整个项目的体量看起来非常吓人，但你可以先研究脚手架都能干什么、它生成了什么东西，然后搞明白一个 service 单位包含哪些东西。再去寻找猜测可能实现你想找的东西的 service ，逐渐拨开抽象层和数据结构，怎样都是能看进去一部分的

来，我特意在 CSDN 上找的：

https://i.imgur.com/zQbCavc.png

OP 觉得这个词被滥用让人不适，我有同感，但我的不适感来源于这个词的定义太过于模糊了

比如在我看来这楼里提到的大多数行为都不是「抬杠」

据我的定义，「抬杠」一定是与原断言的语义相关的，是针对原断言语义范畴大小的演绎。而诸如「扣帽子」「贴标签」这样的行为是不需要与断言语义有关的，仅需要语句中出现关键词素即可完成，跟杠是两码事了

我心目中的定义很明确：

抬杠=故意抬高原 assertion 的判定标准使得陈述不再成立的行为。

比如「大家其实都不喜欢抬杠」←这个断言里，「大家都」圈定的范围其实是比较模糊的，在允许语义相对模糊的情况下，我说「都」，可以约等于「在全体人群中均匀随机采样得到的样本空间内，大部分」。抬杠的做法即，由于「大家都」并没有明确指代哪个部分，我现在把精确度标准提高，那么「都」是一个全称量词，∀n(n∈自然人):¬(n 喜欢抬杠)存在反例： ∃n(n∈自然人):n 喜欢抬杠，原断言变得不再成立。

用人话来说就是
原断言：「大家其实都不喜欢抬杠」
抬杠：「怎么能说都，就是有人喜欢抬杠」



因此 「杠」字就是那个「标准」
日常交流其实大部分的「标准」都是隐含的，比如当前这句话的「大部分」就没有指出具体是哪些部分。
当语境不需要显式指出所有标准细节，而又存在一个拎出某个细节试图使断言失效的行为，那么这个行为就是「杠」

我来翻译：

「我会一点 x86 汇编，但是不会调试 vm 语言的字节码，是不是不需要会？」

其实系统自带全盘加密是最好的……
灵活性问题建议分多一个区解决

/t/834415
/t/837270

----

大部分人都会看完内容，但他们仅仅想对内容的一小部分发表看法而已

建议下次 h1 加粗写「仅限对本句观点发表评论」

----

没有 ios 设备，现在 ios 不能用字符组合的复杂密码了？

@lujunliang 模板只有在用到的时候才会实例化，实例化前被剔除掉的话根本不会进入语法检查阶段。 trait 类的所有成员最终只会留下 BaseType**推导结果** 的定义。在这个类里写一个 int a(){return "X";} 编译器都是不管的。所以只把声明留下来不要函数体也可以，反正最后编译器不会去检查这个函数的定义在哪里，只是用声明计算类型而已。

https://godbolt.org/z/vq6hM4534

定义一个 trait 类，其中有一个类型成员 BaseType：
当 T::Base 存在时 using BaseType= T::base
当 T 继承自 SomeBase 时 using BaseType=SomeBase

另外介绍一下这个站：
https://cpppatterns.com/patterns/function-template-sfinae.html
https://cpppatterns.com/patterns/class-template-sfinae.html


我几乎每回重新写 trait 都要来查一下。。

只用神州和 e 嗨，除了贵点啥毛病都没有。

两家都能手机自助开锁取还，e 嗨还有 etc ，app 里还车结算。

我刚开始学写代码的时候能记住 10 多个 C 库函数和几十个 Windows API/MFC 类成员函数，参数不说记得很熟吧，有几个大概是些什么还是比较清楚的

后来呢，接触了 c++ stl / java （ android ）/ kotlin / python / golang / haskell ，写了单片机的工程、嵌入式的 linux kernel 和 bootloader 、golang 的 crud 、vue 的 速成页面、unity 的小玩具 …………


别说什么 API 了，sql 语句我都得翻个文档出来参考。
更搞笑的是， 我觉得 dash 还是比较好用的，但后来 dash 也用得越来越少了，还是直接浏览器 google 文档，因为连 dash 搜索我要打什么前缀都要搞不清了：

https://i.imgur.com/7CpSZnH.png