这应该会是一篇比较长的文章,有关于和 Sourcegraph 这家公司的渊源,也有关于远程文化的见解,还有关于工程管理的实践,更有工作这一年来的感悟和收获。在这篇文章里,我会一如既往地瞎写,毕竟我不是什么正经人,骂骂咧咧地搞创作才是让我享受并为之振奋的事情。

如果各位没什么意见的话,那我就开始我的表演了。

八卦故事

来自 Quinn 的一封邮件

2013 年是我学习 Go 语言的第一年,那会儿搞的第一个项目就是 Go Walker( https://gowalker.org/ ),星夜兼程运行至今,不过此时此刻已经是如同鸡肋一般的存在了,还没有下线权当纪念。不过为什么要提到这个一副要死的样子的东西?当初为什么要搞 Go Walker ?它是做什么的?它和这里要讲的故事有什么关系?不要着急,我会一一解答的,我抛这些反问句就是为整篇文章的字数做一点点微薄贡献。

好的,我们先来看说说 Go Walker 是个什么东西。简而言之 它是一个用于在线展示 Go 语言项目文档的网站,技术上继承自 https://godoc.org 比较早期的实现。其实算是一个练手的项目,误打误撞又学习了 Go 语言相关的 Web 开发。那它和 godoc.org 的区别在哪呢?

这是个好问题。因为当时 Go 语言的发展尚属早期,语言的生态比较粗糙,全然不如今天的样子。工具链什么的,混的还不如今天的 Rust。较早接触 Go 语言的都知道,当时写代码唯一可以代码提示的工具 gocode 都甚至不是 Go 官方提供的,可想而知当时的情况有多惨烈。既然写代码的工具链都这么卑微,更不要说可以用什么来浏览代码了,能把 Sublime Text + GoSublime 这个组合跑起来就差不多可以封神了,至于像 Rob Pike 那样盲写代码纯靠编译器?呵呵,别了吧,我头发不是用来这样掉的。

那么回到浏览代码这个问题上,为什么 godoc.org 不行我非要搞个 Go Walker?我是不是有病?从当时的情况来看,godoc.org 的作用非常单纯,就像 javadoc 那样,单纯的展示某个库的 API 文档,比如说 API 长什么样,参数有哪些,文档是什么。总而言之,其对于源码层面的探索近乎于零。唯一能导向源码的地方就是跳转到 GitHub 上的具体某一行,可是去 GitHub 上面看代码,比他妈的本地看还要惨,等同于在看纯文本了,找一套函数调用关系还要靠浏览器的 ctrl+f,真的是要吐了。

于是我呢,就基于当时 godoc.org 的基础上可以把这些 API 的源码直接展示在浏览器里,附加一些比较基础的跳转功能,也算是一个初出茅庐的静态分析展示工具了。比如下图,我不光可以看到 Empty 这个函数的文档、用法,我还能看到它的代码,里面包含了静态分析之后的结果,鼠标点击就能跳转。

image-20200607001012018

这里的关键词是静态分析,因为最早期的 Sourcegraph 也是搞的这件事情。于是,在 2013 年的某一天,TODO

GopherCon 2014

电梯的故事

远程文化

工程管理

生活方式

自我感悟

未来展望