写给知乎:最艰难的告别

这一周,我的工作量很大。因为,我下决心要告别知乎了。为了让自己绝对不可能再回来,我做了以下一些事情:

  • 关注的80+话题,一一取消关注
  • 关注的50+专栏,一一取消关注
  • 关注了880+知友,一一取消关注,就像是向880+朋友,一一道别
  • 收到了2000+个邀请,积压着一直没有回答,也只能一一忽略,抱歉
  • 关注了3000+问题,一一取消关注,这样我就不会看到自己关心的问题的最新回答了
  • 回答了1200+问题,一一看过,有价值的移到自己的blog,然后全部删除,有时候还要再回顾一下评论
  • 写了110+篇专栏,一一看过,转移,删除
  • 卸载了手机上的知乎

这些事情,花了我7~8天的时间。写完这篇专栏之后,我会把知乎的密码改成一个自己永远都想不起来的乱码,以确保自己再也上不了知乎。

 

来知乎已经四年了,我也曾经说过:「说了这么多,但是,我从来没有想过,要戒知乎!知乎依然是我现在最喜欢,也最经常去的网络社区(没有之一)。」

为什么要这么干呢?因为对知乎,彻底失望了。事情的来龙去脉,可以看这几篇文章:

一篇锤子手机总监级别的软文是怎样诞生的?

[知乎专栏–思考IT]运营的底线

[知乎专栏–私吐槽]是什么人,在修改问题?

[知乎专栏–私吐槽]知乎,你们这样真的有意思吗?!!

如何看待『Smartisan OS 中的定时静音功能』问题下出现的许多知乎用户认为是软文的现象?

这个问题里的黄继新的回答!

Smartisan OS 中的定时静音功能设计过程是如何的?

以及这个问题的修改记录里,众多知乎员工的身影!

 

既然想走,那就走得彻底些,最后的最后,我的心情非常复杂,却不想写什么狠话。2年前,我曾经为知乎写过一首诗,就以这首诗,作为这段时光的结束吧。

 

对酒当歌,叹人生兮几何。
古有屈原,咏天问与九歌。
浩瀚苍茫,当上下而求索。
时光荏苒,惜岁月之蹉跎。

昔日艰难,有凿壁而偷光。
发奋苦读,常刺股与悬梁。
名师难遇,千里求学他乡。
知音难觅,伯牙摔琴心伤。

今非昔比,求知易如反掌。
身无长物,揽万卷于网上。
问答辩难,可教学而相长。
千里知音,未谋面却来访。

知乎出世,聚英才于一堂。
稀有社区,以认真为风尚。
妙问妙答,常有缘得欣赏。
牛人高人,可讨教也无妨。

赞曰:
惟愿知乎常驻世,惟愿知友常交流;
惟愿知识常流传,惟愿智慧常增长。

This entry was posted in 知乎.

[知乎专栏–思考IT]运营的底线

在2年前的一个回答里,我谈到了知乎走向失败的风险:可能导致知乎走向失败的最大风险是什么?

周源的理想是:

  • 知乎将持续产生高质量、可沉淀的信息,并让有价值的信息和人都关联起来

而我的担忧是:

知乎的运营,一直都在追求优质的回答。这是大家有目共睹的。但是,何为优质呢?
1、大家都赞同?
2、运营的员工有偏爱?
3、名人?
4、能够激发更多的讨论?
5、具备足够的深度和长度?

这些都可能不是优质的判断依据,但是也有可能被用来判断是否优秀。

我担心的最大的问题,就是知乎运营团队,在何为优秀的判断上,默默的,不自觉的,有意无意的,向KPI低头,向热闹低头,向名人和大企业低头

最终,从一个一流的问答社区,变成为一个二流的,却标榜自己是一流的问答社区。

现在,李奇作为一名知乎员工, 在微博上看到了「好的内容」,就在微博上邀请,然后在知乎「提了一个最适合朱萧木回答的问题」,然后再自己点赞,然后在推送到知乎日报。

这,已经大大的越过了内容运营的底线,而是在践踏的知乎,作为一个问答社区的原则!

在这个问题下,目前有38个回答被折叠,据说原因是「并未回答问题」。但是:「李奇根本就不是在提问」,他只是用提问的形式,「导入了一篇外部的内容」,因为手法拙劣,结果被抓了现行,遭到了吐槽!

一个更加有趣的现象是:Smartisan OS 中的定时静音功能设计过程是如何的? – 知乎用户的回答

这篇@土星光环 拉偏架的「回答」,同样没有回答问题,却依然高高在上。

这真的令人感到不齿!

update1:

对于「donhi feng 是知乎员工」的猜测,是我的错误记忆与判断,特此删除并致歉!

update2:

如果我是李奇,我会这么做: 提一个问题「手机的静音功能设计,应该考虑哪些因素?」

然后,将各个手机厂商相关人等,邀请来回答这个 问题。

然后,等待各种优秀的回答浮现出现,择优挑选上日报。

This entry was posted in 知乎.

[知乎专栏–思考IT]长假记事——聊聊用户体验

在国庆长假的前几天,我在知乎看到了两个回答,心中虽然有些想法,却不知如何表达,也就存在心里,出去旅游去了。

为什么阿里系软件体验都不好?

百度阅读还有什么不足,阅读产品让你来做你怎么做?

虽然这两个答案,我都不太喜欢,但是却不想正面评论,只想讲几个旅游途中发生的小事。

一、华为E585

因为要自驾游,而且是从上海出发,沿途经过南浔、湖州、宣城、芜湖、巢湖等地,所以配一个3G转无线WIFI,非常有必要。在淘宝上与卖家聊了10分钟,在众多的华为E5中,选择了号称性价比最高的E585,再买了一张联通的15G年卡,共计:497元。

但是,这个小玩意却给我们的这趟旅途,带来了极大的方便,全程随身WIFI,流量与网速都丝毫不必担心,唯一的苦恼,是5小时左右,需要充一次电,但是这也合情合理,毕竟那么小小的一个机器,能够撑5小时,已经很不错了。

对于产品的基本要求:提供符合我预期的功能,不要给我带来烦恼

二、高德地图与百度地图

我一直在用高德地图,在相当长的时间里,它也工作的不错。直到这回在芜湖,有一个宾馆,它没有找到。害我们钻到另一个莫名其妙的弄堂里去了。

还好有E585,我当场下载了一个百度地图,搜到了宾馆。

过了两天,在巢湖,我怀着再给高德地图一次机会的心情,搜索了一次加油站。 结果还是没有找到,我用百度地图,再次搜到了加油站,顺利加到了油。

最近,高德地图,还在搞一个活动:「你敢用,我敢赔」。但是,我根本不会想找他赔钱,我直接就换了另外一个地图来用了。

对于产品的基本要求:首先完成基本功能

购物网站无法完成购物,地图App无法找到地点,阅读软件让人无法顺利阅读,这种软件,就没有存在的必要。

三、微信

我们家在微信上有一个群,所有的亲戚都在里面。这次出门,我们基本上每天会在群里发一些旅游的照片。有一天照片发得晚了些,老妈的电话就打过来了:「怎么今天没有拍照片吗?还在等着看呢!」

国庆期间,我爸妈在上海,自得其乐的玩了很多地方,然后每天都在朋友圈里发照片。我有一天忘记点赞了。老妈的电话又打过来了:「我们今天去了XXX和XXX,好多人都看到了,都夸我们了,你看了吗?」我赶紧打开微信,把该补的赞补上了。

回到上海,老妈捧着她的手机过来,第一件事就是让我帮她看看,怎么他的微信又要重新登录了。

这里虽然只是说我老妈,但实际上,我身边的几乎所有父母辈的老人,都极其热衷使用微信。虽然他们很多地方不会,而且学得很慢,操作很慢,打字也很慢。但是这丝毫不妨碍他们,每天玩得不亦乐乎。

对于产品的终极要求:抓住核心需求,满足核心需求

四、 结束语

再来谈谈我对阅读的根本需求的看法:作为一个经常在手机上阅读的人,我大概有百分之90的时间,都是在进行翻下一页的操作。在这个过程中,我的用户体验如何?或者换言之:什么样的阅读体验,才算是顺畅的?

能够顺畅的阅读一本书,这是核心需求。

其次,如何找到我想要读的书?以及,我可能会喜欢的书,该如何找到我?这其中存在一个过犹不及的问题:书太少,没办法读,简直就没有打开App的动力。书太多,读不完,也会有另一种自暴自弃的压力。

所以:根据用户的实际阅读进度,推荐新书,我觉得是一个重要的需求。

因此,我比较认同百度阅读的PM,@冶林 的观点:「细节是否重要?很重要,但是如果连根本需求都没有做好,细节做的再好也还是没用。」

This entry was posted in 知乎.

[知乎专栏–思考IT]成功的开源项目都有什么样的特点?

前几天,我在知乎回答了一个问题:成功的开源软件都有什么样的特点?

一、萌芽阶段
1. 解决实际问题,这是核心,不一定要特别创新,特别酷,当然如果有的话是加分项
2. 定期发布,及时接受反馈,不断满足用户需求,形成稳定预期

二、成长阶段
1. 出色的宣传手段,引导传播的能力,很多不错的开源项目因为这一点不够,始终默默无闻
2. 足够好的协作机制,虽然开源社区通常有较为成熟的玩法,但是做得不够好的项目比比皆是
3. 友好的参与引导,不断的吸引新人加入贡献(包括新手指南,开发文档,Demo等等)

三、成熟阶段
1. 商业介入,获得资金支持(很多一开始选择了不太具备商业价值的开源项目,会始终非常小众)
2. 良好的社区氛围,老人有地位,新人有上升空间,公开透明不内斗
3. 正确的方向感,是长期繁荣的保障

以上这些,都依赖于一个最重要的先决条件:足够强大、足够优秀的创始人+领导者!

这两天又思考了一下,发现开源软件与开源项目,还是有一些差别的。通常来说:开源软件,主要是供最终用户使用,而开源项目,则是一个更大的概念,可以做一个菱形图来说明:

在开源项目的基础上,可以创造一个好的开源生态圈,而基于开源生态圈,会产生一个甚至多个不同的开源产品。这里说「开源产品」,也就包含了「开源软件」与「开源硬件」。

因此,深入思考的结果就是:优秀的、成功的开源产品,依赖于良好的开源生态圈,而良好的开源生态圈,严重依赖于最初开源项目的定位与类别。

例如:依赖于Wordpress的平台,诞生了一大批Wordpress的插件。依赖于Eclipese的平台,又诞生了一大批Eclipse的插件。Firefox、Chrome莫不如是。

所以:一个能够让开发者参与扩展的平台,是建立生态圈的重点之一。

再者,开发、调试、发布、获取、升级、评价这些扩展插件,是否易懂,是否方便,是否快捷,也是一个生态圈,是否能够健康的重要支撑特性。

例如:ruby的gem,nodejs的npm,就是极大的提升了ruby与nodejs的生态圈活力

所以:一个能够支持生态圈得以出现的机制,一个能够辅助生态圈形成的工具,至关重要。

再深入的想一层,当我们开发一个软件,他应该具备哪些功能,他的可扩展性该如何实现,则是考验最初创始人的架构能力的关键。

例如:UNIX/Linux的核心思想:「一切皆文件」

再如:Rails的核心思想:「约定大于配置」以及「Rack架构」所带来的活力

所以:优秀的架构,能够从一开始,就为开源生态圈打下良好的基础。

This entry was posted in 知乎.

[知乎专栏–思考IT]下一代研发平台的四块积木

最 近正在看一本书,就是之前介绍过的Jared Diamond写的《第三种黑猩猩》,昨天又读到了其中一段,是讲人类如何分析动物的语言的。在引入了录音技术之后,人类对于猴子的语言的了解,有了突破 性的进展。通过分析,我们分析出了10个词汇。在没有先进的录音分析技术之前,哪怕是最有经验的动物学家,也没办法了解这么多。另一方面,对于大猩猩的语 言的分析,却很困难,因为他们动来动去,不容易录音。

回到研发的话题,在我看来:缺乏对于研发过程中各种行为的分析,是无法真正改进研发 管理的关键原因,程序员每天到底花多时间编程?花多少时间看文档?花多少时间开会?一个Story,会经过多少道工序,最终被开发完成,发布上线?如果研 发的效率不高,最大的瓶颈到底是在哪个环节?

大数据分析工具出现之前,这些答案,都是被一种奇怪的方式回答的:数据散乱,随意,缺乏统一的标准,领导想看了,下面的人就去搞一个Excel。

如果我们有了足够好的大数据分析工具,问题就得到解决了吗?实际上并没有这么简单。究竟应该采集哪些数据呢?在研发的过程中,相关人员,究竟发生了哪些行为呢?这些行为,是能够被分析的吗?是能够被量化的吗?

我 发出了一个邮件,包含了一个word文档作为附件。这个行为的含义,如何分析?以Github为代表的Social Coding,在我看来,最大的贡献是将原来含混的研发行为,原子化了。star、watch、fork、issue、pull request、follow,过去可能都是在email里完成的。通过社交化服务将研发行为原子化,也因此使得量化这些行为,变得可能。

在写Blog的时候,我们会引用其他人的Blog,这时候,BSP就会帮我发出一个PingBack,告诉那篇Blog,它被我引用了。但是,在开源项目的领域,还缺乏这种项目之间的PingBack机制,因此在项目与项目之间的关系,我们还很难梳理清楚。

一个可以期待的功能特性,应该是基于开放平台的OpenAPI的,假设每一个开源项目托管平台,都支持UseIt这样的API,任何使用了它的项目,或者部署了这个开源项目的平台,都会发出一个UseIt的请求给它。该是多么美好的未来啊?

最后,我们再来回顾一下动物语言的研究,为什么大猩猩的语言不好研究?因为采集数据困难。从这个角度来说,如果开发人员都在自己的本地机器上工作,大多数时候不联网,那么研发数据的采集就会非常困难。如果基于云计算的开发平台能最终普及,所有的研发行为,都实际上在云平台上发生,我想:这个故事就基本上完整了。

因此,我们得到了这样四块积木:大数据分析+社交化服务+开放平台+云计算=下一代研发平台

This entry was posted in 知乎.

[知乎专栏–思考IT]互联网公司的研发组织

一、平台化趋势

各个互联网公司,都有类似的发展趋势,腾讯的总结是:云中发展、轻重分开、快速沉淀。

盛大的类似道路是:将各个技术团队的平台类技术收拢成盛大在线(SDO),在后期由于云计算技术的兴起,又联合盛大创新院与盛大在线,建立了盛大云。

阿里云、京东云、腾讯云,这些云服务的发展趋势,也非常类似。

平台化、服务化、虚拟化、分层化,是统一的趋势。

与这种趋势相关联的,是组织机构的调整,与研发节奏的调整,越是底层的架构,研发(迭代)周期越长,走得更加稳健。

越是上层(应用层)的产品,越是强调快速开发,快速迭代,快速试错。

二、矩阵型团队

随着互联网研发技术的日益成熟,各种工种也逐渐出现:产品经理、前端工程师、前端架构师、后端研发、后端架构、用户体验设计师、运营、运维、测试、安全、策划等等。

大 多数互联网公司的研发团队,都成为一种矩阵型的结构。项目经理+一群研发人员,是一个项目组的基本构成,人数会非常少,3~5个人的规模非常常见。但是, 这些人之外,还有各种专职团队的人员加入:产品经理团队,会派驻1~2个产品经理过来;架构师团队,会派一个架构师过来;与此类似:前端设计师、测试工程 师之类的专业角色,也会被派来。

这种团队的组织,往往是动态的,在项目完成后,也许会各奔东西。

运营、运维、DBA之类的人员,不太会直接加入具体的项目,但是会与项目组有密切的协作。

因为矩阵型团队,交叉协作,多线汇报,使得绩效考核的工作,会相当困难。

三、能者多劳

组织结构与分工甚至技术架构的决策,往往与各个团队的人员能力有关。能力强大的个人与团队,会逐渐膨胀,扩大其职责。比如最近比较热门的淘宝前端团队,推出的中途岛项目,其本质,就是借助Node.JS的后端能力,接管部分原本由后端团队负责的工作。

很多身在互联网公司的员工,会觉得这种情况非常混乱。不过,这也正是互联网公司的活力所在。

 

保留评论:

真正的互联网公司,追求的并不是体系的完善化。而是单点的极致。
以前都在讲,最短的一块板子,决定水桶装多少水。现在这种状态变化了,现在是,所有的板子都要达到一个标准的水准,然后要有一根最长的,要比所有人的板子都长。
对于腾讯那种,已经平台化的企业来说,平台就是他们的产品。平台就是他们最长的一块板,是其他人所无法超越的。
真正的互联网企业,不需要把水桶的所有板子都做得一样长,而是需要保证所有板子都满足基本需求的同时,有一块特别长的板子。

能 够让用户记住你,一想到要做什么,就想到你。就像施乐、巴可,分别成为了复印机和投影仪在一些国家的代名词。如果只是能够提供满足需求的产品,而无法树立 独特的,能够占领用户心理位置的品牌,那么体系再完善都没有意义。还是说水桶,哪怕你的水桶最短的板子,比我的水桶第二块板子还要长,只要你的最长板子, 没有我的最长板长,那么用户就会记住我,而不是你。那么最终成功的就肯定是我。

This entry was posted in 知乎.

[知乎专栏–思考IT]从软件工程到研发管理(三)

三、从一个完整企业的角度,来看待研发行为

真实的研发,至少可以分为两大类:经营性研发与非经营性研发,或者说:以盈利为目的的研发与不以盈利为目的的研发。

在这篇文章里,我们将主要讨论在企业内进行的以盈利为目的的研发活动。

1. 从追求利润最大化到追求研发效率与研发能力

任何企业,都会追求利润最大化,收入越多越好,成本越少越好。

具 体到一家研发型的项目,自然希望自己研发出来的产品,能够卖得越多越好,越贵越好。但是产品的质量不过硬,产品的性能不过关,产品的功能达不到客户的要 求,哪怕软件都开发出来了,也照样卖不掉。我们都知道操作系统很赚钱,但是有几家公司能够开发出 足够商用的OS呢?我们都知道最賺钱的软件例如 Oracle 数据库、Office 套件,Photoshop 套件,但是又有几家公司能够开发得出来呢?

因此我们可以认为: 研发能力,决定了一个研发型企业的收入上限

相应的,研发成本越低越好。由于研发人员通常是固定月薪,所以:开发速度越快,则成本越低,开发人员投入越少,则成本越低。在确保完成的前提下,减少投入,加快速度,就是降低成本的必然选择。

因此我们可以认为:研发效率,决定了一个研发型企业的成本下限

2. 在开放创新的时代,追求利润最大化的更多努力

缺 乏远见的企业,可能只会不断的压榨员工,以降低成本。较有远见的企业,还会想着提升员工与团队的研发能力,以增强盈利能力。 基本上,如上所述,一家传统的IT企业,它追求利润最大化的努力,也就到此为止了。但是,在一个开放创新的时代,企业应该能够找到更多利润最大化的途径, 也应该做出更多的努力。

什么是开放创新呢?

一家企业往往不仅仅只有一个研发项目,跨团队的研发管理优化,有哪些事情可以做?

在一个开源软件越来越具有活力的时代,一家企业有哪些事情可以做?

互联网大行其道,移动互联网热火朝天,各行各业都在加速创新,各种技术的交叉融合,孕育了无数的创新机会,一家有进取心的企业,又该做些什么?

  • 通过鼓励复用以节约成本
  • 通过鼓励创新以开拓财源

无外乎以上两点吧。

3. 研发活力概念的提出

无论是复用还是创新,都需要一个企业的研发团队,具备更加强大的实力。

  • 复用需要架构支持、眼界开阔、充分交流
  • 创新需要组织支持、思路开阔、充分交流

一个具备活力的学习型组织,才能满足以上的要求,作为一个度量思维活跃度与行为活跃度的指标,提升研发活力,对于提升企业的利润,具有重要意义。

我们可以简单的理解研发活力的概念:当一个物体内的分子逐渐开始运动,则物体的温度就会逐渐升高,分子运动越剧烈,则物体的温度越高。

组织内的成员,越是僵化的「仅仅从事自己的本职工作」,则一个组织越是死气沉沉。反之,越是有活力的企业,有能量,有创造力的企业,内部员工的可活动空间就越大,活动的自主性也就越大。

如果我们能够以某种类似热力学定义温度的方式,找到一个指标衡量IT企业内的研发活力,则可以以此来判断企业「在研发过程中,创造利润的潜力」。

<未完待续>

This entry was posted in 知乎.

[知乎专栏–思考IT]极客的进化

去年七月,我去南京参加@极客行动,回到家,在跟儿子解释什么是极客的时候,我对他说:「极客就是这么一种人,他们觉得这个世界不好,他们不会等别人来改变,他们自己就会动手。如果需要改程序,他们就去改程序;如果需要修机器,他们就去修机器;如果需要发明什么,他们就去发明。

今天,我打算接着聊聊极客的进化。

一开始,他们只是去改进。会计电算化,办公自动化,计算机辅助设计,计算机辅助制造,计算机辅助 XXX。说到底,仅仅是利用计算机去辅助些传统的工作,去提高原有工作的效率而已。

再后来,他们不仅仅在改进,而且在创造。甚至是在颠覆。想象过完全不一样的汽车吗?想象过完全不一样的步枪吗?想象过完全不一样的银行吗?想象过完全不一样的工厂吗?各种新技术的运用,不仅仅在提高传统工作的效率,甚至让一些传统行业面临消失的危机。

与此同时,他们在创造各种各样的工具,他们在发明各种创新的协作方式。使得改变世界的难度,越来越低。傻瓜照相机,傻瓜打印机,傻瓜式图像处理工具,傻瓜式软件开发工具,等等等等。

那么,极客们还可以干些什么呢?自我改造!正如我之前的一篇文章《自动驾驶汽车、DevOps、SDE及其他》中谈到的:将 IT 技术应用于 IT 研发之中,进一步加快,甚至颠覆 IT 开发的传统模式,这是一个值得探索的「新」领域。

如果你也对成为这样的极客有兴趣,那么,从学习一门编程语言开始吧!

This entry was posted in 知乎.

[知乎专栏–思考IT]Source Code + X

最近,有一位来自学术界朋友,找到了我们这个开源的圈子,因为他正在做一个课题《开源项目知识共享影响机理》,打算做一轮访谈,他所提出的大多数问题,都是围绕开源与知识共享展开的,我在经过相当长的一段时间思考之后,却打算撇开那些问题,谈谈我的一些思考。

最早的Source Code,其实是非常学术性的,那些科学家们,研究、发明并制造出了计算机,然后再编写计算机能够运行的代码。对于科学家来说:代码与论文非常类似,都是学术成果,饱含知识。他们应该、也必须被分享给学术界的其他专家。

所以,在非常早期的阶段:Source Code + 论文 = 知识分享

到 了1976年2月3日,比尔盖茨发了一封著名的《写给电脑爱好者的公开信》,高唱版权与利益。而且愤怒的将那些免费复制软件的家伙,称之为:窃贼!盖茨的 观点,可以说完全正当,甚至他的逻辑也完全成立,如果无法保护商业软件的版权,那么整个软件行业都不会出现,他们会永远停留在校园里,停留在学术阶段。

所以,在看到的软件利益之后:Source Code + 版权 = 利益

有一群黑客,他们崇尚自由,并且痛恨一切对于自由的限制,哪怕是合理的,合法的限制。伟大的Richard Stallman站了出来,在1985年发表了GNU宣言,并于1989年起草了GPL,提出了Copyleft的概念。

所以,在追求自由的黑客看来:Source Code + GPL = 自由

而在另一方面,「贪得无厌」的资本家们,觉得版权法对于他们利益的保护依然不够,他们需要借助专利的力量,不仅保证对手无法盗版他们的软件,而且连仿制都将违法。从美国的软件专利的历史来看,1992年以后,美国的软件专利保护,一直在承不断扩大的趋势。

所以,对于资本家来说:Source Code + 专利 = 受到更多保护的利益

当 然,这个世界上,中庸的人与团体,还是大多数。围绕着源代码,大家也在探索,是不是能够建立某种利益的共同体,而且这个共同体,并不会追求极端的自由,并 不是仅仅为了共享知识,交流学术,他们拿起了法律的武器,创作了很多种不同的License,用于规定参与各方的权利与义务,不但能够与版权相容,甚至与 专利都不产生矛盾。(最早的Open Source这个名词,诞生于1998年)

所以,成千上万的人们,从五湖四海走来,团结在某一个License之下:

Source Code + License = Open Source
就像我不会批评比尔盖茨一样,没有对于版权的强调,就不会有健康的软件行业。我也不会批评开源运动,没有足够好的利益协调机制,仅仅靠理想与坚持,根本不会有现在这么多开源软件。

总体而言,我的态度是:自由软件值得尊重;软件版权应该遵守;开源运动值得参与;专利说到底是个很糟糕的东西;而知识, 蕴含在任何能够被读到的源代码里。

This entry was posted in 知乎.