低代码到底是不是行业毒瘤?一线大厂怎么做的?戳此了解>>> 了解详情
写点什么

对话鉴释首席架构师刘新铭:程序员不要“做一天和尚撞一天钟”

2020 年 12 月 17 日

对话鉴释首席架构师刘新铭:程序员不要“做一天和尚撞一天钟”

最近,InfoQ 记者在鉴释北京办公室对鉴释联合创始人兼首席架构师刘新铭(Shin)进行了独家专访,主题涉及软件开发、软件质量和软件安全、程序员、编程语言等。本文是采访实录,希望能给你带来启发(对话内容略有调整)。如果想看精简版,《66岁还在写代码,这个程序员想把bug扼杀在“摇篮”里》。

我是谁


Shin(刘新铭):我是鉴释的联合创始人兼首席架构师。我的工作是跟我的 CTO 陈新中共同设计我们的产品,我们分工明确,彼此互补,共同调整。


基础架构跟一般的写代码不太一样,当然,我也写代码,主要是在核心算法方面写代码。除了核心算法之外,在云上面的架构,我就跟我们另外一个架构师一起讨论、一起合作。所以,总体来说我就是在鉴释负责技术方面的工作。当然在研发方面需要帮忙的时候,我也会帮忙,比如我过去半年就在做项目管理,把公司项目管理从 0 到有把它做上轨道。

从业经历


讲到过去,我入行是 1984 年。从 84 年开始的 10 年时间,我都在做编译器,从最底层的开发人员做到惠普的整个工具链(Tool Chain)的负责人,负责整个工具链,包括了编译器、debugger 和性能分析器等,给惠普服务器、安腾服务器做的工具链。之后,我去做了两年操作系统,主要还是管理的工作,负责惠普分布性存储的内核部分,也是最难的部分。我们的主要工作目标是性能调优,把所有性能方面存在的大大小小的问题修复好。接下来还搞了三年的物联网,我在英特尔实验室做首席科学家,(担任)物联网实验室主任,在北京跟北京市政府合作做了几个物联网端到端的解决方案。后来,我就去了国外,在美国一家华人公司待过两年,帮他们做数字化转型,因为在那之前,该公司的软件都是用 Java 写的,我们把它变成更适合在现代的云端架构上面运行,所以这也是为什么我现在在鉴释负责有关云方面的技术和业务。在职业生涯中,我有一半的时间是在写代码,算起来应该有百万行到 150 万行了吧!


InfoQ:那您属于非常老的程序员了。


InfoQ:您现在还一直在写代码是吗?


Shin:还在写。


机会与回国创业


InfoQ:您之前在美国那边工作,后来回国参与创立鉴释,为什么会从美国回来创业?


Shin:这个也是因缘巧合,我们 4 个创始人都曾在同一家公司做资深管理,或是架构方面的工作。讲到这三四十年系统架构的改变过程,(它在)未来的十年已经失效。我们看到前面 25 年行业的飞速成长,到后来云架构的诞生,但到最近这两三年,我们看到整个藉由芯片性能的大幅提升期结束了。今年中国计算机大会(CNCC)邀请了 John Hennessy,谷歌的董事长,也是前斯坦福大学校长来发表演讲。他说,未来十年,IT 产业的变革,将从通用的 CPU,蜕变成雨后春笋般各种应用为主的架构,即特定领域架构 DSA(Domain Specific Architecture)。AI 芯片会如雨后春笋(出现),目前,全中国大概就有 5 到 10 个 AI 芯片同时在做。


在这许多特殊的架构做出来的时候,整个软件系统会变得非常复杂,这给我们这些做编译器和系统软件的人一个全新的机会,因为在当前环境之下,你真的要把各种很复杂的环境搭建起来,然后让各种硬件性能能够凸显出来,复杂度非常高。那复杂度高的同时,软件质量的高低就会越来越重要,安全漏洞也会频繁出现。近十年,安全漏洞出现的速度是以几何基数增加的,怎么样把几何基数增加的安全问题和软件质量问题管控下来,是全世界共同面临的问题,而这些问题在中国又异常突出。


过去 20 年,从互联网开始腾飞以后,中国的软件产业,拿来主义比较常见,例如开源的拿来就用。但拿来主义普遍存在问题。在西方有一个很有名的比喻,说猴子、香蕉跟丛林,一只猴子,它想要吃一根香蕉,去找这个香蕉,最后搬回来了一个很庞大的丛林。这是什么意思呢?其实,它真正想要的是香蕉,是从香蕉树上找到香蕉,可是香蕉树跟整个丛林全部缠在一块,猴子没有办法只把香蕉跟香蕉树从那片丛林里剥离出来,它就只能把整片丛林搬回来。所以,中国的软件不论大小都或多或少存在“大丛林”的问题。很少有软件能做到吃香蕉就只有香蕉而没别的,很难!这是中国软件产业面临的普遍现状,当然,全世界软件大致都存在这样的问题。那我们能不能把那些没用的东西剥离开来呢?太难了,因为全部东西都是绑在一块的,尤其是 Java 这种语言,很难去剥离。所以在这种情况之下,软件质量问题就会显得比较严峻。


InfoQ:确实。


Shin:要有很大的勇气,而且需要大量很有经验的人才,才不会犯别人已经犯过的错。


InfoQ:对,并且中国缺乏高质量而且资深的软件工程师。


Shin:大家都叫码农。


InfoQ:国内一些公司,程序员在软件开发方面缺乏很深的造诣,他们的技能一直停留在比较初级的水平。因此,没法在一些技术上做深。


Shin:这个东西要做深了,才敢把那些没用的东西剥掉,所以我最近老跟大家说,你知道什么是猴子、香蕉、丛林吗?


InfoQ:第一次听说这个比喻,很有意思。


Shin:你可以去搜一下 Monkey、banana、jungle。


InfoQ:你们回国创立鉴释科技,您觉得你们的机会在哪里?


Shin:第一个机会,国内真正把这个事情做起来的公司凤毛麟角,竞争者少。更重要的是中国的软件市场巨大无比,当我们觉得现在看起来没什么机会,其实机会正在形成之中,而正在形成中的机会就很难去量化。举个例子,在一个人收入只有 1 千块人民币一个月的时候,他在乎的事情,跟他收入在一万块或十万块的时候是不一样的,他收入每个月十万块的时候,他会在乎生活品质,而收入 1 千块的时候能活着就不错了。我觉得中国的软件现在正从一万块到十万块的这个过程中,这个速度会加快,因为中国的市场很大。举个例子来说,欧美安全扫描软件方面的工具,肯定是没有搞小程序的。


InfoQ:是的


Shin:因为小程序是中国特有的,中国人发明的。


InfoQ:因为它是依附于微信生态的。


Shin:对,但是你仔细去看,不只是微信生态里面有小程序,各家都开始搞这个小程序了。因为大家都受不了写个应用还得弄一个安卓版、一个 iPhone 版,小程序就一个版本,这就产生了中国自己原生的架构。现在小程序的使用方大都还是小户,比如点餐的,就算黑你一把也拿不到什么钱,但慢慢的小程序开始处理更多、更大额付款时,这种应用越做越多,迟早会有黑客看上这个市场的,对吧?


InfoQ:对。


Shin:那这个东西除了在中国做,还能在美国做吗?这就是中国独特的地方。那除了小程序以外,我相信类似于小程序的应用会雨后春笋般出现,因为中国的手机使用量是全世界第一的,光中国移动广东移动的手机发出去的电话号码数据就超过全美国的任何一家电话公司。


InfoQ:确实。机会还是挺大的。


解决软件质量和软件安全问题


InfoQ:您提到,现在传统的应用变成了这种云上的应用架构,也会有很多软件复杂度方面的问题,还有软件质量和软件安全问题。所以你们创立鉴释,是想解决这个软件的安全和质量问题的,对吧?


Shin:是的,其实我们想要打造的,首先是要打造工具,找出问题所在,这个工具能教你怎么样解决问题。然后就是管理,怎么样把开发软件的方法,用更科学的方法管理起来。近几年,欧盟有一个立法叫做《通用数据保护条例》(General Data Protection Regulation,简称 GDPR),它不只列出了不能触犯的具体规范,而且提出在软件开发过程中,需要用什么样的流程管理才能做到完整的隐私保护。行业里经常会存在“道高一尺、魔高一丈”的情况, 经常规范一出来的时候,要黑你的人就已经升级了。所以欧洲搞这个 GDPR 的时候,它就不再只是强调严谨的自我规范,而是要求在做软件的时候,要有流程上的管理机制,然后又要有足够的手段来保证管理机制的确有策略地执行,而没有违规做一些规范外的操作。所以要想在国内很快把观念转换过来,并不是那么容易的。国外也有企业因为这样的违规被罚巨款的情况。


InfoQ:实际上,我看到欧盟在这一块的处罚还是比较严的。比如,它们处罚 H&M,罚了几千万欧元。


InfoQ:国内互联网的发展速度很快,很多新兴的创业企业会强调一些理念,比如小步快跑。因为业务的发展诉求,开发人员可能会为了赶进度,忽略代码质量,这样做可能会给项目带来很大的影响。那么,对企业来说,应该如何去权衡这个业务诉求和软件的代码质量和安全要求?


Shin:用一个比较形象的比喻,你如果去故宫博物院参观,大概每一年或每个季度,它都会有一个特定主题的展览,对吧?


InfoQ:对。


Shin:那个主题展会有一个负责人,美国叫做 Curator。譬如说,他要做一个展览,来展示雍正的生平。雍正是怎么样的一个人,他的工作习惯,他在工作之余都做哪些事情,生活上如何排解自己的孤独,还有他工作忙到什么地步,焚膏继晷地批阅各种奏折。


InfoQ:有点像策展人,是吧?


Shin:是,策展人。所以,那些所有搞小步快跑的人,其实做的都是策展人的事情。他们设计出来要展览的内容,在每个角落、每个转角,他要展示什么东西,他希望这个参观者从进去到出来能留下什么样的印象。国内的软件大部分都在干这件事情。那策展人不能在要展览雍正生平的时候才去发明雍正穿什么衣服,或者雍正用过哪些东西,他一定是现有什么东西能拿出来用,然后哪些地方不够的话,世界上另外哪一个博物馆有,我们把它借过来用。所以那些素材就是我们现在讲的 OpenSource。所以当策展人跟 OpenSource 之间的关系是这样的时候,结果就是策展人以为他自己是一个软件开发者,其实他是吗?不是的。这个在中国存在的一个相当大的误解。但也不是说所有的软件开发者都是策展人。张小龙搞出微信来,他就不是策展人,他真的是要解决一个问题,用最简单的手段,所以他一路把架构跟技术做起来,从 0 开始做。但国内那些小步快跑的,我挑战他们的是,有几个是像张小龙一样从 0 到有把这个东西架构起来的,我觉得比例非常小。未来十年,还能这样走下去吗?我觉得每个搞软件的人都得仔细想一想。我不能说每个人都会得到同样的结论,他说我策展人就是策展人,我公司这么小,我不这么弄怎么弄?所以家家有本难念的经。到最后就是有点节操的、有点情怀的人也许会有机会搞出一些比较突出的东西,然后最后好多人会集中到那些比较突出的几个亮点创新上,把一些小的东西做大、做好,我觉得这是未来最有可能的发展方向。但以我写软件这么多年的经验,我的主张是,策划的时候就要从头到脚看透,不要用策展人的心态来做软件。


软件源代码安全


InfoQ:有人说,软件正在吞噬世界,但是源代码是软件的基石,因此如果源代码出问题的话,影响就特别重大,您是如何看待现在软件源代码安全的?


Shin:举一个最好的例子,这个就要讲一讲美国的坏话。在 2014 年,(业界)有一个很隐秘的 bug 叫做”Heartbleed 心脏滴血“被揭露。


InfoQ:心脏滴血漏洞非常有名,我听过。


Shin:心脏滴血漏洞是 OpenSSL 里面的一个 bug,这个 bug 是在出问题的地方跟真正引入问题的地方,中间隔了 4 层的 processure code。从这边拿进来的坏东西到真正用上,中间隔了好几层的函数调用的层次,4 层。这个东西,当它曝露出来以后,就连带着暴露了几个问题。第一个问题,美国 NSA 早就知道了,以色列的那个情报机构也早就知道了,可是他们在默默地用这个后门去偷全世界各地的信息。


InfoQ:就是利用这个漏洞来干坏事,是吧?


Shin:不能说它干坏事,它是把信息都搜集到了,不该搜的也搜了。这是第一个暴露的。同一年,第二个暴露的,同一个机构把思科 data exchange 的机器,从思科的发货点到客户的接货点中间截了,然后把它的火漆打开了,在里面插上一个特制化芯片,并把所有的数据备份到 NSA,这个视频在网上是能查到的。西方是比较透明,它就什么事情都(曝)露出来了,呈现一个现状:开源里面有很多的漏洞,可是厉害的人看到开源的漏洞,假设它有足够的权力跟财力,它就会做一些不该做的事;那有一些比较低级的,它就做一些坏事,把你的数据弄走了,让你付钱,花钱消灾,可是问题一直都存在。可是如果你就说希望我自己的东西没问题,英文这个叫 Murphy's Law(墨菲定律),你觉得可能会发生的问题一定会发生,只是说发生的时候,你付出的成本是多大的问题,对吧?就像我刚才讲的,谷歌违反了 GDPR,欧盟罚它几亿元,但是这边一个小开发商,他的用户就是几千个,欧盟会罚吗?它觉得机会成本太高了,它也懒的理你,对吧?那中国这种都想试试看,我们说你不会碰我的,大家就会存在侥幸心理。


InfoQ:对


Shin:可是存在的,而且很严重,想一想要吃一个香蕉,结果拿回了一片丛林,我们不知道那片丛林里面有什么虫子、有什么蛇、有什么猛兽,只有当我们真正被吞掉以后,才知道就太迟了。


InfoQ:在您看来,影响软件源代码安全的因素都有哪些呢?


Shin:影响软件代码安全其实是一个不断演进的过程。譬如说,我写一个专门摘香蕉的软件,可能两三百行就写完了。后来,下一个客户来了说,你摘的香蕉挺好,我现在需要摘橘子,那你把这个软件改成也能摘橘子。再下一个客户说要摘苹果,然后这个软件就越长越大。更重要的是,需要摘香蕉、摘橘子、摘苹果可能是三个不同的人。那第三个人摘苹果的时候,它有两种选择,可以把前面的软件重构,把它简化,写得干净一点、漂亮一点。可是通常的情况是,明天就要交货了,那就只好赶工,赶工的时候就开始偷工减料,软件质量就会越做越差,所以安全和软件质量问题就是这么来的。


Shin:假设这次需要变成摘各种水果,那软件就是我们现在讲的丛林,因为没有一个人能够把这软件的来龙去脉都分析清楚,也没有人会去在乎。所以这就是为什么 Linux 的创办人,叫 Linus Torvalds,他最终接了一家公司的 offer 去当一名员工去了。


InfoQ:我前段时间也看到谷歌浏览器上有两个插件,插件的项目人把两个插件卖给了一个土耳其的开发者团队,然后那个团队在插件更新版里面插入恶意代码。因为这两个插件在 Chrome 上有超过 30 万次的下载安装,恶意代码进入后,它就可以控制浏览器,甚至可以在 Instagram 上面对一些图片点赞,访问一些没有打开的用户。那个插件的原开发者也是由于项目的不断增长,个人没有时间来维护。


静态代码分析工具


InfoQ:您觉得在解决源代码的安全上,静态代码分析工具,可以发挥哪些价值?


Shin:静态代码分析工具,我们自己实现的方法是通过编译器,编译器跟别的方法在根本上是不一样的,因为编译器必须把程序里面它真正想要做的事情,从程序员可以看得懂的变成机器语言。这中间的过程,不能把它想要做的语义改造脱离它的原意。因为要达到这个目标必须要把它所有程序里面的语义掌握起来,把它抓起来,我们叫做 IR,就是中间表示 Intermediate Representation。有了这个东西以后,自然而然可以在数据流跟控制流上精确地掌握所有程序里面的内容。譬如说一个变量,在哪宣称的变量?到哪用上了?这中间经过哪些控制流?我们是一清二楚的,用编译器可以查得很清楚。它可能是十几、二十个、三十个、上百个控制流下来,如果不用我们这个手段做的话,如果说执行到哪个特殊控制流的时候,错出来了,Bug 就出来了,这不是任何一个测试能够搞定的事情。有人说,那就多测试一点,问题是每一个控制流的变化,就是像 if else/if then else,就是 1 变 2、2 变 4 嘛,经过 10 个 if then else 就是 1024 个变化了,对吧?2 的 10 次方,那我们程序里面几千个、几万个 if then else,那就是 2 的几千、几万次方的变化,测试是不可能搞定一切的,但是用静态定义分析的手段是可以把所有走过的路线都分析出来的。到时候,你在这边可能会错,我确定是没有错的,然后我们除了给你分析出来了以后,这个英文就叫 detect,找到你的问题,然后帮助你,把你这个问题修正 correct,所以 detect、correct。我帮助你修正只是给你建议,你要是相信我的话,我直接帮你修好了,我就把你的代码保护好了,这是第三个阶段是 protect,那最后就是把我们的工具整合到你的整个软件开发的流程里面,跟各个工具整合在一块的时候,那在你写代码的时候就能预防错误,做好修改。所以我们是用这种阶段性的手段,把这个静态编译的完完整整,把各种可能错的地方都帮你找出来。但是你有时候还是会心急,因为我们很容易让一个软件找到几千个、几万个问题。像我们帮国内有一家很有名的公司做的开源软件分析,一找找出个 2 千多个(bug)。


InfoQ:实际上,像这种工具,比如静态代码分析工具,它能完全找出一个软件中的全部漏洞吗?


Shin:这有两个层次,一个是说我要找什么样的漏洞,第二个是某一类漏洞,我能不能把它找齐,全部找出来,这是两个层次的问题。我们的算法可以保证找这某一类漏洞,可以百分之百地找出来,而不会漏掉任何一个。


InfoQ:就是特定的漏洞可以全部都找出来,是吧?


Shin:对,我们说把所有的已知漏洞都做完了吗?没有。我们公司只有两年,不可能把所有应该已经看过的漏洞都找出来,但是只要是属于这一类的漏洞,我们做了,就一定能把它找全,这是算法的优势。


InfoQ:实际上,我也了解了一下,像 Java 这种静态代码分析的理论和基础主要是有 4 种,比如缺陷模式匹配、类型推断、模型检查和数据流分析。您能否介绍一下静态代码分析技术的最新发展情况?


Shin:你讲的那 4 个类别,我们唯一不做的是第一个,缺陷模式匹配。为什么不做这个?因为这个东西是死的。我们看这个代码,看起来这个形状就是错的,所以这个只能找别人已经找到的错误。我们不做这个事儿,我们是找那些别人没找到的错,我都可以找到,所以我们是用最后那两个:模型检查和数据流分析。我们主要是靠这两个。然后是第三个 Type Inference,因为 Java 本身就是一个 Typed Language,Type Inference 在我们编译器里面是必须要做的,所以除了第一个以外,其他三个我们都做。那目前市场上大家做的东西,你可以说它们是符合其中任何一个,但不会是同时照顾所有的,这是不可能的,大部分只有一个,或者是两个,不会超过两个,因为要同时照顾那么多个角度的事,除了编译器之外,没有其他的更能够把它近距离掌握的方法。所以我们基本上除了第一个以外,其他三个都有涵盖。


InfoQ:在您看来,静态代码分析工具对开发者和企业,它的价值是什么?


Shin:价值的话,举例来说。当你在意生活品质的时候,就会在意食物和穿着了。假设大家在乎软件品质时,价值就是,让软件送出去以后 bug 最少,bug 少的时候,维护成本就少。有人做过统计,如果说在开发的过程中,就找到了这个 bug 并把它修正好了,假设是 1 块钱的成本,在做 Q&A test 的时候,成本就是 10 块钱,到客户的场景中出了问题的时候,成本就到了 160 块钱。在客户应用场景(出现)的问题,要把它还原成真正源代码错误的问题,中间经过那么多人的手,那么多人去分析,所以对于真正在乎软件成本和质量的开发人员和开发公司来说,这是非常有价值的。如果退而求其次,它不在乎这个成本,但是必须要合规才能推出这个软件。那我们的代码分析软件,能给它提供非常关键的合规诉求。比如说自动驾驶,必须要通过 MISRA 的认证,那你得用工具来分析一下是不是合乎 MISRA 认证的标准,这是合规的要求。第三个就是开发人员的效率。我个人写代码写了那么多年,我自己知道,做一件事情的原则是我做完一次、两次,第三次一定是想办法把它交给别人去做。但国内可能会相反,我做这个东西最好别人都不知道,所以这将永远是我的项目,老板永远不会砍我的头,这是两种完全不同的思维。从我个人经验来说,如果这个工具可以帮助我把这个软件做得更好,那我就可以把这个软件交出去让别人来做。没有人愿意接手一个天天要修 bug 的软件,但是会很乐意接手一个高质量的软件。


InfoQ:实际上,在很多企业里面,大多数软件开发团队还是依赖动态测试,相比动态测试,静态代码分析,它的优势是什么?


Shin:在写程序的时候,有控制流 if then else,如果说程序里面只有 10 个控制流,大概还能弄出 1024 个测试用例,因为动态测试就是把测试用例灌进去,然后让可能出的错在还没有发布之前把它报出来。假设有 10 到 1 万个的 relations flow,那就不可能了,所以业界在 30 年前做硬件测试的时候已经下了结论。所有的测试,如果说不去从设计的角度来分析,专门靠测试来把所有可能执行的路线都执行完,那是不可能的,这是一个复杂度上不可能解决的问题。


InfoQ:业界也有许多这种静态代码分析工具,比如 CheckStyle、FindBugs 还有 PMD 这些,其中有开源的,也有商业付费的,我看鉴释的主打产品爱科识也是源代码分析工具,您认为相比它们,鉴释的产品优势是什么?


Shin:你刚刚举的这几个都只是针对 Java,但是现代软件系统不会只是一个 Java 搞定天下,性能 performance critical 的,会用 C 和 C++写,外面包装的用 Java 来写,在互联网互动 across internet 时,用 JavaScript 来写,或者是由 Python 来写 AI 算法,所以单一语言的时代已经过去了。未来的世界是多语言、多模块、而且是跨越 Internet 的,越来越复杂。目前包括鉴释在内,在全球,业界并没有一个工作能够做到完完全全把一个解决方案从头测到尾,从头分析到尾。所以你刚刚举的那几个,有的是单一语言分析,有的分析只能在一个函数里面分析,要跨函数的时候,它们是做不到的,那既然跨函数都做不到,跨模块就更做不到了,跨语言就有更大的问题了,就更难做了。


InfoQ:市面上有种类繁多、各有千秋的工具,企业应该如何去权衡和比较?如何选择适合自己的静态代码分析工具?


Shin:关于选择的问题。第一,很多企业会选择最便宜的。第二,有些企业会说要买包就买个名牌,LV,这是两个极端。但是我觉得应该是在中间,就是用能够付出的价钱拿到最好的回报。如果没有一个标准的基准就比较难 benchmark。其实真正困难的是什么?真正困难的是卖给谁的问题。假设一个很开明的软件开发经理,管理 20 人的团队,把这个工具拿来,所有人扫一遍,然后把所有找出来的这个错,组里面的每个人都去修,如果说每个人都修,修完以后哪一个软件使他要动手修的 bug 数量最多,那肯定是最合用的,对吧?


InfoQ:对。


Shin:可是我是应用开发,想一想老板在看着,跟老板要了几万、几十万去买了一个工具,结果不买不知道,一买才知道你们做的软件有那么多漏洞,怎么找出来那么多错?那你是买那个找出来的错最少的,还是错最多的?还是让老板来决定一切?再一个就是 QA manager,他要去选一个能满足合规需求的,跑完以后就合规了,软件就可以发布了。每个角色想的角度不太一样,那怎么样去选?我觉得在工具的选择上,当用户没有感到切身之痛的时候,他们的选择可能就随机一些。但一旦有切身之痛的时候,它们就会选那个找出错误最多的工具。


InfoQ:当开发者遇到真正痛点的时候,他才会去找真正有用的那个工具。


Shin:是的,这里我分享一个美国的经验。今年 6 月份的时候,有一个 conference,叫做 SOAP,它跟另外一个 conference,就是编译器界最有名的 conference 叫 PLDI 一起合办的。这个小 conference 上,它们邀请了两个仍做主旨发言,一个是脸书的,一个是谷歌的,两个都是他们内部的静态代码分析的负责人。会议上,他们不约而同,讲了他们整个演进的过程,他们刚开始在使用静态代码分析工具的时候,大约都在 2012 年到 2014 年之间,但是刚开始的时候,没有人理他,因为经过分析,修改的比例是 0%。


InfoQ:就是没有人采纳。


Shin:没有人理。后来,它们就使出一招杀手锏,不约而同把所有的人的代码 checkin,提交到公司的代码仓里。代码仓自动把这个 standard annalysis kick off 完了以后,报告出来,直接放到公司一个内网的公告栏上,之后,它的那个修复率从 0%到(飙升到)70%,直接升上去,原因是什么?那个演讲人就说,我们所有做代码评审的人,就问一下说某某某,我刚刚看到你确定的东西有一个新的错,你准备怎么办?那肯定是以最快的时间把它修好。


InfoQ:是的


Shin:这是痛点,人说到痛的时候,他就会做什么?他就会用这个工具。然后当全公司都在看你的时候,你当然会修了,到后来报出来的错越来越少,为什么?因为每个人提交前需要自己先跑(一遍)。那你可以看到这件事情不是说它的那个错误变少了,而是说每个开发人员的行为变了。我们要的是改变开发人员的态度和行为,刚开始是怕被罚嘛。在谷歌,就是把违规成本人为的提高,提高完以后,整个素质也上来了,因为大家开始在乎了。


InfoQ:实际上提高违规成本之后,下面的开发者就会主动的或者被迫自己提升,修复错误?


Shin:对。开发者被提升了。


InfoQ:您认为一款好的静态代码分析工具应该具备哪些要素?


Shin:第一个,他找出来的错要靠谱。对吧?


InfoQ:对。


Shin:你 10 个里面,有 9 个是假的,我就不看了。第二个要快,给你一个静态代码分析的 Request,结果一跑,跑了两个小时,我就没兴趣了。对吧?


InfoQ:是的。


Shin:第三个叫做容易用。如果总要折腾半天启动一个静态扫描工具,那多一事不如少一事,对吧?如果说这个开发环境都已经整合好了,每次编译的时候就开始自动扫描,那是最省事的,做到这一点就可以用了。当然,最后一个是便宜。(对于这一点),我个人就持不同的观点。你应该把它想成说,我把我的品质提升了以后,我的工作比较容易被认可,我公司发布的产品退货率降低了,大家使用方便又满意,不像我现在点个菜点半天,点不出来,不知道哪里出了错。所以品质的问题,我觉得小程序是一个好事情,大家开始重视程序设计的好坏是有差别的,性能好坏是有差别的,因为他还是感觉得到的嘛,所以就希望说这一连串的改变能够往好的方向发展。我相信是会往好的方向发展。


InfoQ:除了提到的静态代码分析工具,企业还可以采取哪些措施来提升自己的软件质量和安全?


Shin:我用 GDPR 来做例子,你要把 GDPR 做对。第一个,你内部要成立一个质量监控的团队。


这个团队主要的工作不是当警察,而是要提出一个方案,怎么样让软件的质量能够持续往上提升,那这种方案必须包含几个要素,你从什么角度来评估,能够量化的评估方法,量化的结果是有一个自动化的机制,而不是人为的机制,自动化(自动)把那个数据给收集起来,不能是我要量化这个机制,所以大家努力手动地去把这个数据给弄出来,那是骗人的。自动化机制弄完了以后,有了数字以后,你要开始(有)监控这个机制,而且要每天监控,监控发现它的那个取向是变好了还是变坏了。当变坏的时候,要有人进去研究为什么变坏了,要(有)调整的机制,所以这是一个完整的循环,你调整的时候就回到头了。规范这个机制,我量化什么东西,我要怎么样自动化,不断地往前转,所以好的团队这个软件的质量跟做设计意见是一样的,你一定是一个完整的循环,而且这个循环的时间越短越好,所以很多人就说你敏捷开发,可是大家误会了敏捷开发里面最重要的精神是,你要在这个机制里面不断地调整你的工作方法,不断调整你监控质量的方法。因为敏捷开发变成只是说我短、平、快了的话,那就失去你原来的初衷了。GDPR,这就让我想到我在 YouTube 上面看过一个影片,谷歌在这个影片来介绍它的安全管控是怎么管的,因为大家都很在意说我个人隐私的数据是不是在报废的磁盘里面,会有些人收走你的磁盘,然后复原你的数据,所以谷歌做了一个磁盘销毁的工厂,磁盘销毁工厂里面管控到什么地步?只有两个人可以进去,其他人不准进去。


InfoQ:两个人?


Shin:只有这两个人,然后是严格控管的,周围的人可以去参观,但只能到外面一层,隔着一层玻璃看里面销毁的人在干什么,后面还有两层的管理措施,第一层进去的人得看他的 ID,第二层进去的人得有点像 bar code(条形码)一样去扫,第三层要看你的虹膜。


InfoQ:生物识别吗?


Shin:生物识别,然后经过了那三层,几乎是你没有被允许进去的人,你是进不去的,每一层之间都是铁丝网,很厚的墙,不是玻璃墙,它就规范了我要怎么样来管控隐私的管理,而且它实现的时候是每一层的这个管理,它是都有记录的,都可以随时回放说今天某某人几点几分来了以后,我这个监控可以看到。所以不只是一个管理的机制,还要实现出来,而且要能够取信于人,而且可以重复实现的流程。讲完以后,大家就很惊讶说还能做成这样,费用很高,可是你不做这个的话,你就准备付出代价跟碰到一起什么时候的问题。


InfoQ:您在鉴释负责面向 DevOps 的静态代码分析工具。现在,有很多新的理念,比如 DevOps 或者 SDL(安全开发生命周期)。与传统相比,静态代码分析有哪些新的变化?


Shin:变化就是原来十几、二十年前,一个 Release 是 6 个月,后来变成 3 个月,现在通常是 2 到 3 周,这是第一个 Release 的 frequency。另外一个变化是微服务,原来是一个大应用切切切,切成几十个、几百个小应用,然后每个小应用都独立的往云上面 deploy(部署)。这最有名的例子是美国的 Netflix,有个影片就介绍说,它大概现在有 500 个 Micro Service(微服务),每天 deploy(部署)到亚马逊云的这个次数大概在 200 次以上,而每个微服务都由一个开发人员负责。那你想一想,如果说我要把这个东西做到从开发到 deploy(部署)都是我一个人负责的时候,那从我的角度而言,我肯定是每次编译就直接分析一次了,从这个地方才管控,你要等到我需要 Launch(发布)前再去测试的时候,我还得往回找,过去通常是两周会有一个发布嘛,但每个开发人员他可能手上只有 3 到 4 个微服务,事实上他从开始改动到真正发布时通常是 2 周的时间,如果说他后期才去找错就太慢了,太花时间了,在那种高效的环境里面,别人都是他这一个礼拜搞个两次,我自己搞一次。


InfoQ:实际上,他把这个动作前置了。


Shin:所有的(动作)都是前置的。


InfoQ:就是随时编译,随时测试,是吧?


Shin:是。


静态代码分析工具的发展方向


InfoQ:在你看来,未来,静态代码分析工具会朝哪一个方向发展?


Shin:2017 年,图灵奖得主是前斯坦福校长约翰·汉尼斯和前伯克利大学的大卫·帕特森。在他们得奖的时候,主办方举办了一个活动,就是让他们上课,参会的人上了一个半小时的课。在课上,他们讲了一个重要的观点,


未来十年,摩尔定律要结束了,未来十年的 IT 行业往前走是什么样子,那我就用这个东西来接他们的话。我们做软件的人不应该只看现在,而是要看未来三年、五年甚至十年的时候,这个 IT 世界的格局是怎么样的。我们从那个角度来看这件事情的时候,他们两位老先生提出的观点就是说,未来的软件世界是软硬共构,软件来决定硬件要什么,就像我要做 AI 的应用软件决定了谷歌那个 TPU 是什么样的结构,根据它的算法来决定其硬件结构。未来,这种硬件结构会越来越多。也就是说,未来的整个软件开发过程仍然是各种各样的语言,而且语言会越来越多,多出来的东西是针对这些硬件发明了新语言,那它写这个程序的时候,这种算法它能在我写一次以后,最好的是所有的 AI 芯片的都可以跑我写的这些应用,对吧?那也就是说,我底下会有各种各样的硬件环境,我上面会有各种各样的语言,那我们这个静态分析就好玩了,对吧?你可以想像得到,我这个手机,大家可以想像说我在支付宝用人脸识别。未来,人脸识别里面的这个芯片可能是这家做的,可能另外一个手机的是那家做的,那我不能这家写一个版本,那家写一个版本,我仍然希望就是同一个软件最好是小程序,那小程序里面会不会有安全问题?那肯定有,随着硬件越来越多,在硬件层次的安全问题也越来越多,所以我认为我们这个静态分析未来要经由 IAST,就是插桩的方式,并且在硬件的层次上能做到保护的工作。我刚才讲的 detect\correct\protect,第三个就是保护,我要保护客户的数据、金钱,而且是在各种各样的硬件环境里,这是我们未来面临的挑战,这样复杂庞大的问题,但是如果说大家不重视这件事情,可以想像得到,最后的情况就是咱们某位领导几点几分上厕所,美国的国家安全局都知道,那就很恐怖了。


InfoQ:确实。


Shin:你不可能不用的。那除非说每个领导都做一个国家特制的硬件,那国家特制就更需要用我们的软件了,要保证里头美国的情报单位没法穿透。


InfoQ:所以现在强调软件、硬件的自主可控。


Shin:自主可控,这是一件大问题,大家都觉得可以自主、可以可控,但是我认为大家不要太乐观,要花最少 3 年到 5 年的时间,勉勉强强可以说我有可能自主可控,要记住这个丛林里面有哪些东西是第一步。


InfoQ:然后,接下来第二步呢?


Shin:然后修正,找出来以后要修正,修正完了以后要能够自动 protect,或者更重要的是能够 prevent,要避免开发人员把 bug 给放进去,这是一个必须要走的路,不然的话,讲的都是虚的。


云原生会给软件开发带来哪些新变化?


InfoQ:我们看到,应用的一个发展趋势是从本地往云上迁移,现在也有一些企业讲云原生,比如在云上进行部署和开发测试。在您看来,这种云原生的应用,它会给软件开发带来哪些新的变化?


Shin:我们的团队此时此刻就在搞云原生,把我们原来在私有服务器运行的单体应用把它拆解,然后往云上面搬,所以从我个人的角度,为什么会选择这个方向?其实原则非常简单,因为你真的要把这个东西不用云原生而自己去搭建云给我的那些服务的话,第一个我得搭建很多很复杂的环境。


比如 google native,一个人不够,你要把 google native 跑起来至少两个人,还有各种各样的,比如说卡夫卡,你不可能说我没有雇人去管 ZooKeeper、卡夫卡(Kafka),要配置的人员数量太多了,你不如就用它们(提供)的,这是第一个成本的问题。第二个是人员素质很难维护,你去哪里雇那么多优秀的人。对吧?然后,第三个就是云原生它有一个叫做 lambda function,我使用的时候才付费。


你不能做到这个使用才付费的时候,你就去租那个虚拟机,那个很花钱的,假设我要同时服务一千个、一万个源代码扫描,假设我真的是很成功,那每一分钟都在烧钱。


InfoQ:确实。


Shin:所以我个人觉得云原生是不可避免的,那需要做哪些改变?就是需要架构重构,就是我们搞架构的人干这种事情,怎么样切,切到把那个刚刚猴子、香蕉、丛林的事儿拿过来做比喻,我要把它切出来,我要香蕉就给我香蕉。


InfoQ:我之前看到,Uber 的技术人员发了一条消息,他们从单体变成微服务,后来又变成宏服务。原本,他们想利用微服务的优势,但是真正采用微服务后,这个事情变得更加复杂。从架构重构或架构演进的角度来说,这个东西到底该怎么切?


Shin:这个东西光靠一两个人的脑力是不够的,你必须要有一些工具,像谷歌有很多内部的工具是没有开源的,它管理每个这些微服务之间的关系,光管理这个关系,你就要把它弄清楚是一个独立的工具,有一点像这个大编制的交响乐团,120 个人、120 个乐器,各司其职,你需要有一个指挥家在那儿搞。所以这个东西避免不了,那指挥家主要的责任就是啥?你什么时候把不同的人带进来,然后进来的时候你要怎么样合乎整个音乐的那个感觉、气势,所以 Orchestration(编排)很重要。下一个就是监控,它也很重要。我每一个人、每个乐器的意义,在交响音乐厅里面,你会看到有麦克风,其实麦克风一方面是收音,一方面是监控,它主要是看看说这个场子里面做出来的效果是达到我原来希望的效果。当然,现在的指挥家很多都很厉害,不需要戴耳机,但是你看现在所有大的电视节目唱歌的人也戴耳机,后台都有耳机,耳机是什么?监控,那监控的时候,第三个就是你要能实时的把问题找出来,实时找问题就是好的系统,它用上 AI 的时候,把这些程序员正常的 pattern(模式)它能够掌握下来,然后用这个去预测未来,对吧?然后预测你如何调度,因为你不可能去掌握无限的资源,你肯定还是要有预算的,Uber 也是如此,他们很清楚需要知道拿来多少辆车,有多少辆车今天上线,每一部上线要能够彼此管控这个 user expectations(用户期望),对吧?我告诉你说要几分钟到达你那儿,我最好准一点,不然的话,人家就跑去坐 Lyft 了,不坐 Uber 了。


InfoQ:对。


Shin:所以是各个角度的问题,一个综合掌控的问题,但是上云这个事是不可避免的,因为软件复杂到这种地步,你真的是整个 life cycle(生命周期)都要照看好,想到都恐怖,你做个软件要花很多人力。


中外软件产业的差异


InfoQ:在您看来,中国与国外的软件产业相比,它们有哪些不同?


Shin:我觉得最大的不同是,在我这个年纪的人还在写代码的,在中国大概只有我跟我的合伙人了。在美国,像我这种人有很多,比如说当年发明 C 语言的这个人,一直到去世之前,他都在写代码,这是第一个最大的不同点。第二个最大的不同点是美国,他们(程序员)写代码的时候,他会从根看起,从应用一直到系统硬件,一路看到底。


InfoQ:从上到下一直看到底?


Shin:看穿,看透。所以美国能够搞出深度神经网络(DNN)、卷积神经网络(CNN)这种机器学习(技术)。深度学习的算法是加拿大人搞的,但是如果没有美国英伟达搞出的 CUDA 这个算法平台环境的话,软件也不容易起来。所以,他们是硬件软件、软件硬件来来回回折腾。但是在中国,大家习惯于有啥干啥,到现在都还是这个心态。


InfoQ:就是说模仿是吧?


Shin:他当老二。


InfoQ:有一本叫《红皇后的奔跑者》,是美国的一位大学教授参观中国后写的,他指出中国的创新,就像你刚才说的,当老二(模仿)。


Shin:但是有例外,小程序是真的中国独有的创新。因为写个应用,改一点东西就能在两个平台上跑起来。所以说中国做软件跟美国的不同点是美国人经常会努力地去了解,从上到下,即使是普通程序员,他都会努力去了解,这个软件到底要解决什么问题。而在国内,底层写代码的人,基本上都是屁股决定脑袋,少有追根究底的。


InfoQ:相当于他是一个割裂的状态。


Shin:在美国从上到下是不断巡回的,来来回回折腾的,在国内就是上面的一个指令,下面就照干,上面的指令错了,底下就弄错了,但还好市场够大,所以大家都忍耐着。


软件开发行业的变化


InfoQ:您一直在一线写代码。与以前相比,软件开发这个行业现在有哪些变化?


Shin:我看的都是系统层级的代码,编译器跟操作系统为主,所以编译器和操作系统这些东西其实比较独立,比较不求人,不像现在的应用,它必须要天天看客户反馈怎么样,然后很快地做机动的调整,所以系统软件是没有变化的,但是我讲系统软件,大家都不会有感觉,因为国内不做系统软件,国内都是做应用软件,倒推几十年前,应用软件跟现在的应用软件当然也不一样,其实你以前刚开始的时候,80 年代大家努力地是办公室的人,把你这个 Power Point/Word 全部电子化,在那之前,你要做文件排版就一家公司搞,美国的一家公司已经倒闭了,叫王安公司(Wang Computer)。


InfoQ:这个公司以前听过。


Shin:当年,所有的报纸都是用它排版的。那个时候,排版是一件大事,比如现在的排版,大家说那没有什么了不起嘛,比如说 Word 或者谷歌 Doc 都可以搞定,80 年代是办公室自动化的,90 年代、2000 年是干啥的?看电视的、看视频的,所有的东西都绕着视频转,所以应用是不一样的,然后,电脑的复杂度也不一样。我第一次玩硬盘是 1984 年。我家里还有一台电脑是苹果的 lisa,全世界只有 4 百台,我们家里就有一台。


InfoQ:那现在都是古董级了。


Shin:是古董,我相信中国大概没有。你知道那个时候,硬盘有多大?这么大,这么厚,你猜有多大?里面能存多少数据?


InfoQ:几 KB?


Shin:没有了,20 兆,体积好大。1997 年的时候,我们同事跟我吹牛,他竟然拿到一个硬盘,大概有这么大、这么薄,很得意,他说全公司只有 5 个,我拿到了一个,2G。


InfoQ:现在电脑都 500G 了


Shin:我就是这个意思,所以现在的软件都是可以随便就抓一个丛林进我的电脑里面,这是我的软件,那个时候硬盘只有 200 兆、20 兆的时候,谁敢弄一个丛林进我的电脑?那多贵,所以那个时候的软件跟现在的软件完全不同,现在是硬件不值钱,所以努力用,那个时候的软件是锱铢必较,那你锱铢必较的人训练出来跟现代的软件工程师真不同。


Java、C++与 Rust


InfoQ:在写代码的时候,您用哪一种语言多一点?Java、C++还是 Python、Rust?


Shin:我是(用 C++的)。因为我第一次写 C++是 1988 年。我对 Java 的印象就是高产出,但不高效能,因为它是动态语言,所以我们以前做过性能分析,如果说你不做任何的优化,Java 的性能是 C++的十二分之一。


然后,另一个值得注意的事情是,Java 的 Memory 管理,它是 Manage 的 Memory,所以你不需要做 new 和 delete。在用 C++时,我得自己去做这些事,Java 不用,Java 帮你搞定,可是事实是它搞不定,90%的安卓手机。安卓是用 Java 写的。


InfoQ:是的


Shin:你一个礼拜不重启就慢的像蜗牛一样,为什么?因为里面在不断地跑 garbage collection,它重新把那个不用的 Memory 收回来,简称 GC。这 GC 一旦跑起来,机器就不反应了,他们叫卡顿,手机卡顿了,就得重启。但是苹果,我就不那么需要重启。我通常就是看着烦了,没事干,重启一下,绝对不是因为性能的缘故。我是(用)C++的人。


讲到 C++,我就会说不完,因为在 88 年底,我自己写了一个类似于 Java 的一个 interpreter,解释级的 C++,用它来做 UI。当时我按一个键,就像现在我们在手机上按一个键,3 秒钟之后反应回来了,你知道那个时候机器有多慢,0.5 个 MegaHz(MHz),我们现在机器随便都是 2 个 GHz,1 个 GHz 是 1000 个 MHz,所以我那个时候机器是现在手机两千分之一倍的速度,现在的手机随便都是 6 个核。88 年那个时候是 1 个核,对吧?因为 Java 出来的是 1996 年。出来的时候,那个机器大概是 50 个 MHz,所以是我在做 C++解释器时候的一百倍的速度,所以 Java 可以跑了。我敢讲,这个 GC 的问题,未来也慢慢就不是问题了。97 年的时候,同事还跟我吹牛,他 2 个 GB 的硬盘就是这么大,现在随便就是几百 GB 的 SSD。


InfoQ:确实,发展特别快


Shin:所以这个资源无限的扩张,所以大家很 happy,就是用 Java 写,谁都能写代码了。这几年,有个新的语言,Rust,更有意思了。Rust 把这个 Memory 管起来了,设计 Rust 的人说这个 C++速度好,咱们用 C++的速度,但是我们要有类似于 Java 的这个 memory 管理,就是他发明了这个 memory ownership 的机制,你把这规则看懂了,才写得了代码,可以编得过去,95%的 Java 开发人员搞不过那一关,所以这门槛直接在编程人员上筛选。大家都说用 Rust 很保险,不是的,是因为语言本身帮你把人员筛选了,搞不定的人就不能写 Rust,写不了。但是,你如果能够搞定 Rust 这一个规则的时候,保证你写 C++也没有任何的问题,重点就在这儿。所以它是在人员筛选上下手,我刚刚已经讲完了三个编程语言,还有一个值得一提,就是 Go?我不建议用 GO,全中国都在疯 Go,我说小心,如果说在国内有这些重要的系统级的软件是用 Go 写的,谷歌只要下令停供,你怎么办?


InfoQ:实际上,在云原生热潮下,Go 语言非常受欢迎,很多应用是用 Go 写的。


Shin:大家说用 Go 好。


InfoQ:Go 语言可能因中美冲突面临“断供”,是吧?


Shin:人都以为 Go 多好,可不知道 Go 的性能多差啊!我是搞性能的人,它现在是因为随便的机器都是 2G 的 Clock rate(时钟频率),然后 6 个核,所以你不觉得,Go 也是用 manage memory,跟 Java 一样,Go 也会卡顿的,它也有 GC 的,大家不知道吧?有多少人知道 Go 也有 GC?


我跟 Go 的人开过会,了解 Go 这个语言 manage memory 不太好,结果没想到 Go 在中国那么热门。在 Go 出来前,谷歌内部写 Server 端是不准用 Java 的,手机端的安卓是用 Java 的,Server 端是不准的,一律是 C++和 Python,然后设计 Go 出来的时候,设计者是希望把 Google 内部用 Python 写的代码用 Go 取代,因为 Python 本身是有一些性能上跟安全上的问题的。


InfoQ:Python 比较慢,是吧?


Shin:Python 的速度是 C 的四十七分之一。Python 比 Java 慢,因为没有人会去做 Python 的 JIT, Go 设计的目标就是取代 Python,它只要比 Python 快就行了,所以它强调的是我编译的时候速度快到没感觉,然后就可以开始跑了,因为 Python 是解释性语言,你不需要编译,直接就跑了,说我使用时感觉上像 Python,速度又要比 Python 快,但是要不要比 Java 快?他们说不必要,Java 不是我们要取代的对象。然后,国内不知道的人说 Go 就是谷歌推的嘛,谷歌发明的东西还能差吗?性能还能差吗?其实性能比 Java 还差,尤其是里头还有 GC,因为性能实在太差了,因此 GC 了,也不知道。


给中国开发者的建议


InfoQ:写了这么多年代码,如果让你给他们一些建议,你有哪些建议?


Shin:我觉得第一个最重要的事情,所有的开发者应该要有的,是一个对自己纪律的要求。


InfoQ:自律,是吧?


Shin:Self-discipline,即自我管理的要求。我给自己定的目标必须要精确,我几十年写代码有个原则,我当天写的代码,当天一定测试完毕,测试结果自己写。我明天来了,我就知道那个活干完了,我从来不担心说昨天干的活有 bug,我测试用例是测试到每个执行路径都有 cover,而且是机动的。譬如说两个 if-then-else,一共有 4 个路径组合,我测试用例一定把 4 个 pass 都测完了,不会遗漏任何一个,这是 discipline(自律,自我要求)。没有这个对自我要求的纪律是做不到这个的。那要做到这一点其实说难也不难,说简单也不简单。你不能有撞钟的心态,我这是一份薪水,时间到了,我上班,时间到了,我下班,做的好不好那是老板的事,所以第二个事情是你要自我要求,假设公司自己开的,要做到什么程度,自己才会满意,对吧?


InfoQ:对。


Shin:第三个,你要突破,自我突破,我尽量做一点好的,这个月比上个月,我尽量比去年好,可以不断地往上走,事实上是无限的。


InfoQ:国内有种说法,程序员 35 岁没干到管理或高级软件工程师,就没什么前途了。对开发者来说,他应该怎样不断精进自己的技能,提高自己软件开发的能力?


Shin:这是结果论,我最坏的假设是某某人他 21、22 岁大学毕业,到 35 岁有 14 年,他的程度维持在他大学刚毕业的时候,这样会被淘汰,换成你是老板也会淘汰他。我一定淘汰他:第一个你知识跟不上现代了,第二个你的体力没有现在年轻人好了,第三个你脑子没年轻人快了,我还留你干嘛。所以大家要有危机意识,不是说 35 岁,我就要被淘汰了,不是的,你要今年比去年好,不要多,今年比去年好 30%,3 年就 twice as good。


InfoQ:每年都有进步,是吧?


Shin:六年就是四倍的好,那 35 岁怎么会被淘汰呢?求你留下来都来不及,还淘汰你?疯子老板才会做这种事情,所以给自己定一个目标,本周比上周好、今年比去年好,自己定目标,看你的能力,看你愿意投多少资源进去,但是 0 是不可接受的。有一个最起码的条件,你每年要评估自己,我去年毕业了,我一定要胜过今年毕业的人,我做的一件事如果不能比他好,那对不起自己。一定要对得起自己,那我要怎么样达到说我今年比去年好,然后我比今年刚毕业的人好,自己评估一下,我每年要往前走 10%、20%、30%,自己定目标嘛。你开始定了目标以后,你就会想说那我怎么样评估我是比较变好的,当你想到我怎么样评估自己变好的时候,你自然而然会想到,我怎么样量化?


InfoQ:对。


Shin:量化是做所有的工作,如何量化把它想清楚是最重要的一件事情,所以说是给自己定,而不是老师给你定,而是自己给自己定,所以这些都是自我要求,自我要求一定要做得到。自我要求做不到,我讲的进步也就不会发生,那就等 35 岁被淘汰。


2020 年 12 月 17 日 14:331824
用户头像
万佳 InfoQ编辑

发布了 551 篇内容, 共 202.5 次阅读, 收获喜欢 1382 次。

关注

评论

发布
暂无评论
发现更多内容

反垄断之下 区块链迎来新生?

CECBC区块链专委会

区块链

JustSwap交易所系统APP开发|JustSwap交易所软件开发

开發I852946OIIO

系统开发

领域驱动设计DDD

积极&丧

Android开发全套学习!不同层级的Android开发者的不同行为,学习路线+知识点梳理

欢喜学安卓

android 程序员 面试 移动开发

附PPT丨广东移动智慧中台能力运营实践

dbaplus社群

中台 中台战略

开一个世界末日的脑洞

熊斌

我的世界 生活记录 七日更

毕业三年,如何达到月薪30K?我想跟你聊聊!!

冰河

程序员 程序人生 架构师 升职加薪 提升自我

设计模式【1】-- 单例模式到底几种写法?

秦怀杂货店

设计模式

一直在云上的星空联盟,“真”上云了

亚马逊云科技 (Amazon Web Services)

云计算 AWS

附PPT丨如何构建数据库容器化PaaS

dbaplus社群

数据库 容器化

架构师入门感悟之十

莫问

架构师训练营第五周课后作业

万有引力

星环科技助力商业银行机器学习平台建设

星环科技

FinTech

恐怖:这份Github神仙面试笔记,简直把所有Java知识面试题写出来了

Crud的程序员

Java 架构师 java程序员 java基础

explicit_defaults_for_timestamp 参数详解

Simon

MySQL 七日更

Mybatis【7】-- Mybatis如何知道增删改是否成功执行?

秦怀杂货店

Java mybatis

设计模式【1.1】-- 你想如何破坏单例模式?

秦怀杂货店

设计模式 单例 23种设计模式

字节跳动开源云原生机器学习平台 Klever

字节跳动技术团队

学习 字节跳动

Github标星5.3K,网易云的朋友给我这份339页的Android面经,附赠课程+题库

欢喜学安卓

android 程序员 面试 移动开发

Mybatis【9】-- Mybatis占位符#{}和拼接符${}有什么区别?

秦怀杂货店

mybatis 预编译

记一次由Arthas引起的Metaspace OOM问题

闲鱼技术

Java 阿里巴巴

爱奇艺用户分析平台实践:TB级数据查询秒级返回

dbaplus社群

大数据

“区块链+”产业生态雏形已现 安全监管逐步完善

CECBC区块链专委会

区块链 区块链生态

Angel推荐算法在游戏推荐中的应用

DataFunTalk

学习

安卓开发快速学习!一个小例子彻底搞懂Android的MVP模式到底是什么?面试必问

欢喜学安卓

android 程序员 面试 移动开发

Lambda【1】-- List相关Lambda表达式使用(上篇)

秦怀杂货店

Java Lambda

花火交易所软件开发|花火交易所系统APP开发

开發I852946OIIO

系统开发

字节跳动自研「BVC2.0」视频编码器在 MSU 2020 中获得四项第一

字节跳动技术团队

字节跳动 视频编码

《爱奇艺安全应急响应中心漏洞评分标准2021》来了

爱奇艺技术产品团队

安全 安全漏洞

Mybatis【8】-- Mybatis返回List或者Map以及模糊查询怎么搞?

秦怀杂货店

Java mybatis

LeetCode题解:42. 接雨水,双指针,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

2021 ThoughtWorks 技术雷达峰会

2021 ThoughtWorks 技术雷达峰会

对话鉴释首席架构师刘新铭:程序员不要“做一天和尚撞一天钟”-InfoQ