本文背景
前几天TWGC会上, 很多人对自己过去一年在参与开源项目过程中的心得体会与收获进行了总结。我总结能力不太行,姑且写下此文。权且算作鄙人从一个开源使用者,经历参与开源,贡献开源,到不才成为子项目组/SIG副组长的过程中的部分收获。
参考LF基金会的文章, 这里我把自己视为了一家“公司”。对自己的开源战略进行了规划,具体内容写在本文,仅供大家茶余饭后作为谈资。
个人收获
我把收获分为两个部分,技术水平和思考问题的方式。这里我并没有严格参考基金会文档中的直接和间接分类与定义。
我会以如下格式记录书写,如果大家不想看冗长的细节,请通过右侧大纲跳过。
### 项目
_摘要_
- 证据 1
- 证据 2
动手实践部分
golang编程实战
参与维护了一个基于golang书写的用于Hyperledger Fabric性能测试工具或者优化一些需要提高性能的开源代码库,可以全方面的锻炼能力。有什么比通过让用户使用来验证你代码效率更能证明项目效率的事情呢?
- 多线程
压力测试明显是一个多线程的程序,简单来说我们需要启动多个进程来赋予被测系统工作负载,也就是压力。多线程只有一个模型,生产-通道-消费
, 万变不离其宗。 - TDD实战
不多写一行无用的代码,不多加一个无用的功能,目标导向。 - 内存逃逸处理
我们的代码在细节层面性能不够理想,怎么办?与其日后面对这类任务的时候不知所措,不如看那个库有可以练手的机会,上去改。试问golang内存逃逸如何处理?
异步,让大家都有喝杯咖啡的时间
之前看到TED上总有程序员来做分享,在生活中使用各种编程思想甚至敏捷
- CI
我现在最喜欢分屏幕工作,不是说mock和ut不重要,而是我们依旧无法保证会不会有雪花环境之类的问题。 跑上CI,我去喝杯咖啡,CI过了,把PR从draft转化为ready for review,LGTM。
IDE | 浏览器
impl | code | CI | stack overflow
- 远程协作中的异步体现
各个领域的大牛分布在世界各地,或者全国各地。我们也没办法指望其他人7*24随时回复你的消息。因此,通过在github上开issue/mail等方式进行远程异步协作,真的不错。从而让自己可以同步的在不同项目上有所进展。我最近需要训练下如何进行响应式思维了。毕竟有了request还是需要对event进行相应的。
request sth
on success ...
on wait ....
on ...
更加有效的搜索
避免重复造轮子最大的阻碍不是如何使用轮子和梯子,而是如何搜索,善用的github和其他工具的搜索功能,善于使用正确的词汇来描述的你项目/问题。
知识的获取与储备
我们很难在每个领域都成为专家,对于哪些自我苦手的领域/或者暂时不需要专精的领域…
请教专家
能够找到人问,看起来不是什么很值得写在这里的,但是在那之前?对于一个你不熟悉的领域,你应该找谁问呢?你应该如何确定这个人是专家呢?在解决某问题的时候,如果这个问题足够的普遍/普适,肯定会吸引到一些行业/领域的专家。
不懂 -> 找人问 -> 找谁呢? <- 被同一问题吸引而来的专家
思考总结,成为砖家
很多时候我们对于一些自己认为理所应当的问题,并没有很好的总结。当与他人分享的时候,我们就需要总结并思考。并提高自己对于知识的认识,将其整合进入自己的知识体系。
不懂 -> 理解 -> 懂 -> 给他人讲懂
描述,思考的角度
观点能否被其他人接受?如何说不?
开源社区,群策群力,观点基于某个角度出发,有理有据。明显有效的避免某种思维局限。想想看上一次我们先入为主的代入某个观点的教训。
最后
欢迎大家参与开源社区活动与建设,充分开放自己的思维。TWGC开源工作组地址