第2期 康威定律 (一周阅读与记录)
阮一峰还有其他互联网中的许多人,让我相信互联网的精神就是分享。
于是我也想试试开始自己的周刊,记录我在这一周内的阅读与收获,先定个小目标吧,写下5期这样的分享,每期包括大概10项内容。
目前主要会偏向音视频、网络传输等方面,毕竟现在主要在做这方面。
康威定律
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
设计系统的架构受制于产生这些设计的组织的沟通结构
即系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。
业务-组织-架构三位一体:
所以根据康威定律,系统设计应当与组织沟通方式贴合。这个世上没有完美的系统设计,只有最为合适的系统设计。什么时候最为合适的系统设计,那就是业务-组织-系统都完美贴合。如果是业务导向的,那么就要去调整组织结构。如果是组织导向的,那么就要去调整业务目标。而现实中很多时候,都是三者不相贴合,这样就会在实现的时候互相掣肘,严重影响最终的效果。
康威的原文中提出的各定律:
- 第一定律 组织沟通方式会通过系统设计表达出来
- 第二定律 时间再多一件事情也不可能做的完美,但总有时间做完一件事情
- 第三定律 线型系统和线型组织架构间有潜在的异质同态特性
- 第四定律 大的系统组织总是比小系统更倾向于分解
文章
- 非常适合用来视频编码技术入门,通过docker提供了体验很好的练习项目
- 强烈推荐,也提供了中文版 点击此处
7 YEARS OF OPEN-SOURCE DATABASE DEVELOPMENT: LESSONS LEARNED
- 作者谈到在维护rqlite的7年间学到的
- 尽量进行小的更改,一次只实现一个feature
- 创造力不稳定且无法预测,保持长期高强度、高精力的提交commit是很难的
- 测试的重要性——“正是高的测试覆盖率才能保持高质量的代码”,“测试不会因为神奇的原因而失败,这代表你不完全了解自己写的代码”
- 作为一个团队来构建软件需要大量的非编码活动,需要在编码风格,错误解决策略,代码审查和功能优先级上达成一致。
Go 1.17 will allow converting a slice to an array pointer (some of the time)
- 我们知道在golang中,[]byte 可变,string 不可变,因此正常情况下[]byte 到string,string到[]byte会拷贝数据。但是通过unsafe包与指针转换操作,string和[]byte是可以快速转换的,而无需产生额外分配(应该尽量避免)
- 同样对与类似的slice与array,通过unsafe和reflect同样也能实现转换
- 在Go 1.17中将允许直接转换slice到底层的array pointer,而没有额外分配(commit 1c268431f4,同样存在一些限制)
Converting a slice to an array pointer yields a pointer to the underlying array of the slice. If the length of the slice is less than the length of the array, a run-time panic occurs.
- 遗憾的是,目前无法通过类型断言来检查是否可能panic,需要依赖
if len(slice)
1 | s := make([]byte, 2, 4) |
- reflect包同样也支持了从slice到array的转换commit 760d3b2a16
- FLV是一个比较简单的封装格式
- 这两篇文章挺好的,讲述了FLV的封装格式,我也照着文章写了个flv的muxer、demuxer以及一个简单的flvparser
- 非常好的一篇文章
- 介绍了证书相关的知识以及如何校验证书,最后还使用openssl校验了github的证书
- 证书之间的信任链
- 根证书是自签名的,更新根证书依赖系统更新、设备更新
工具
- 我自己仿照https://pkg.go.dev/golang.org/x/tools/cmd/stringer,写的一个小工具,用于给const(enum)生成对应的描述性信息的map(还在开发中,现在算是能用)