当前位置:首页 > 互联网
  • 别做大厂的螺丝钉

    职场&认知洞察 丨 作者 / findyi 大厂是很多职场人追求的目标。 薪资高、福利好、培训规范、发展空间大、管理规范等等。 这些都是大企业的优势。 但不少人在大厂的发展却陷入了困境。 关于在大厂工作的问题,有一个洋友的问题,分享给大家: “洋哥,我是做地图相关研发工作的,来这家BAT级别大厂10年了。因为舒适和安逸,忽略了能力上的长线发展,最近一次晋升又失败了。已经快40岁了,还是基层员工。最近尝试在跳槽,本以为有大厂光环很容易找到好的职位,却发现根本不是这么回事。我现在非常非常苦恼,请洋哥指点迷津,我到底该怎么办?“ 破解中年危机的方法其实是提前预防。 而不是等到危机发生的时候再去找方法。 所以我给他的建议是:先继续在这家大厂干着,同时开始改变自己,不能再继续当一颗螺丝钉。 虽然我一直建议应届生和经验不多的职场新人,最好能去大厂熏陶下。 但是一些在大厂按部就班,适应维护某些模块的朋友。 很容易陷入一年经验用十年的状况。 随着年纪的增大遇到风吹草动,再转向非常困难。 大厂是培养职场螺丝钉的温床。 工作稳定、分工明确、工具和组件化的程度高。 这样带来的好处是:组织的效率高。 但组织的效率高,并不意味着你能有成长。 亚当斯密在《国富论》里,举了扣针工厂的例子: “一个工人无论如何努力,一天也生产不了20枚扣针,但有了分工之后,经过前后18道工序,每人每天平均可以生产48000枚扣针。这就是专业化分工的高效性。” 任何一家公司,从老板的角度肯定是提高效率、多赚钱。 所以公司必然走向专业化分工,一个工作切成很多块。 每个人都终日重复其中某一块,以提高效率、降低风险和对人的依赖。 越大的公司,这种现象越明显,但是,这对个人发展是灾难性的。 你在大企业里可能成为了一个“人才”,但是,只是企业定制化人才,被体制化了。 就像一颗螺丝钉,尺寸和材质只能用在某一个地方,挪到别处去,根本用不上。 说几点避免成为螺丝钉的破解方法吧。 —  1   — 跳出舒适区 身边有不少在大厂工作多年遭遇天花板的朋友。 有一些想跳到小一点的公司或创业公司去拼一把的,我都会非常支持。 在大厂积累了一定实力,了解了规范的管理、团队运作之后。 去创业公司hold更大的职责,可以高速提升认知和能力。 也算是强迫自己从安逸的环境中走出的一种方式。 人的本能都追求安逸舒适的状态,一旦陷入进去并且适应,其实就陷入了舒适区。 2015年我在360就是这种状态,经过几年的奋斗打拼,部门的产品技术都已经成体系,产品线也趋于稳定。 每天做做管理,跟进点小问题就下班了。 拿着高薪和期权还没多少挑战,相信这种工作很多人会羡慕。 一开始我也觉得很爽,但时间长了突然惊觉我的能力在退化。 于是我很快陷入苦恼之中。 思考半年,我选择了跳出来创业。 虽然最终并没有成功,但也让我积累了商业、产品、运营等能力。 而这些能力,恰好帮助我轻松跨越中年危机,有了更多的职场选择。 站在原地,看不到新世界! —  2   — 重要不紧急的事情 大厂螺丝钉们都有个很大的特点:天天处理重要且紧急的事情。 拿程序员来说:编写业务代码、调试、上线、解决线上BUG。 工期紧起来基本用本能在做事。 能不能留出时间来做重要不紧急的事情很关键。 比如能不能把自己写的代码研究透了? 或者不断重构改善代码质量? 或者引入新的设计模式,在代码设计上下点功夫? 再比如工作外的提升,能不能学习下各种开源源码。 能不能看看日常调用的底层组件究竟是如何实现的? 甚至自己搭建一个,调试运行玩一玩? 做这些事情,短期内可能对工作产出没有任何帮助,也不能让你升职加薪。 做的时候还会感觉到很难进步。 一些真正重要的事情,比如技术上的精进、产品上的积累等等。 一开始都很缓慢没进展,跟蜗牛似的,突然间就如同雄鹰展翅一飞冲天。 说到这里,又要祭出一熟悉的图了: 坚持做「重要不紧急」的事情,直到突变线的来临。 —  3   — 关注其他人做的事 很多读者问过我一个问题:洋哥,你是如何同时掌握技术、产品、运营、商业等能力的呢? 复盘下我的经历,有一个点很重要:在工作中不光要耕好自己的一亩三分地,也要关注其他人在做什么,是怎么做的。 这也分两个层面,第一个是同职能的其他同事,通过了解他们的工作,你可以知道你的「盲区」。 「盲区」很可怕,很多陷入愚昧山峰停滞成长和发展的朋友,很大原因都是因为有大量盲区:不知道自己不知道。 当你知道其他人用不同的方法更高效的解决了问题,你一定会反思改进。 第二个层面是不同职能的同事,你了解他们在做什么,其实是一种高效学习。 比如程序员多和产品聊聊天,了解下交互为什么要这么设计,这个功能究竟满足了什么用户价值。 这会让你不用实际做产品,就具备了一定的产品业务Sense,能快速扩大你的Scope。 具备这种能力会让你的职场发展势如破竹。 很多技术人职场追求的终极目标是担任CTO。 如果一个CTO没有超强的产品业务Sense,极容易成为背锅侠,最终黯然离开。 —  4   — 不设边界,实 现跃迁 在职场,不要给自己设置边界。 可以找直属领导要求更具挑战性、成长性的工作。 也可以主动帮助同事解决问题。 还可以多看书实践优化手头的工作。 张一鸣在刚工作的时候,就从来不给自己设置边界。 看看他对自己第一份工作的自述: “我做完自己的工作后,对于大部分同事的问题,只要我能帮助解决,我都去做。当时 Code Base 中大部分代码我都看过了。新人入职时,只要我有时间,我都给他讲解一遍。通过讲解,我自己也得到成长。所以,我很快从负责一个模块,到负责整个后端系统,一开始带一个小组,后来带一个小部分,再后来带一个大部门。” 在工作中通过不设边界,不断突破舒适区进入学习区。 进而把学习区变成舒适区,这个时候一个小的跃迁就发生了。 无数个小的跃迁之后,大的跃迁随即而来。 这个时候你也就摆脱了螺丝钉的命运。 特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下: 长按订阅更多精彩▼如有收获,点个在看,诚挚感谢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-25 关键词: 程序员 互联网

  • 爱奇艺视频精彩度分析算法及应用

    分享嘉宾:刘祁跃 爱奇艺 科学家 编辑整理:龚云荷 出品平台:DataFunTalk 导读: 视频是爱奇艺的核心内容,视频内容的精彩度分析,不仅关系着视频的分发,也关系着视频相关广告的投放等,比如能否将广告放在非常吸引人的点位上。 所以我们非常关注能否分析出有吸引力的内容,甚至根据分析的结果,二次创造出有吸引力的内容。 对于吸引力,我们在思考什么是非常重要的。 这里列出三点: 第一个是视频质量,比如是否清晰、镜头是否晃动、是否有无意义的内容,这是基础的质量问题。 第二个是视频美学,比如色彩是否优美,构图是否好,光线明暗对比度是否好。 当然,有了质量和美学还不足以说明视频是否有吸引力,大部分的视频是靠情节取胜,也就是靠视频的内容去吸引人,不管是长视频的电视剧、电影、动漫,还是横版短视频和竖版小视频,都包含着当前视频是何人何地发生何事,由这样的内容反映精彩度。精彩度是视频吸引力的第三点,也是最重要的一点。 01 方法及整体框架 1. 如何识别精彩 这就促使我们去思考,如何分析内容的精彩度,这里有几个维度:第一,内容标签,比如打斗等偏感官层面的信息或者是浪漫等偏高层语义方面的信息,这需要理解视频内容。第二方面是程度等级,比如说打斗,如果是武林高手之间的对决,相比于我们普通人之间打斗会更精彩,所以需要一个分级打分机制。还有一些信息影响到用户对视频的喜好,比如对明星、IP、剧集等的喜爱,都会影响用户对其精彩度的判断。前面这3点是人们对于视频精彩度的一个理性分析,但实际上精彩度还是较主观的看法,同一个视频,有些人觉得精彩,有些人则不觉得。一些上映之后成为收视率“黑马”的作品,在上映之前,人们没有预期到其足够精彩,上线之后,却成为爆款,这体现了对精彩度主观判断的局限性,因此我们也要考虑视频上线后的用户反馈。比如用户的播放、弹幕等行为,有些视频片段用户会反复播放,另一些则会被跳过。我们希望通过以上几个方面,构建对于精彩度的认知。 2. 精彩度分析整体技术框架 由此,我们形成如图的精彩度分析方案,该方案的适用对象较广泛,不管是对完整的剧集,还是简短的花絮,都可以适用,我们这里聚焦于对电影电视剧的片段做分析。影视剧的整体精彩度比较宏观,受参演明星,改编的小说等已知因素的影响,所以通过算法对整体做精彩度分析收益相对较小。当下我们更关注,对长视频局部剪辑片段的打分。精彩的局部片段的识别,有助于启发创作者对于局部精彩视频的思考,有利于后续创作的提升。同时,精彩片段的识别,有助于二次传播、碎片化时间的消费,以及广告的投放等。如框图所示,我们输入的是视频片段,然后进行多模态的视频特征提取,接下来分两步,一个是基于GCN的弱监督模型,另一个是基于多任务学习的监督模型。 02 视频精彩度分析算法 1. 精彩度监督模型 对于精彩度的监督模型,首先需要标注人员对视频精彩度进行打分。考虑到数据的复杂性,会充分利用多模态和时序关系去提取信息。操作中会有一些具体技巧,比如由于其标注主观性比较强,会进行噪声建模,从回归分数变成一个拟合分布。另外,评分和标签是高度相关性的,因此可以通过多模型、多任务学习的方式来进行。 2. 不同模型提取特征性能对比 这张图显示了采用不同的模型提取特征,对最终精彩度输出的影响。最初的方法是针对图片信息采取2D的CNN,再去对帧级别feature进行融合;接着考虑由时序上的3D卷积模型来提特征;然后尝试根据预训练模型来进行微调;再利用视觉+音频的多模态的信息进一步提升。 3. 精彩度分数预测 监督模型的一个分支是精彩度分数预测。对于精彩度分数,会先做人工标注,但是因为主观性偏向非常强,所以噪声较大,可信度并不高。当标注为某一个分数,那它很大概率会是以这个分数为均值的正态或偏正态分布。比如标注分数是六分,那该视频可能很大的概率是六分,但也可能会小一些的概率是五分或七分。为减少噪声影响,会对噪声做一个建模,直观的假设,将标注的分数看做一个正态分布的均值。为了满足概率积分的要求,实际上设计了一个偏正态分布。分布的方差通过理论分析+实验,来确定一个比较合适的值。有了这个分布,对于分数的回归,可以变成一个类似分类的任务,对于每一个离散值给出一个概率,这样得到对分布的预测,从而加权得到最终预测的分数。采取该策略后,我们发现对于噪声比较大的主观性标注任务还是有意义的,其它一些图片回归任务我们也用了类似方法,取得了不错的效果。 4. 看点多标签模型 接下来看第二点,关于视频内容的看点多标签。比如像打斗、爆炸,都是比较有意思的标签,可能是会吸引人的。对于不同类型的视频,看点的标签是不一样的。比如说对于偶像片来说,浪漫的标签可能非常有吸引力;对于动作片来说,可能飙车、打斗、枪战等很有吸引力。多标签模型,在近几年各领域都广泛关注,包括短视频标签、图片多标签、文本多标签等。多标签的难点,是如何对同样的信息去生成不同的标签,针对这个问题会有三个方案。第一种是利用信息不同区域对应不同的标签,可以类比目标检测。即划分图像的不同区域,用其本身及周边的信息,去预测该区域的一个标签。那第二个是层次的关系,比如从画面视觉内容来说,一男一女在西餐厅吃烛光晚餐,则需要进行性别识别、场景识别、目标检测等,同时它是一个浪漫的约会场景,所以还可以推理出上层的标签。第三个要考虑的点,是标签之间的依赖关系,有一些标签很可能经常共同出现,比如说有海滩和阳光。有一些标签之间不太容易共现,比如手机跟古装片,可能是互斥关系。当然如果能识别这是一个穿越片,就可认为这两个标签共现是比较和谐的。在很多看点多标签之间,有这种互相依赖的关系,如何去表达标签的关系有很多方式,比如说CNN和RNN结合,通过RNN去显示地表达标签之间的依赖。那其它一些方式,比如通过标签embedding,希望其去影响分类器,而对于这个embedding,可能会通过图的拓扑结构,根据相似的邻域标签信息来修改embedding,从而让这个embedding包含标签之间的关系,再将这个embedding以某种方式去影响分类器。还有一种方式,就是训练时找到一个嵌入的空间,把ground truth的多标签投射到嵌入空间,利用多标签去生成一个feature,同时对于待处理的数据也生成一个feature,要求这两个feature要尽可能接近,之间的某种距离可以作为loss之一。这样,嵌入空间的音视频feature,即表达了多标签的关系,可以认为是对多标签的编码,而后续的分类过程,就是对多标签的解码。 5. 多任务学习模型 评分和看点标签这两个模型高度相关,所以用了多任务学习。因为业务有非常多的需求,各需求之间往往有相关性,经常存在多任务学习的可能性。另外,海量数据下如何节省资源,也是非常现实的需求。如果我们通过多任务学习能够降低资源消耗,更好的体现相关性,甚至还有可能提升指标,那会非常有动力去做多任务学习。我们现在的架构,底层共享网络,上层建立评分和标签网络。训练策略方面没有标准化方式,采取一些经验性的方式,动态调节权重,比如根据每一路分支loss下降的情况进行调整,或是动态分析每路分支的运行情况,修改训练频次,保持一致的收敛速度。 6. 弱监督模型 接下来我们再看一下,弱监督模型这一块。我们有很多用户观影行为数据,是否可用于拟合对分数的标注。比如观看行为,观看次数越高,一般也越精彩。但是不同视频本身热度不一样,同一个视频的不同部分,单纯看播放量也不公平,因为很多用户不会看完整个视频,一般前面的片段播放量会更高。所以,直接将用户行为作为精彩度的度量,虽然相对于人工标注的分数更能体现用户的实际偏好,但还是存在非常多的噪声。为了减少噪声影响,要做很多数据预处理,比如尽量避免用区分度不大的数据。除了关心绝对精彩度,也关心相对大小,即一个视频中,哪些内容相对其余部分更有吸引力。我们往往会从一个视频当中,筛选相对精彩的内容,去做二次创作、投放广告等。在这样的诉求下,可以采用Ranking思想去设计Loss。因为噪声较大,会给label计算置信度,比如可以用相似的样本来做平滑。这里我们还可以利用图,设计图卷积过滤高频信息更新样本feature,实现更好的聚类,并利用更新后的相近节点来修改样本置信度,最终有效提升弱监督模型效果。 03 应用 1. 前情提要 前情提要是精彩度相关的一个应用,运用算法对每一集识别出精彩片段,通过一定策略剪辑。虽然前景提要本身是一个用户产品,但可以在上面投放广告,并且处于片头这个黄金位置,实现了很好的商业价值。 2. 拆条 第二个应用是长视频拆条。做一个比较好的拆条,要从长视频当中选出比较精彩的部分,同时满足切分方式的合理性。可以方便投放在站内或者是站外的各种渠道上,这样可利用用户的碎片化时间,一方面形成对短内容的消费,一方面也能够起到短带长的作用。所以要做拆条的话,不仅仅需要对内容本身的理解,也需要对精彩度做分析。 3. 自动生成封面 智能封面图生成,目前线上的影视剧封面,采用自动生成动态图的方式。对视频中精彩片段进行打分,并需要保证片段的多样性和代表性。对于图片也会有精彩度、美学等分析。不管是静态封面图还是动态封面图,都可以生成多个,然后去做个性化的分发,并通过线上的反馈来调整生成封面图的策略。 4. 片段打分 还有一个应用,是直接对片段的精彩度打分,有利于冷启动阶段的分发;也能给创作者提供参考。 04 总结和展望 总结一下,当大家思考内容平台的时候,会非常关注内容是否精彩。针对精彩度分析,不只是一个单一的技术,更是一个综合性的解决策略。可能会利用各种各样的垂直算法、产品策略,工程策略等,最终形成可行方案。精彩度方案已被广泛应用,并会从质量和效率两个方面的提升来做评价。由于精彩度分析任务的特点,如需要用到海量数据、具有较强主观性、有很多用户行为数据等,会牵涉到很多技术方向,像弱监督、多任务、多标签、图等等。此类偏主观的分析,用户标准、用户行为以及先验的外部信息,这三个维度都非常重要。 后续的展望,第一方面是在特征提取上,尽量去融合更多的信息,包括文本的信息,比如台词、弹幕等。第二个是在模型上,比如怎么通过半监督的方式,把有标注和无标注的数据,放到一个统一框架中来。第三点是如何利用各种垂直识别,不管是底层的识别,还是偏上层的推理形成高层语义,需要能把这些信息利用起来,从而知道为什么精彩,作出可解释的精彩度评价。 嘉宾介绍: 刘祁跃 爱奇艺 | 科学家 刘祁跃,爱奇艺科学家,智能平台部视频分析组负责人。负责对视频内容的理解和生成,并应用到广告、创作、分发等业务。 特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下: 长按订阅更多精彩▼如有收获,点个在看,诚挚感谢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-25 关键词: 视频 互联网

  • 一个技术总监的忠告:精通那么多技术为何还是做不好一个项目?

    编写高质量可维护的代码既是程序员的基本修养,也是能决定项目成败的关键因素,本文试图总结出问题项目普遍存在的共性问题并给出相应的解决方案。 1. 程序员的宿命? 程序员的职业生涯中难免遇到烂项目,有些项目是你加入时已经烂了,有些是自己从头开始亲手做成了烂项目,有些是从里到外的烂,有些是表面光鲜等你深入进去发现是个“焦油坑”,有些是此时还没烂但是已经出现问题征兆走在了腐烂的路上。 国内基本上是这样,国外情况我了解不多,不过从英文社区和技术媒体上老外同行的抱怨程度看,应该是差不多的,虽然整体素质可能更高,但是也因更久的信息化而积累了更多问题。毕竟“焦油坑、Shit_Mountain 屎山”这些舶来的术语不是无缘无故被发明出来的。 Any way,这大概就是我们这个行业的宿命——要么改行,要么就是与烂项目烂代码长相伴。就像宇宙的“熵增加定律”一样: 孤立系统的一切自发过程均向着令其状态更无序的方向发展,如果要使系统恢复到原先的有序状态是不可能的,除非外界对它做功。 面对这宿命的阴影,有些人认命了麻木了,逐渐对这个行业失去热情。 那些不认命的选择与之抗争,但是地上并没有路,当年软件危机的阴云也从未真正散去,人月神话仍然是神话,于是人们做出了各自不同的判断和尝试: 掀桌子另起炉灶派: 很多人把项目做烂的原因归咎于项目前期的基础没打好、需求不稳定一路打补丁、前面的架构师和程序员留下的烂摊子难以收拾。 他们要么没有信心去收拾烂摊子,要么觉得这是费力不讨好,于是要放弃掉项目,寄希望于出现一个机会能重头再来。 但是他们对于如何避免重蹈覆辙、做出另一个烂项目是没有把握也没有深入思考的,只是盲目乐观的认为自己比前任更高明。 激进改革派: 这个派别把原因归结于烂项目当初没有采用正确的编程语言、最新最强大的技术栈或工具。 他们中一部分人也想着有机会另起炉灶,用上时下最流行最热门的技术栈(spring boot、springcloud、redis、nosql、docker、vue)。 或者即便不另起炉灶,也认为现有技术栈太过时无法容忍了(其实可能并不算过时),不用微服务不用分布式就不能接受,于是激进的引入新技术栈,鲁莽的对项目做大手术。 这种对刚刚流行还不成熟技术的盲目跟风、技术选型不慎重的情况非常普遍,今天在他们眼中落伍的技术栈,其实也不过是几年前另一批人赶的时髦。 我不反对技术上的追新,但是同样的,这里的问题是:他们对于大手术的风险和副作用,对如何避免重蹈覆辙用新技术架构做出另一个烂项目,没有把握也没有深入思考的,只是盲目乐观的认为新技术能带来成功。 也没人能阻止这种简历驱动的技术选型浮躁风气,毕竟花的是公司的资源,用新东西显得自己很有追求,失败了也不影响简历美化,简历上只会增加一段项目履历和几种精通技能,不会提到又做烂了一个项目,名利双收稳赚不赔。 保守改良派: 还有一类人他们不愿轻易放弃这个有问题但仍在创造效益的项目,因为他们看到了项目仍然有维护的价值,也看到了另起炉灶的难度(万事开头难,其实项目的冷启动存在很多外部制约因素)、大手术对业务造成影响的代价、系统迁移的难度和风险。 同时他们尝试用温和渐进的方式逐步改善项目质量,采用一系列工程实践(主要包括重构热点代码、补自动化测试、补文档)来清理“技术债”,消除制约项目开发效率和交付质量的瓶颈。 如果把一个问题项目比作病入膏肓的病人,那么这三种做法分别相当于是放弃治疗、截肢手术、保守治疗。 2. 一个 35+ 程序员的反思 年轻时候我也是掀桌子派和激进派的,新工程新框架大开大合,一路走来经验值技能树蹭蹭的涨,跳槽加薪好不快活。 但是近几年随着年龄增长,一方面新东西学不动了,另一方面对经历过的项目反思的多了观念逐渐改变了。 对我触动最大的一件事是那个我在 2016 年初开始从零搭建起的项目,在我 2018 年底离开的时候(仅从代码质量角度)已经让我很不满意了。只是,这一次没有任何借口了: 从技术选型到架构设计到代码规范,都是我自己做的,团队不大,也是我自己组建和一手带出来的; 最开始的半年进展非常顺利,用着我最趁手的技术和工具一路狂奔,年底前替换掉了之前采购的那个垃圾产品(对的,有个前任在业务上做参照也算是个很大的有利因素); 做的过程我也算是全力以赴,用尽毕生所学——前面 13 年工作的经验值和走过的弯路、教训,使得公司只用其它同类公司同类项目 20% 的资源就把平台做起来了; 如果说多快好省是最高境界,那么当时的我算是做到了多、快、省——交付的功能非常丰富且贴近业务需求、开发节奏快速、对公司开发资源很节省; 但是现在看来,“好”就远远没有达到了,到了项目中期,简单优先级高的需求都已经做完了,公司业务上出现了新的挑战——接入另一个核心系统以及外部平台,真正的考验来了。 那个改造工程影响面比较大,需要对我们的系统做大面积修改,最麻烦的是这意味着从一个简单的单体系统变成了一个分布式的系统,而且业务涉及资金交易,可靠性要求较高,是难上加难。 于是问题开始出现了:我之前架构的优点——简单直接——这个时候不再是优点了,简单直接的架构在业务环境、技术环境都简单的情况下可以做到多快好省,但是当业务、技术环境都陡然复杂起来时,就不行了; 具体的表现就是:架构和代码层面的结构都快速的变得复杂、混乱起来了——熵急剧增加; 后面的事情就一发不可收拾:代码改起来越来越吃力、测试问题变多、生产环境故障和问题变多、于是消耗在排查测试问题生产问题和修复数据方面的精力急剧增加、出现恶性循环。。。 到了这个境地,项目就算是做烂了!一个我从头开始做起的没有任何借口的失败! 于是我意识到一个非常浅显的道理:拥有一张空白的画卷、一支最高级的画笔、一间专业的画室,无法保证你可以画出美丽的画卷。如果你不善于画画,那么一切都是空想和意淫。 然后我变成了一个“保守改良派”,因为我意识到掀桌子和激进的改革都是不负责任的,说不好听的那样其实是掩耳盗铃、逃避困难,人不可能逃避一辈子,你总要面对。 即便掀了桌子另起炉灶了,你还是需要找到一种办法把这个新的炉灶烧好,因为随着项目发展之前的老问题还是会一个一个冒出来,还是需要面对现实、不逃避、找办法。 面对问题不仅有助于你把当前项目做好,也同样有助于将来有新的项目时更好的把握住机会。 无论是职业生涯还是自然年龄,人到了这个阶段都开始喜欢回顾和总结,也变得比过去更在乎项目、产品乃至公司的商业成败。 软件开发作为一种商业活动,判断其成败的依据应该是:能否以可接受的成本、可预期的时间节奏、稳定的质量水平、持续交付满足业务需要的功能市场需要的产品。 其实就是项目管理四要素——成本、进度、范围、质量,传统项目管理理论认为这四要素彼此制约难以兼得,项目管理的艺术在于四要素的平衡取舍。 关于软件工程和项目管理的理论和著作已经很多很成熟,这里我从程序员的视角提出一个新的观点——质量不可妥协: 质量要素不是一个可以被牺牲和妥协的要素——牺牲质量会导致其它三要素全都受损,反之同理,追求质量会让你在其它三个方面同时受益。 在保持一个质量水平的前提下,成本、进度、范围三要素确确实实是互相制约关系——典型的比如牺牲成本(加班加点)来加快进度交付急需的功能。 正如著名的“破窗效应”所启示的那样:任何一种不良现象的存在,都在传递着一种信息,这种信息会导致不良现象的无限扩展,同时必须高度警觉那些看起来是偶然的、个别的、轻微的“过错”,如果对这种行为不闻不问、熟视无睹、反应迟钝或纠正不力,就会纵容更多的人“去打烂更多的窗户玻璃”,就极有可能演变成“千里之堤,溃于蚁穴”的恶果——质量不佳的代码之于一个项目,正如一扇破了的窗之于一幢建筑、一个蚂蚁巢之于一座大堤。 好消息是,只要把质量提上去项目就会逐渐走上健康的轨道,其它三个方面也都会改善。管好了质量,你就很大程度上把握住了项目成败的关键因素。 坏消息是,项目的质量很容易失控,现实中质量不佳、越做越臃肿混乱的项目比比皆是,质量改善越做越好的案例闻所未闻,以至于人们将其视为如同物理学中“熵增加定律”一样的必然规律了。 当然任何事情都有一个度的问题,当质量低于某个水平时才会导致其它三要素同时受损。反之当质量高到某个水平以后,继续追求质量不仅得不到明显收益,而且也会损害其它三要素——边际效用递减定律。 这个度需要你为自己去评估和测量,如果目前的质量水平还在两者之间,那么就应该重点改进项目质量。当然,现实世界中很少看到哪个项目质量高到了不需要重视的程度。 3. 项目走向衰败的最常见诱因——代码质量不佳 一个项目的衰败一如一个人健康状况的恶化,当然可能有多种多样的原因——比如需求失控、业务调整、人员变动流失。但是作为我们技术人,如果能做好自己分内的工作——编写出可维护的代码、减少技术债利息成本、交付一个健壮灵活的应用架构,那也绝对是功德无量的。 虽然很难估算出这究竟能挽救多少项目,但是在我十多年职业生涯中,经历的和近距离观察的几十个项目,确实看到了大量的项目正是由于代码质量不佳导致的失败和遗憾,同时我也发现其实失败项目的很多问题、症结也确确实实都可以归因到项目代码的混乱和质量低下,比如一个常见的项目腐烂恶性循环:代码乱》bug 多》排查问题耗时》复用度低》加班 996》士气低落…… 所谓“千里之堤,毁于蚁穴”,代码问题就是蚁穴。 接下来,让我们从项目管理聚焦到项目代码质量这个相对小的领域来深入剖析。编写高质量可维护的代码是程序员的基本修养,本文试图在代码层面找到一些失败项目中普遍存在的症结问题,同时基于个人十几年开发经验总结出的一些设计模式作为药方分享出来。 关于代码质量的话题其实很难通过一篇文章阐述明白,甚至需要一本书的篇幅,里面涉及到的很多概念关注点之间存在复杂微妙关系。 推荐《设计模式之美》的第二章节《从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?》,这是我看到的关于代码质量主题最精彩深刻的论述。 4. 一个失败项目复盘 先贴几张代码截图,看一下这个重病缠身的项目的病灶和症状: 这是该项目中一个最核心、最复杂也是最经常要被改动的 class,代码行数 4881; 结果就是冗长的 API 列表(列表需要滚动 4 屏才能到底,公有私有 API 180 个); 还是那个 Class,头部的 import 延绵到了 139 行,去掉第一行 package 声明和少量空行总共 import 引入了 130 个 class! 还是那个坑爹的组件,从 156 行开始到 235 行声明了 Spring 依赖注入的组件 40 个! 这里先不去分析这个类的问题,只是初步展示一下病情严重程度。 我相信这应该不算是特别糟糕的情况,比这个严重的项目俯拾皆是,但是这也应该足够拿来暴露问题、剖析成因了。 4.1 症结 1:组件粒度过大、API 泛滥 分层的理念早已深入人心,尤其是业务逻辑层的独立,彻底杜绝了之前(不分层的年代)业务逻辑与展现逻辑、持久化逻辑等混杂的问题。 但是好景不长,随着业务的复杂和变更,在业务逻辑层的复杂性也急剧增加,成为了新的开发效率瓶颈, 问题就出在了业务逻辑组件的划分方式——按领域模型划分业务逻辑组件: 业界关于如何设计业务逻辑层 并没有标准和最佳实践,绝大多数项目(我自己经历过的项目以及我有机会深入了解的项目)中大家都是想当然的按照业务领域对象来设计; 例如:领域实体对象有 Account、Order、Delivery、Campaign。于是业务逻辑层就设计出 AccountService、OrderService、DeliveryService、CampaignService 这种做法在项目简单是没什么问题,事实上项目简单时 你随便怎么设计都问题不大。 但是当项目变大和复杂以后,就会出现问题了: 组件臃肿:Service 组件的个数跟领域实体对象个数基本相当,必然造成个别 Service 组件变得非常臃肿——API 非常多,代码行数达到几千行; 职责模糊:业务逻辑往往跨多个领域实体,无论放在哪个 Service 都不合适,同样的,要找一个功能的实现逻辑也无法确定在哪个 Service 中; 代码重复 or 逻辑纠缠的两难选择:当遇到一个业务逻辑,其中的某个环节在另一个业务逻辑 API 中已经实现,这时如果不想忍受重复实现和代码,就只能去调用那个 API。但这样就造成了业务逻辑组件之间的耦合与依赖,这种耦合与依赖很快会扩散——新的 API 又会被其它业务逻辑依赖,最终形成蜘蛛网一样的复杂依赖甚至循环依赖; 复用代码、减少重复虽然是好的,但是复杂耦合依赖的害处也很大——赶走一只狼引来了一只虎。两杯毒酒给你选! 前面截图的那个问题组件 ContractService 就是一个典型案例,这样的组件往往是热点代码以及整个项目的开发效率的瓶颈。 4.2 药方 1:倒金字塔结构——业务逻辑组件职责单一、禁止层内依赖 问题根源的反面其实就藏着解决方案,只是需要我们有意识的去改变习惯、遵循新的设计风格,而不是凭直觉去设计: 业务逻辑层应该被设计成一个个功能非常单一的小组件,所谓小是指 API 数量少、代码行数少; 由于职责单一因此必然组件数量多,每一个组件对应一个很具体的业务功能点(或者几个相近的); 复用(调用、依赖)只应该发生在相邻的两层之间——上层调用下层的 API 来实现对下层功能的复用; 于是系统架构就自然呈现出倒立的金字塔形状:越接近顶层的业务场景组件数量越多,越往下层的复用性高,于是组件数量越少。 4.3 症结 2:低内聚、高耦合 经典面向对象理论告诉我们,好的代码结构应该是“高内聚、低耦合”的: 高内聚:组件本身应该尽可能的包含其所实现功能的所有重要信息和细节,以便让维护者无需跳转到其它多个地方去了解必要的知识。 低耦合:组件之间的互相依赖和了解尽可能少,以便在一个组件需要改动时其它组件不受影响。 其实这两者就是一体两面,做到了高内聚基本也就做到了低耦合,相反如果内聚度很低,势必存在大量高耦合的组件。 我观察发现,很多项目都存在低内聚、高耦合的问题。根本原因在于很多程序员,甚至是很多经验丰富的程序员也缺少这方面的意识——对“内聚性”概念不甚清楚,对内聚性被破坏的危害没有意识,对如何避免更是无从谈起。 很多人从一开始就凭直觉写程序,有了一定经验以后一般能认识到重复代码的危害,对复用性有很强的认识,于是就会掉进一个陷阱——盲目追求复用,结果破坏了内聚性。 业界关于“复用性”的认识存在一个误区—— 认为包括业务逻辑组件在内的任何层面的组件都应该追求最大限度的可复用性; 复用当然是好的,但那应该有个前提条件:不增加系统复杂度的情况下的复用,才是好的。 什么样的复用会增加系统复杂性、是不好的呢?前面提到的,一个业务逻辑 API 被另一个业务逻辑 API 复用——就是不好的: 损害了稳定性:因为业务逻辑本身是跟现实世界的业务挂钩的,而业务会发生变化;当你复用一个会发生变化的 API,相当于在沙子上建高楼——地基是松动的; 增加了复杂性:这样的依赖还造成代码可读性降低——在一个本就复杂的业务逻辑代码中,包含了对另一个复杂业务逻辑的调用,复杂度会急剧增加,而且会不断泛滥和传递; 内聚性被破坏:由于业务逻辑被打散在了多个组件的方法内,变得支离破碎,无法在一个地方看清整体逻辑脉络和实现步骤——内聚性被破坏,同时也意味着,这个调用链条上涉及的所有组件之间存在高耦合。 4.4 药方 2:复用的两种正确姿势——打造自己的 lib 和 framework 软件架构中有两种东西来实现复用——lib 和 framework, lib 库是供你(应用程序)调用的,它帮你实现特定的能力(比如日志、数据库驱动、json 序列化、日期计算、http 请求)。 framework 框架是供你扩展的,它本身就是半个应用程序,定义好了组件划分和交互机制,你需要按照其规则扩展出特定的实现并绑定集成到其中,来完成一个应用程序。 lib 就是组合方式的复用,framework 则是继承式的复用,继承的 Java 关键字是 extends,所以本质上是扩展。 过去有个说法:“组合优于继承,能用组合解决的问题尽量不要继承”。我不同意这个说法,这容易误导初学者以为组合优于继承,其实继承才是面向对象最强大的地方,当然任何东西都不能乱用。 典型的继承乱用就是为了获得父类的某个 API 而去继承,继承一定是为了扩展,而不是为了直接获得一个能力,获得能力应该调用 lib,父类不应该去实现具体功能,那是 lib 该做的事。 也不应该为了使用 lib 而去继承 lib 中的 Class。lib 就是用来被组合被调用的,framework 就是用来被继承、扩展的。 再展开一下:lib 既可以是第三方的(log4j、httpclient、fastjson),也可是你自己工程的(比如你的持久层 Dao、你的 utils); framework 同理,既可以是第三方的(springmvc、jpa、springsecurity),也可以是你项目内封装的面向具体业务领域的(比如 report、excel 导出、paging 或任何可复用的算法、流程)。 从这个意义上说, 一个项目中的代码其实只有 3 种:自定义的 lib class、自定义的 framework 相关 class、扩展第三方或自定义 framework 的组件 class。 再扩展一下:相对于过去,现在我们已经有了足够多的第三方 lib 和 framework 来复用,来帮助项目节省大量代码,开发工作似乎变成了索然无味、没技术含量的 CRUD。但是对于业务非常复杂的项目,则需要有经验、有抽象思维、懂设计模式的人,去设计面向业务的 framework 和面向业务的 lib,只有这样才能交付可维护、可扩展、可复用的软件架构——高质量架构,帮助项目或产品取得成功。 4.5 症结 3:抽象不够、逻辑纠缠——High Level 业务逻辑和 Low Level 实现逻辑纠缠 当我们说“代码中包含的业务逻辑”的时候,我们到底在说什么?业界并没有一个标准,大家经常讲的 CRUD 增删改查其实属于更底层的数据访问逻辑。 我的观点是:所谓代码中的业务逻辑,是指这段代码所表现出的所有输入输出规则、算法和行为,通常可以分为以下 5 类: 输入合法性校验; 业务规则校验:典型的如检查交易记录状态、金额、时限、权限等,通常包含数据库或外部接口的查询作为参考; 数据持久化行为:数据库、缓存、文件、日志等任何形式的数据写入行为; 外部接口调用行为; 输出/返回值准备。 当然具体到某一个组件实例,可能不会包括上述全部 5 类业务逻辑,但是也可能每一类业务逻辑存在多个。 单这样看你可能觉得并不是特别复杂,但是现实中上述 5 类业务逻辑中的每一个通常还包含着一到多个底层实现逻辑,如 CRUD 数据访问逻辑或第三方 API 的调用。 例如输入合法性校验,通常需要查询对应记录是否存在,外部接口调用前通常需要查询相关记录以获得调用接口需要的参数,调用接口后还需要根据结果更新相关记录状态。 显然这里存在两个 Level 的逻辑——High Level 的与业务需求对应且关联紧密的逻辑、Low Level 的实现逻辑。 如果对两个 Level 的逻辑不加以区分、混为一谈,代码质量立刻就会遭到严重损害: 可读性变差:两个维度的复杂性——业务复杂性和底层实现的技术复杂性——被掺杂在了一起,复杂度 1+1>2 剧增,给其他人阅读代码增加很大负担; 可维护性差:可维护性通常指排查和解决问题所需花费的代价高低,当两个 level 的逻辑纠缠在一起,会使排查问题变的更困难,修复问题时也更容易出错; 可扩展性无从谈起:扩展性通常指为系统增加一个特性所需花费的代价高低,代价越高扩展性越差;与排查修复问题类似,逻辑纠缠显然也会使添加新特性变得困难、一不小心就破坏了已有功能。 下面这段代码就是一个典型案例——High Level 的逻辑流程(参数获取、反序列化、参数校验、缓存写入、数据库持久化、更新相关交易记录)完全淹没在了 Low Level 的实现逻辑(字符串比较、Json 反序列化、redis 操作、dao 操作以及前后各种琐碎的参数准备和返回值处理)。下一节我会针对这段问题代码给出重构方案。 @Overridepublic void updateFromMQ(String compress) { try { JSONObject object = JSON.parseObject(compress); if (StringUtils.isBlank(object.getString("type")) || StringUtils.isBlank(object.getString("mobile")) || StringUtils.isBlank(object.getString("data"))){ throw new AppException("MQ返回参数异常"); } logger.info(object.getString("mobile")+""+object.getString("type")); Map map = new HashMap(); map.put("type",CrawlingTaskType.get(object.getInteger("type"))); map.put("mobile", object.getString("mobile")); List list = baseDAO.find("from crt c where c.phoneNumber=:mobile and c.taskType=:type", map); redisClientTemplate.set(object.getString("mobile") + "_" + object.getString("type"),CompressUtil.compress( object.getString("data"))); redisClientTemplate.expire(object.getString("mobile") + "_" + object.getString("type"), 2*24*60*60); //保存成功 存入redis 保存48小时 CrawlingTask crawlingTask = null; // providType:(0:新颜,1XX支付宝,2:ZZ淘宝,3:TT淘宝) if (CollectionUtils.isNotEmpty(list)){ crawlingTask = list.get(0); crawlingTask.setJsonStr(object.getString("data")); }else{ //新增 crawlingTask = new CrawlingTask(UUID.randomUUID().toString(), object.getString("data"), object.getString("mobile"), CrawlingTaskType.get(object.getInteger("type"))); crawlingTask.setNeedUpdate(true); } baseDAO.saveOrUpdate(crawlingTask); //保存芝麻分到xyz if ("3".equals(object.getString("type"))){ String data = object.getString("data"); Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score"); Map param = new HashMap(); param.put("phoneNumber", object.getString("mobile")); List list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param); if (list1 !=null){ for (Dperson dperson:list1){ dperson.setZmScore(zmf); personBaseDaoI.saveOrUpdate(dperson); AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf);//查询多租户表 身份认证、淘宝认证 为0 置为1 } } } } catch (Exception e) { logger.error("更新my MQ授权信息失败", e); throw new AppException(e.getMessage(),e); }} 4.6 药方 3:控制逻辑分离——业务模板 Pattern of NestedBusinessTemplate 解决“逻辑纠缠”最关键是要找到一种隔离机制,把两个 Level 的逻辑分开——控制逻辑分离,分离的好处很多: 根据经验,当我们着手维护一段代码时,一定是想先弄清楚它的整体流程、算法和行为,而不是一上来就去研究它的细枝末节; 控制逻辑分离后,只需要去看 High Level 部分就能了解到上述内容,阅读代码的负担大幅度降低,代码可读性显著增强; 读懂代码是后续一切维护、重构工作的前提,而且一份代码被读的次数远远高于被修改的次数(高一个数量级),因此代码对人的可读性再怎么强调都不为过,可读性增强可以大幅度提高系统可维护性,也是重构的最主要目标。 同时,根据我的经验,High Level 业务逻辑的变更往往比 Low Level 实现逻辑变更要来的频繁,毕竟前者跟业务直接对应。当然不同类型项目情况不一样,另外它们发生变更的时间点往往也不同; 在这样的背景下,控制逻辑分离的好处就更明显了:每次维护、扩充系统功能只需改动一个 Levle 的代码,另一个 Level 不受影响或影响很小,这会大幅降低修改成本和风险。 我在总结过去多个项目中的教训和经验后,总结出了一项最佳实践或者说是设计模式——业务模板 Pattern of NestedBusinessTemplat,可以非常简单、有效的分离两类逻辑,先看代码: public class XyzService {abstract class AbsUpdateFromMQ { public final void doProcess(String jsonStr) { try { JSONObject json = doParseAndValidate(jsonStr); cache2Redis(json); saveJsonStr2CrawingTask(json); updateZmScore4Dperson(json); } catch (Exception e) { logger.error("更新my MQ授权信息失败", e); throw new AppException(e.getMessage(), e); } } protected abstract void updateZmScore4Dperson(JSONObject json); protected abstract void saveJsonStr2CrawingTask(JSONObject json); protected abstract void cache2Redis(JSONObject json); protected abstract JSONObject doParseAndValidate(String json) throws AppException;} @SuppressWarnings({ "unchecked", "rawtypes" })public void processAuthResultDataCallback(String compress) { new AbsUpdateFromMQ() {@Overrideprotected void updateZmScore4Dperson(JSONObject json) { //保存芝麻分到xyz if ("3".equals(json.getString("type"))){ String data = json.getString("data"); Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score"); Map param = new HashMap(); param.put("phoneNumber", json.getString("mobile")); List list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param); if (list1 !=null){ for (Dperson dperson:list1){ dperson.setZmScore(zmf); personBaseDaoI.saveOrUpdate(dperson); AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf); } } }} @Overrideprotected void saveJsonStr2CrawingTask(JSONObject json) { Map map = new HashMap(); map.put("type",CrawlingTaskType.get(json.getInteger("type"))); map.put("mobile", json.getString("mobile")); List list = baseDAO.find("from crt c where c.phoneNumber=:mobile and c.taskType=:type", map); CrawlingTask crawlingTask = null; // providType:(0:xx,1yy支付宝,2:zz淘宝,3:tt淘宝) if (CollectionUtils.isNotEmpty(list)){ crawlingTask = list.get(0); crawlingTask.setJsonStr(json.getString("data")); }else{ //新增 crawlingTask = new CrawlingTask(UUID.randomUUID().toString(), json.getString("data"), json.getString("mobile"), CrawlingTaskType.get(json.getInteger("type"))); crawlingTask.setNeedUpdate(true); } baseDAO.saveOrUpdate(crawlingTask);}@Overrideprotected void cache2Redis(JSONObject json) { redisClientTemplate.set(json.getString("mobile") + "_" + json.getString("type"),CompressUtil.compress( json.getString("data"))); redisClientTemplate.expire(json.getString("mobile") + "_" + json.getString("type"), 2*24*60*60);}@Overrideprotected JSONObject doParseAndValidate(String json) throws AppException { JSONObject object = JSON.parseObject(json); if (StringUtils.isBlank(object.getString("type")) || StringUtils.isBlank(object.getString("mobile")) || StringUtils.isBlank(object.getString("data"))){ throw new AppException("MQ返回参数异常"); } logger.info(object.getString("mobile")+""+object.getString("type")); return object; } }.doProcess(compress);} 如果你熟悉经典的 GOF23 种设计模式,很容易发现上面的代码示例其实就是 Template Method 设计模式的运用,没什么新鲜的。 没错,我这个方案没有提出和创造任何新东西,我只是在实践中偶然发现 Template Method 设计模式真的非常适合解决广泛存在的逻辑纠缠问题,而且也发现很少有程序员能主动运用这个设计模式;一部分原因可能是意识到“逻辑纠缠”问题的人本就不多,同时熟悉这个设计模式并能自如运用的人也不算多,两者的交集自然就是少得可怜;不管是什么原因,结果就是这个问题广泛存在成了通病。 我看到一部分对代码质量有追求的程序员 他们的解决办法是通过"结构化编程"和“模块化编程”: 把 Low Level 逻辑提取成 private function,被 High Level 代码所在的 function 直接调用; 问题 1 硬连接不灵活:首先,这样虽然起到了一定的隔离效果,但是两个 level 之间是静态的硬关联,Low Level 无法被简单的替换,替换时还是需要修改和影响到 High Level 部分; 问题 2 组件内可见性造成混乱:提取出来的 private function 在当前组件内是全局可见的——对其它无关的 High Level function 也是可见的,各个模块之间仍然存在逻辑纠缠。这在很多项目中的热点代码中很常见,问题也很突出:试想一个包含几十个 API 的组件,每个 API 的 function 存在一两个关联的 private function,那这个组件内部的混乱程度、维护难度是难以承受的。 把 Low Level 逻辑抽取到新的组件中,供 High Level 代码所在的组件依赖和调用;更有经验的程序员可能会增加一层接口并且借助 Spring 依赖注入; 问题 1 API 泛滥:提取出新的组件似乎避免了“结构化编程”的局限性,但是带来了新的问题——API 泛滥:因为组件之间调用只能走 public 方法,而这个 API 其实没有太多复用机会根本没必要做成 public 这种最高可见性。 问题 2 同层组件依赖失控:组件和 API 泛滥后必然导致组件之间互相依赖成为常态,慢慢变得失控以后最终变成所有组件都依赖其它大部分组件,甚至出现循环依赖;比如那个拥有 130 个 import 和 40 个 Spring 依赖组件的 ContractService。 下面介绍一下 Template Method 设计模式的运用,简单归纳就是: High Level逻辑封装在抽象父类AbsUpdateFromMQ的一个final function中,形成一个业务逻辑的模板; final function保证了其中逻辑不会被子类有意或无意的篡改破坏,因此其中封装的一定是业务逻辑中那些相对固定不变的东西。至于那些可变的部分以及暂时不确定的部分,以abstract protected function形式预留扩展点; 子类(一个匿名内部类)像“做填空题”一样,填充模板实现Low Level逻辑——实现那些protected function扩展点;由于扩展点在父类中是abstract的,因此编译器会提醒子类的程序员该扩展什么。 那么它是如何避免上面两个方案的 4 个局限性的: Low Level 需要修改或替换时,只需从父类扩展出一个新的子类,父类全然不知无需任何改动; 无论是父类还是子类,其中的 function 对外层的 XyzService 组件都是不可见的,即便是父类中的 public function 也不可见,因为只有持有类的实例对象才能访问到其中的 function; 无论是父类还是子类,它们都是作为 XyzService 的内部类存在的,不会增加新的 java 类文件更不会增加大量无意义的 API(API 只有在被项目内复用或发布出去供外部使用才有意义,只有唯一的调用者的 API 是没有必要的); 组件依赖失控的问题当然也就不存在了。 SpringFramework 等框架型的开源项目中,其实早已大量使用 Template Method 设计模式,这本该给我们这些应用开发程序员带来启发和示范,但是很可惜业界没有注意到和充分发挥它的价值。 NestedBusinessTemplat 模式就是对其充分和积极的应用,前面一节提到过的复用的两种正确姿势——打造自己的 lib 和 framework,其实 NestedBusinessTemplat 就是项目自身的 framework。 4.7 症结 4:无处不在的 if else 牛皮癣 无论你的编程启蒙语言是什么,最早学会的逻辑控制语句一定是 if else,但是不幸的是它在你开始真正的编程工作以后,会变成一个损害项目质量的坏习惯。 几乎所有的项目都存在 if else 泛滥的问题,但是却没有引起足够重视警惕,甚至被很多程序员认为是正常现象。 首先我来解释一下为什么 if else 这个看上去人畜无害的东西是有害的、是需要严格管控的: if else if ...else 以及类似的 switch 控制语句,本质上是一种 hard coding 硬编码行为,如果你同意“magic number 魔法数字”是一种错误的编程习惯,那么同理,if else 也是错误的 hard coding 编程风格; hard coding 的问题在于当需求发生改变时,需要到处去修改,很容易遗漏和出错; 以一段代码为例来具体分析: if ("3".equals(object.getString("type"))){ String data = object.getString("data"); Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score"); Map param = new HashMap(); param.put("phoneNumber", object.getString("mobile")); List list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param); if (list1 !=null){ for (Dperson dperson:list1){ dperson.setZmScore(zmf); personBaseDaoI.saveOrUpdate(dperson); AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf); } }} if ("3".equals(object.getString("type"))) 显然这里的"3"是一个 magic number,没人知道 3 是什么含义,只能推测; 但是仅仅将“3”重构成常量 ABC_XYZ 并不会改善多少,因为 if (ABC_XYZ.equals(object.getString("type"))) 仍然是面向过程的编程风格,无法扩展; 到处被引用的常量 ABC_XYZ 并没有比到处被 hard coding 的 magic number 好多少,只不过有了含义而已; 把常量升级成 Enum 枚举类型呢,也没有好多少,当需要判断的类型增加了或判断的规则改变了,还是需要到处修改——Shotgun Surgery(霰弹式修改) 并非所有的 if else 都有害,比如上面示例中的 if (list1 !=null) { 就是无害的,没有必要去消除,也没有消除它的可行性。判断是否有害的依据: 如果 if 判断的变量状态只有两种可能性(比如 boolean、比如 null 判断)时,是无伤大雅的; 反之,如果 if 判断的变量存在多种状态,而且将来可能会增加新的状态,那么这就是个问题; switch 判断语句无疑是有害的,因为使用 switch 的地方往往存在很多种状态。 4.8 药方 4:充血枚举类型——Rich Enum Type 正如前面分析呈现的那样,对于代码中广泛存在的状态、类型 if 条件判断,仅仅把被比较的值重构成常量或 enum 枚举类型并没有太大改善——使用者仍然直接依赖具体的枚举值或常量,而不是依赖一个抽象。 于是解决方案就自然浮出水面了:在 enum 枚举类型基础上进一步抽象封装,得到一个所谓的“充血”的枚举类型,代码说话: 实现多种系统通知机制,传统做法: enum NOTIFY_TYPE { email,sms,wechat; } //先定义一个enum——一个只定义了值不包含任何行为的“贫血”的枚举类型if(type==NOTIFY_TYPE.email){ //if判断类型 调用不同通知机制的实现 。。。}else if (type=NOTIFY_TYPE.sms){ 。。。}else{ 。。。} 实现多种系统通知方式,充血枚举类型——Rich Enum Type 模式: enum NOTIFY_TYPE { //1、定义一个包含通知实现机制的“充血”的枚举类型 email("邮件",NotifyMechanismInterface.byEmail()), sms("短信",NotifyMechanismInterface.bySms()), wechat("微信",NotifyMechanismInterface.byWechat()); String memo; NotifyMechanismInterface notifyMechanism; private NOTIFY_TYPE(String memo,NotifyMechanismInterface notifyMechanism){//2、私有构造函数,用于初始化枚举值 this.memo=memo; this.notifyMechanism=notifyMechanism; } //getters ...}public interface NotifyMechanismInterface{ //3、定义通知机制的接口或抽象父类 public boolean doNotify(String msg); public static NotifyMechanismInterface byEmail(){//3.1 返回一个定义了邮件通知机制的策的实现——一个匿名内部类实例 return new NotifyMechanismInterface(){ public boolean doNotify(String msg){ ....... } }; } public static NotifyMechanismInterface bySms(){//3.2 定义短信通知机制的实现策略 return new NotifyMechanismInterface(){ public boolean doNotify(String msg){ ....... } }; } public static NotifyMechanismInterface byWechat(){//3.3 定义微信通知机制的实现策略 return new NotifyMechanismInterface(){ public boolean doNotify(String msg){ ....... } }; }}//4、使用场景NOTIFY_TYPE.valueof(type).getNotifyMechanism().doNotify(msg); 充血枚举类型——Rich Enum Type 模式的优势: 不难发现,这其实就是 enum 枚举类型和 Strategy Pattern 策略模式的巧妙结合运用; 当需要增加新的通知方式时,只需在枚举类 NOTIFY_TYPE 增加一个值,同时在策略接口 NotifyMechanismInterface 中增加一个 by 方法返回对应的策略实现; 当需要修改某个通知机制的实现细节,只需修改 NotifyMechanismInterface 中对应的策略实现; 无论新增还是修改通知机制,调用方完全不受影响,仍然是 NOTIFY_TYPE.valueof(type).getNotifyMechanism().doNotify(msg); 与传统 Strategy Pattern 策略模式的比较优势:常见的策略模式也能消灭 if else 判断,但是实现起来比较麻烦,需要开发更多的 class 和代码量: 每个策略实现需单独定义成一个 class; 还需要一个 Context 类来做初始化——用 Map 把类型与对应的策略实现做映射; 使用时从 Context 获取具体的策略; Rich Enum Type 的进一步的充血: 上面的例子中的枚举类型包含了行为,因此已经算作充血模型了,但是还可以为其进一步充血; 例如有些场景下,只是要对枚举值做个简单的计算获得某种 flag 标记,那就没必要把计算逻辑抽象成 NotifyMechanismInterface 那样的接口,杀鸡用了牛刀; 这时就可以在枚举类型中增加 static function 封装简单的计算逻辑; 策略实现的进一步抽象: 当各个策略实现(byEmail bySms byWechat)存在共性部分、重复逻辑时,可以将其抽取成一个抽象父类; 然后就像前一章节——业务模板 Pattern of NestedBusinessTemplate 那样,在各个子类之间实现优雅的逻辑分离和复用。 5. 重构前的火力侦察:为你的项目编制一套代码库目录/索引——CODEX 以上就是我总结出的最常见也最影响代码质量的 4 个问题及其解决方案: 职责单一、小颗粒度、高内聚、低耦合的业务逻辑层组件——倒金字塔结构; 打造项目自身的 lib 层和 framework——正确的复用姿势; 业务模板 Pattern of NestedBusinessTemplate——控制逻辑分离; 充血的枚举类型 Rich Enum Type——消灭硬编码风格的 if else 条件判断; 接下来就是如何动手去针对这 4 个方面进行重构了,但是事情还没有那么简单。 上面所有的内容虽然来自实践经验,但是要应用到你的具体项目,还需要一个步骤——火力侦察——弄清楚你要重构的那个模块的逻辑脉络、算法以致实现细节,否则贸然动手,很容易遗漏关键细节造成风险,重构的效率更难以保证,陷入进退两难的尴尬境地。 我 2019 年一整年经历了 3 个代码十分混乱的项目,最大的收获就是摸索出了一个梳理烂代码的最佳实践——CODEX: 在阅读代码过程中,在关键位置添加结构化的注释,形如://CODEX ProjectA 1 体检预约流程 1 预约服务 API 入口 所谓结构化注释,就是在注释内容中通过规范命名的编号前缀、分隔符等来体现出其所对应的项目、模块、流程步骤等信息,类似文本编辑中的标题 1、2、3; 然后设置 IDE 工具识别这种特殊的注释,以便结构化的显示。Eclipse 的 Tasks 显示效果类似下图; 这个结构化视图,本质上相对于是代码库的索引、目录,不同于 javadoc 文档,CODEX 具有更清晰的逻辑层次和更强的代码查找便利性,在 Eclipse Tasks 中点击就能跳转到对应的代码行; 这些结构化注释随着代码一起提交后就实现了团队共享; 这样的一份精确无误、共享的、活的源代码索引,无疑会对整个团队的开发维护工作产生巨大助力; 进一步的,如果在 CODEX 中添加 Markdown 关键字,甚至可以将导出的 CODEX 简单加工后,变成一张业务逻辑的 Sequence 序列图,如下所示。 6. 总结陈词——不要辜负这个程序员最好的时代 毫无疑问这是程序员最好的时代,互联网浪潮已经席卷了世界每个角落,各行各业正在越来越多的依赖 IT。过去只有软件公司、互联网公司和银行业会雇佣程序员,随着云计算的普及、产业互联网和互联网+兴起,已经有越来越多的传统企业开始雇佣程序员搭建 IT 系统来支撑业务运营。 资本的推动 IT 需求的旺盛,使得程序员成了稀缺人才,各大招聘平台上,程序员的岗位数量和薪资水平长期名列前茅。 但是我们这个群体的整体表现怎么样呢,扪心自问,我觉得很难令人满意,我所经历过的以及近距离观察到的项目,鲜有能够称得上成功的。这里的成功不是商业上的成功,仅限于作为一个软件项目和工程是否能够以可接受的成本和质量长期稳定的交付。 商业的短期成功与否,很多时候与项目工程的成功与否没有必然联系,一个商业上很成功的项目可能在工程上做的并不好,只是通过巨量的资金资源投入换来的暂时成功而已。 归根结底,我们程序员群体需要为自己的声誉负责,长期来看也终究会为自己的声誉获益或受损。 我认为程序员最大的声誉、最重要的职业素养,就是通过写出高质量的代码做好一个个项目、产品,来帮助团队、帮助公司、帮助组织创造价值、增加成功的机会。 希望本文分享的经验和方法能够对此有所帮助! 本文是我的一位技术总监好友:权哥花了半个月时间写出来的良心文章,强烈推荐给大家,文章很长很硬很有价值,大家可以收藏多看几遍。希望大家看完之后转发、点在看,好文章要让更多的人看到。 特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下: 长按订阅更多精彩▼如有收获,点个在看,诚挚感谢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-25 关键词: 程序员 互联网

  • 某拼多多程序员:员工学历比阿里强了几条街

    请点击上面  一键关注! 互联网大厂对学历的要求有多高?有的大厂要求211,985,有的大厂却觉得普通一本二本都可以,只要能干活就行,这之间的差别有多大呢? 一个拼多多程序员发帖说,拼多多的员工整体学历比阿里强了好几条街,难怪公司氛围好很多。拼多多人均985,阿里人均才普通一本甚至二本,连211都没到。 此番言论立即引起了网友们的激烈反弹,大家纷纷diss楼主,学历高有什么用?连拉屎自由都没有,人均985却活得那么憋屈,也不知道楼主哪来的优越感,难道是膝盖软骨太脆弱了?看来拼多多的“拉屎梗”真是深入人心,一提到拼多多,大家立即想到了奇特的拉屎姿势。 除了拉屎不便之外,拼多多的大小周和疯狂加班也成了大家diss的重点,一进拼多多,寿命短十年,拼多多就是穷人孩子吃苦挣钱的地方。      阿里员工纷纷出来回应,有的说自己是幼儿园结业,隔壁同事妇产科早产肄业,阿里员工就这么差,怎么了? 有的说阿里学历人均985硕士,一半是浙大的,哪里低了? 有的说十年前的一本会比现在的研究生差吗?有的说在阿里985都是普通的,清北才能抬起头,还有国外高校的呢!楼主一定是被拼多多洗脑了,可见拼多多的pua有多厉害。 还有许多网友说学历高低也不说明什么,马云学历也一般,但也不妨碍人家当首富。大部分互联网公司都不看学历,因为英雄不问出处,何况有时候学历高的人情商反而低。 拼多多员工学历高又怎样?还不是高学历卖假货?根本没资格和阿里battle,阿里的p7能对标杨振宁,拼多多行吗? 阿里的平均学历低也是有原因的,毕竟成立20多年,老员工的学历确实不高,新员工就不同了。拼多多成立时间晚,而且阿里和拼多多的发展阶段不同步,一是分蛋糕,一个是做蛋糕,员工体量差别也很大,自然不能一起比较。 网友说,阿里员工学历低,正说明阿里招人不注重学历,不拘一格降人才,注重的是能力和情商,给更多的人就业机会,这才是一个大厂的胸襟和格局。 学历固然能说明许多问题,比如一个人的学习能力,自律能力,努力程度等等。但衡量一个人的不仅是学历,还有许多因素,比如能力,情商,德行,性格……能否做好一份工作,只看学历绝对不行。学历只能代表当学生时的水平,不能代表一个人的全部,毕业的那一天,这些荣誉和光环就都是过去式了。如果一个人总是沉湎于过去的辉煌不能自拔,那就太幼稚了。如果一个公司在招人的时候唯学历论,可要小心错过适合的人才,毕竟那张纸的重量不足以支撑一个人的全部。 特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下: 长按订阅更多精彩▼如有收获,点个在看,诚挚感谢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-25 关键词: 程序员 互联网

  • 智慧物流成为了旷视发展的新引擎

    智慧物流成为了旷视发展的新引擎

    2020年10月15日,旷视在北京正式举行了“旷视智慧物流战略暨‘AI+物流产业联盟’发布会”。会上,旷世发布了智慧物流业务的定位和战略布局,并且发布了7款AI+智能物流硬件新品。 旷视联合创始人兼CTO唐文斌表示,“供应链物联网是旷视‘1+3’战略的重要支柱,是支撑旷视实现持续增长的关键引擎。旷视将坚定进行长期投入,深耕智慧物流领域“。 旷视高级副总裁、物流业务事业部总经理徐庆才表示,“作为最懂物流的AI公司,我们有决心和信心,成为全球领先的、以AI技术为核心的智慧物流产品和解决方案提供商“。 AI+:智慧物流发展的新引擎 AI新基建浪潮奔涌而来,AI企业需要找寻人工智能与产业结合的最佳落地点。物流行业规模庞大、场景标准,作为链接高度数字化的消费互联网和传统生产制造的过渡地带,天然是数字化转型推进的前哨。 唐文斌认为,物流行业与AI正在经历双向选择的过程,旷视充分看到了AI技术在物流行业的价值与使命。传统物流行业,人的工作压力大、部分工作环境苛刻,物流成本连年攀升,企业主动寻求降本增效之道。而疫情期间,众多企业选择的人机协作自动化场景又多次被验证为十分可靠,AI帮助物流行业进行数智化升级成为必然命题。 物流行业目前面临的挑战主要在于设备的海量规模和系统的柔性离散。未来物流行业将面对三大命题:一是如何制定高可靠规划,保证合理稳定的方案规划设计;二是如何精准控制,精确准时的控制设备协同作业;三是如何打造高效能装备,保障高效安全的储存、拣选及配送。 物流行业问题的答案指向AI,徐庆才认为,AI+是智慧物流发展的新引擎,其终极目标是为行业用户降本增效,提升用户体验。而在这一过程中,旷视将重点聚焦三大战略方向——AI算法技术力、软硬一体产品力、整仓集成生态力。 AI算法技术力:河图全新升级至2.0版本 旷视是一家AI公司,底层AI算法是旷视进入物流行业的核心竞争力。 Brain++是旷视AI算法能力的集大成者。它覆盖算法生产全流程,能够为旷视智慧物流业务提供一站式的AI工程解决方案。旷视将不断加大底层AI基础设施建设,从最底层的算法层向上生长,实现软硬件的创新,促进业务场景效能的最大化。 底层生长的关键在于AI与产业结合,旷视的答案是更新到2.0版本的河图系统。延续1.0架构设计,河图2.0丰富业务控制、设备调度、架构高可用等关键特性,能够为各种品类、复杂设备的大型无人仓提供高效稳定、智能调度、生态连接的整体智能仓储解决方案。 河图2.0版本能够调度旷视自有设备以及其他企业的设备,面向客户生产全流程可视、提前决策、自适应动态调优等功能,均获得成功实践。 软硬一体产品力:发布7款AI+物流硬件新品 旷视高级副总裁、机器人产品部总经理王宏玉表示,旷视一直坚持软硬一体化的产品布局,以加快AI商业落地。旷视将主要做AI赋能的智能物流设备,而非在同质化产品上竞争。同时,旷视也积极联合行业合作伙伴,共同为客户提供整仓智能解决方案。如今,旷视已成为最硬的AI公司。 旷视高级副总裁、机器人产品部总经理王宏玉 旷视本次发布会发布了7款机器人及智能物流装备。旷视新一代物料搬运AMR——MegBot-T800,最高2.1m/s运行速度,车身高度245mm;同时搭载首创无感智能称重,具备极致性能、极致工艺、极致智能和极致安全等特性。MegBot-T1000全金属外壳,250mm轻薄机身,自重仅220kg,工业级耐用,超长续航能力,可以12小时连续工作。 旷视激光SLAM导航AMR——MegBot-S800,采用旷视自研算法的导航系统,具有动态鲁棒特性,50%变化率动态场景稳健运行,单一特征环境不迷路,同时支持柔性部署、高精导航、安全智能。MegBot-S800V,采用纯视觉导航,具有深度智能环境感知和识别能力,立体避障,智能区分人和物。 旷视SLAM导航堆垛智能无人叉车MegBot-F1600,基于自然轮廓特征导航,应对高动态环境更从容,定位精度小于±10mm /±1°;真正无需改造环境,易于部署,10分钟万平米建图,15分钟自动精准运行。旷视SLAM导航智能无人叉车MegBot-L2000,具有快速平面搬运能力,可与河图无缝衔接,更加稳定可靠、经久耐用。 旷视人工智能堆垛机,可以实现巷道内的安全管理、轨道异物视觉检测、商品视觉盘点、垛形及库位视觉检测,使管理更智能、运行更安全、作业更高效,护航人机安全。 整仓集成生态力:发起成立人工智能物流产业联盟 除了以底层AI算法为核心的技术力,持续推进旷视河图升级迭代,打造差异化的智能机器人等软硬一体产品之外,旷视还积极与众多合作伙伴一起,通过整仓交付为客户创造价值。 目前,旷视已经拥有业内最懂行的团队,行业资深专家与AI顶级人才相互融合,团队协同作战能力不断强化;能够提供最优系统配置,通过强大算法,将不同厂商、不同功能的设备接入到旷视河图系统,实现统一管理和调度;能够提供端到端解决方案,为客户提供包含规划、仿真、实施等一站式解决方案。 旷视智慧物流解决方案已经持续落地于鞋服、制造、汽车、医药、快消等不同行业的百余家客户。会上,“糖果王国”、东莞徐福记营运总经理虞湛分享了他的智慧物流体验,“旷视智慧物流解决方案提升了徐福记在物流方面的运作效率,让我们切身感受到技术带来的转变,对于徐福记在未来规划智慧物流、智慧园区方面提供了坚实的技术能力支持”。 越是复杂的、创新的物流项目,越能体现出旷视的核心竞争力。旷视正在打造的全球最柔性服装类智能仓,依托河图连接并调度10类近4000台智能物流装备,包括700余台移动机器人,对作业效率、多类型机器人协同、大集群机器人管控等综合能力提出了近乎苛刻的要求。凭借旷视河图卓越的生态连接、协同智能、仿真能力及扎实的落地交付能力,旷视最终赢得了客户的认可。 旷视在行业内快速发展,离不开行业伙伴的支持与共享。在本次大会上,人工智能和智慧物流行业产、学、研、用方面的30余家机构与企业,共同宣布成立人工智能物流产业联盟。 中国机械工程学会副理事长兼秘书长、人工智能物流产业联盟理事长陆大明表示,“以旷视为代表的的诸多企业借助新技术,联合客户积极创新,不断孵化出新的产品与行业解决方案。AI+物流的全新业态需要众多合作伙伴共同培育,相信联盟的成立一定会助推这个行业快速成长”。 作为人工智能行业务实者与领导者,旷视将坚定投入、深耕智慧物流领域,助力企业降本增效、简化管理,不断为物流行业的智慧发展创造新的价值。旷视始终相信,人工智能终将造福大众,也必将成为物流行业发展的新引擎。

    时间:2020-10-25 关键词: AI 智慧物流 互联网

  • Impala在网易大数据的优化和实践

    文章作者:温正湖 网易杭研 编辑整理:张博 出品平台:DataFunTalk 导读: 网易大数据平台的底层数据查询引擎,选用了Impala作为OLAP查询引擎,不但支撑了网易大数据的交互式查询与自助分析,还为外部客户提供了商业化的产品与服务。今天将为大家分享下Impala在网易大数据的优化和实践。 01 Impala的定位及优势 Impala有哪些优势,让我们选择Impala作为网易内部的OLAP查询引擎? 1. Impala在数据处理中的角色 先来看一下Impala在数据处理中的角色。 对于数据量较少的场景,例如百万数据以下的情况,可以采用传统的关系型数据库,如MySQL或者PostgreSQL等,或者一些文档数据库,比如MongoDB等。随着数据量的增大,达到上亿级别时,一般选择分析型数仓来存储,并使用OLAP引擎来查询。此等规模的数据查询,对响应时间的要求虽然比关系型数据库要低,但一般也要求在秒级返回查询结果,不能有太大的延迟。Impala、Presto、Greenplum等都在此列。当规模继续扩大到上百亿以上时,则会选择批处理引擎,如Hive、Spark来进行数据处理。 今天分享的Impala就是针对分析型数仓的查询引擎。分析型数仓有很多种建模方式。 以Druid和Click House为代表的宽表模型,还有以Impala等为代表的星型/雪花型的建模方式。我们将Impala作为通用的查询引擎,比较典型的应用场景有自助数据分析、BI报表等。在分享的第三部分,有关于Impala在网易大数据平台“猛犸”中的介绍,以及在网易云音乐中的实际使用场景的说明。 2. Impala的优势 网易为什么选择Impala作为OLAP查询引擎,Impala到底有哪些优势?Impala的优势,总结起来包括: MPP 架构,去中心化 优秀的查询性能 友好的 WebUI 界面 完全兼容 Hive 元数据 Apache 顶级项目,社区活跃度高 支持多种数据格式( Parquet/ORC 等) 与 Kudu 结合使用,实时数仓 ① 去中心化的MPP并行架构 相比于传统的关系型数据库,MPP架构可以充分发挥多服务器的特点,将数据量比较大的操作,分散在多台服务器上并行处理。这些复杂的大数据量的操作,对于单台服务器来说是无法完成的任务。 Impala还区别于其他MPP架构的引擎的一点,是Impala有多个Coordinator和Executor,多个Coordinator可以同时对外提供服务。多Coordinator的架构设计让Impala可以有效防范单点故障的出现。 ② 优秀的查询性能 Impala支持CBO(基于代价的执行优化),除此之外,Impala还对Catalog进行了缓存。缓存的信息包括:库和表的信息、HDFS数据库、统计信息等。元数据都缓存在了Impala内部,在做CBO时,能够发挥更大的优势,做出更优的选择。除此之外,Impala同时具有典型的OLAP引擎应有的特征:静态代码生成支持LLVM、JIT;支持HDFS本地读区,减少访问NameNode、DataNode和数据网络传输的开销,对性能有比较大的提升;还有算子下推,runtime filter在Join时,对与join条件之外的列可以进行动态过滤。 从我们实际使用效果来说,Impala性能优势非常明显。前段时间我们对Impala、presto和spark3.0进行了对比测试。测试用例选择tpcds,并行节点8个。 总的来说,Impala相比Presto有明显的优势,相比Spark 3.0也有一定的优势。Spark 3.0对性能做了很多优化和改进,相比之下Impala性能有一些优势,不过Impala因为支持的SQL类型少一些,有一些tpcds的测试用例并不能完成。 ③ 友好的WebUI界面 一般来说,大数据查询引擎的查询计划,比关系型数据库的查询计划复杂的多。Impala提供了一个比较友好的WebUI,在这个界面上,能看到完整的执行计划、内存使用情况、异常查询分析,也可以通过界面终止查询语句。 此外,Impala的优势还体现在:完全兼容Hive元数据、Apache顶级项目有较高的社区活跃度、支持多种数据格式(Parquet、ORC等)、可以与Kudu结合使用等。 02 对Impala的一些增强和优化 在我们生产实践中,也发现了Impala的一些不足,因此网易大数据团队对Impala进行了一些优化和增强。包括以下几个方面: Impala 管理服务器 元数据同步增强 基于zookeeper的服务高可用 支持更多存储后端 其他增强和优化 1. Impala管理服务器 Impala已经提供了WebUI的情况下,为什么需要一个管理服务器? 其中一个原因,是社区版的WebUI是非持久化的,一旦Impalad异常退出,这些信息都会丢失。 我们通过MySQL存储WebUI上的信息,将统计信息、执行信息等重要信息保存到MySQL数据库中,实现持久化保存。在此基础上,管理平台给我们带来许多增值收益。相比于原生的WebUI,增强版的WebUI可以汇总各个coordinator执行的SQL语句,直观展示当前执行的SQL。 还可以作为集群持续优化的平台。因为记录了历史执行的SQL,可以为后续SQL优化提供依据,比如集群SQL的性能指标、随时间变化的性能表现,以及大部分SQL的执行时间。通过统计SQL执行失败的次数,出错SQL,为定位和回溯问题提供帮助。 2. 元数据同步增强 Impala对元数据的缓存,一方面大幅提升了查询性能,但另一方面,元数据更新也带来了新的问题。因为数据可以不通过Impala客户端,而通过其他组件比如Hive进行更新,这就让Impala无法感知到元数据的更新。而老旧的元数据会导致查询失败或者性能下降。因此,需要一个机制能够让Impala及时感知元数据的更新。社区版提供了INVALIDATE METADATA这一命令,可以手动刷新元数据。不过如果一些用户不熟悉这个操作,没有更新Impala缓存的元数据,就会导致查询的问题。怎么解决这样的问题? 网易对此进行优化,引入了元数据自动同步机制:在Hive进行DDL相关操作时,记录操作日志,Impala通过消费操作日志,进行必要的Invalidate Metadata的操作,无须人工操作,大大提高了元数据缓存的可用性和实时性。对于提升Impala的查询性能,降低查询错误都有很大的帮助。 另外一个是元数据的黑白名单机制,配合Impala不同的元数据加载方式。对于启动时加载元数据的,配置黑名单,屏蔽不需要通过Impala查询的表;对于延迟加载元数据的,配置白名单,即刻加载元数据,避免首次查询时延迟过大。 另外需要提醒的是,Impala 3.x版本在元数据缓存管理上有了极大的改进,网易大数据团队也在调研中,准备从2.12升级到3.4版本。 3. 基于ZK的服务高可用 虽然每一个Impalad都可以作为Coordinator,对外提供访问服务,接受客户端请求,但是缺乏一个路由机制。当一个client连接的特定coordinator失效之后,就无法在进行查询了。 网易大数据团队参考Hive的实现,引入zookeeper作为访问代理,客户端首先通过zookeeper找到可用的coordinator节点,然后再提交SQL查询请求。通过这种方式,提供了更健壮的查询服务模式。 4. 支持更多存储后端 对于后端存储的支持,网易团队增加了对iceberg表的创建和查询的支持。已经在云音乐业务上使用,并且贡献给了Impala社区。 其他后端还包括对Alluxio的支持,使用Alluxio作为Impala和HDFS之间的二级缓存。这方面的详细信息,可以搜索《网易严选:基于 Alluxio+Impala 深度融合架构的 BI 系统性能优化实践》。 此外对接Elastic Search查询,充分发挥了ES倒排索引的优势。 5. 其他增强和优化 其他的增强还有:权限的优化、Hive多版本适配、支持JSON,以及社区版的一些Bug修正。 03 Impala在网易的使用案例分析 1. Impala的部署和使用 Impala两种部署方式:混合部署与独立部署。混合部署是指Impala和其他大数据组件共用HDFS。而独立部署则是为Impala配置独立的HDFS。独立部署的优势在于IO和网络通信都有保障,对性能和稳定性的提升有帮助。但是代价也十分明显:成本上升。 Impala与Kudu结合,可以用来构建实时数仓。Kudu增量写入,定期保存到HDFS。Kudu的使用一方面提供了更新数据和删除数据的能力,另一方面也解决了HDFS上小文件的问题。而Impala可以同时查询Kudu和HDFS上的数据。 网易内部对集群的监控,对接了网易内部的哨兵服务。可以提供准实时的告警能力。运维人员通过设置阈值,订阅告警信息,从而了解集群的监控程度。 此外,对于Impala集群的部署和使用,还有几点需要注意: 按照大业务划分不同的集群 按照不同的子业务或者 SQL 类型划分队列 coordinator 节点与 executor 节点分开部署 对于机器数比较少的集群,机器上可部署多个节点,增加并发 业务方重试机制,以免 impalad 节点挂掉导致 SQL 失败 通过 impala hint 改变表的 join 方式 结合实际情况参考是否设置 mem_limit ,设置多大 mem_limit 2. 网易大数据中的Impala 在网易大数据平台“猛犸”中,Impala位于数据计算层,提供交互式查询的能力,对应的应用场景是自助分析。 在网易对外提供的产品和服务中,复杂报表和自助取数,都用到了Impala。其中自助分析服务适用于有一定SQL基础的用户,通过自己写SQL语句,查询数据。灵活性比较大,同时门槛也比较高。 网易有数的自助取数服务(easyFetch)可以通过拖拽维度和度量,方便的获取数据,并生成图表报告。后端对接的是网易有数的API。非常适合非专业人员使用数据,发挥出数据的生产力。 网易现在内部有8个Impala集群,超过200个节点,最大集群规模超过60个节点。除了内部服务外,对外的商业化服务,已经有超过20个Impala集群。 3. Impala在云音乐的使用实践 网易云音乐,有2个Impala集群,超过60个节点的规模。主要的应用场景包括:有数报表、自助分析、音乐版权、A/B测试,easyFetch等等。绝大部分应用场景下,Impala的查询时间不超过2秒。 云音乐A/B测试早期使用Spark按照小时粒度,完成从ODS到DWD层的数据清洗工作,之后生成用户分流表和指标统计表,再使用Spark关联这两张表的结果写入到Kudu中,最后使用Impala对接数据,供用户查询。这样数据延迟至少1~2小时,有些结果甚至在第二天才能看到。但是对于A/B测试,能够实时看到结果才是最好的。 对此云音乐团队基于Flink做了实时性改造。将DWS变成流表,这样Impala可以同时查询T+1的结果表和流表中的实时数据。A/B测试的效果就可以近实时的看到了。 今天的分享就到这里,谢谢大家。 在文末分享、点赞、在看,给个三连击呗~~ 嘉宾介绍: 温正湖 网易杭研 | 高级数据库技术专家 杭研大数据产品中心OLTP&OLAP内核团队负责人。10年数据库和存储开发经验,专注于数据库、数仓技术和分布式系统架构;累计申请10+技术发明专利 ( 已授权8个 ),《MySQL 内核:InnoDB 存储引擎 卷1》作者之一。 特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:长按订阅更多精彩▼如有收获,点个在看,诚挚感谢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-25 关键词: 查询引擎 互联网

  • 架构师说了:不想做背锅侠?生产问题要这样查

    话说这天一大早,那个悲催的中年架构师大刘又被手机微信群给炸醒。部门的运维兄弟在公司微信群里说: 短信的生产环境服务器 CPU 占用率过高,疯狂报警。是不是你们昨天上线看门狗导致的? 大刘迷了巴登的想了想,没错,昨天确实给短信服务装上了看门狗。但是看门狗服务肯定不会有问题(架构师必备的蜜汁自信),而且上线之前各轮测试也都测过了,没见过这个想象啊。 难道是测试妹子没测试到位?难道线上短信应用自身出现了问题? 生产无小事,小事更不能忽视,主要是怕扣绩效奖金。大刘迅速打开电脑,打开 VPN ,远程登上短信生产服务器,开始大刘最拿手的 2W1H 三板斧诊断之旅。 接下来的诊断内容有点烧脑,节奏有点快,请大家坐稳扶好。 1. 病号是谁(WHO)? 大刘拿出控制台诊断仪器,输入 top 命令一探究竟。我勒个去,不看不知道一看吓一跳,PID 为 1878 的病号,CPU 占用居然 200% 多。 问题算是定位到了,但是 PID 为 1878 的病号到底是谁,难道真是昨天上线的看门狗 ? 虽然大刘久经职场,但是排查生产问题时,内心还是比较忐忑,毕竟这是生产环境。 说时迟那时快,只见大刘一个命令输入: ps -ef | grep 1878 定睛一看,原来是放屁瞅别人,短信服务自己在作祟,和看门狗没关系,大刘心里一下子平缓了不少。 锅找到了主儿,其实这个时候大刘完全可以把这个问题甩给短信开发团队,但是大刘最喜欢做的不是甩锅,而是打破砂锅刨到底。 2. 病号哪里出了问题(WHERE)? 为什么 1878 号病人占用 CPU 会这么高呢? 只见黑乎乎的控制台诊断仪器上,大刘熟练的输入: jstack -l 1878 >> 1878号病历.log 这样便得到一份 1878 号病人的病历详情单,一会儿用得上。 到底 1878 号病人的哪个部位出了问题呢? 话没说完,只见大刘又在控制台诊断仪器上,输入一个: top -Hp 1878 白板黑字,把 1878 号病人的器官信息全部列了出来。 看到结果,甚是一惊,PID 代号为 8721 的器官占用 CPU 100% 多。 疑惑油然而生,这个 PID 代号 为 8721 的器官是啥,是头、是眼睛、还是胳膊腿呢?这些器官展示的 PID 列都是昵称,都这么善于伪装,如何揭露它的真面目呢? 还好大刘有高招,借助照妖镜算法,熟练的输入: printf "%x\n" 8721 果真使得代号为 8721 的器官,现了真身,真实身份居然是 2211 的呼吸道,怪不得病号一直气喘吁吁,上气不接下气。 到这一步还无法对症下药啊,还需要进一步确诊 2211 的呼吸道到底出了什么幺蛾子,导致 1878 号病人一直气喘吁吁,上气不接下气? 只见黑乎乎的控制台诊断仪器上,大刘再次飞一般的在输入: grep 2211 -A20 1878号病历.log 诊断结果随之显示在诊断仪器上。 曾经背了很多锅的大刘,看到诊断结果心里乐了一下,一眼就看出是高并发情况下用了 HashMap 的问题(请大家们自行寻找谷歌、百度,就不在此深入展开啦),终于拨开云雾见青天。 3. 如何对症下药( HOW )? 在大刘行云流水没有一丝一毫的拖泥带水般的神操作下,1878 号病人的诊断也就结束了,这个锅就彻底被打破了。 术业有专攻,大刘就可以郑重的告诉短信开发同事具体原因了,捉得病根,开发同事也就可以对症下药啦。 大刘这套行走江湖的诊断问题方式你 get 到了没?大刘自己简单概括为 2W1H 三板斧:病号是谁、病号哪里出了问题、对症下药。 1、病号是谁?(WHO) 第一步:采用 top 命令,找出 CPU 占用最高的病号 PID ; 第二步:通过 ps -ef | grep PID 查看病号对应的真实身份。 2、病号哪里出了问题?(WHERE) 第一步:采用 jstack -l  PID >> PID.log  获取病号的各器官信息的病历单; 第二步:采用 top -Hp PID 拿到占用 CPU 最高的器官昵称 PID ; 第三步:采用 printf "%x\n" PID  根据器官昵称 PID 的拿到器官真实身份 TID ; 第四步:采用 grep TID -A20 pid.log 根据 TID 去病历单中匹配,确定是哪出了问题。 3、捉得病根、便可拿出医药箱,对症下药啦。(HOW) 作为程序猿,工作中难免会遇到不少类似这样的问题。面对问题,你如果像无头苍蝇一样乱撞,撞得头破血流依然不知道缘由,在背锅即将成为现实时,那就不妨试试大刘的 2W1H 三板斧的诊断方式,说不定会帮你快速定位、解决线上问题,毕竟快速的解决生产问题会把损失降到最低。 最后,想对大家说一句: 作为程序猿,一定要有程序猿的态度。避免背锅,拒绝甩锅,打破砂锅,从你我做起。 长按订阅更多精彩▼如有收获,点个在看,诚挚感谢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-25 关键词: 嵌入式 互联网

  • 一程序员竟放弃百度offer,回老家进烟草公司……

    请点击上面  一键关注! 程序员去哪里工作最好?有人说当然是bat,还有字节跳动等一系列新兴互联网公司,这可是互联网的头部大厂,福利待遇好,个人资历也好看。但也有的人不这么认为,做出了其他选择。 一个程序员吐槽自己班上的程序员大佬,毕业后竟然放弃了百度offer,回到老家的一个烟草公司上班,怕不是脑子有坑吧?实在无法理解这个选择。 没想到网友们纷纷开骂楼主,感觉你才脑子有坑呢! 网友们说楼主还是太年轻,幼稚,自己刚毕业时也这么想,几年后活明白了就不这么想了。 骂完楼主,网友们又开始夸那个程序员大佬,选择明智,是个明白人,想的通,这才是真正的大佬! 还有网友表示如果自己也能进烟草公司,还去什么bat,但凡烟草公司要自己,立马回老家。 现在的百度配和烟草公司比吗?楼主的脑回路真奇怪!是不是在逗大家伙? 感觉楼主都被大家说懵了,烟草公司怎么了?为什么大家反应这么强烈?热心网友在线解答,烟草公司上班时间短,工作内容少,福利待遇好,底层员工一年都能到手近20万,配套学校随便进。程序员上班就是种菜养鱼,出了问题就找外包公司,工作内容就是换软件装系统,不要太爽啊! 说到烟草公司的待遇,网友们表示“烟草公司是最挣钱的”!烟草公司是垄断企业,一年交税都高达11000亿,比百度待遇高多了! 也有人说烟草公司的工作内容就是打牌和抽烟,这是不是有点夸张了……不过可以从中想象烟草公司的工作内容有多美好。 等到几年以后,程序员大佬朝九晚五,头发不掉,随时休假,楼主却头发半秃,满脸油光,每天凌晨还在工位上熬,收入却比他还低。 大概就因为这些原因,烟草公司太难进了,想进都进不去,普通人根本高攀不起,不是一般央企和国企能比的。 网友一句话总结:烟草公司,国内没有任何自己公司配当我的对手。怎么样?有没有一种独孤求败的意思? 舒服的地方不只是烟草公司一家,网友总结出这些:两石三网四大行,外加一个大烟草。中石油,中石化,移动,联通,电信,烟草,这些闪闪发光的名字,闪瞎了众多网友的眼,要是能进任何一家都好~ 新兴行业不一定就是好的,传统行业不一定就是不好的。有些公司听起来光鲜,实际上也许没那么好,有些公司听起来好像没什么,但实际上却暗藏玄机。 建议找工作的网友们一定要好好了解,擦亮眼睛,别被外在的东西蒙蔽。 祝大家都能找到钱多事少安稳的好工作,进入提前退休的幸福生活! 特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:长按订阅更多精彩▼如有收获,点个在看,诚挚感谢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-25 关键词: 程序员 互联网

  • 外包员工VS正式员工,福利待遇是否一样?

    请点击上面  一键关注! 互联网公司里常有外包员工,外包员工承担的工作和正式员工差不多,但福利待遇是否一样呢? 这家互联网公司的聊天截图说明了外包员工的地位,不是正式员工,连公司零食都没资格吃,还被人上升到素质的高度,太惨了吧!       网友们都被气笑了,瞧瞧这是什么用词,还“偷吃”,难道不是光明正大地吃吗?公司零食买来就是给员工吃的,又不是什么值钱的东西,吃了又怎么样?难道说外包员工不配吃零食?已经吃了,有本事从嘴里扒出来! 网友一句话道破外包员工的心酸——亲生的和非亲生的差别就是大,福利待遇各方面都不相同,外包员工心里肯定不舒服,这家公司的格局也不大,一点零食还斤斤计较。 有网友说不是所有外包员工都被区别对待,自己以前外包到滴滴时,天天吃零食吃到吐也没人说。这位网友请注意自己的胃,零食再好吃也别贪嘴…… 有人说自己是外包员工,中秋礼品还能领到两份,挺好。 还有人说外包员工6点下班,他作为正式员工却要加班到9点,这么看来好像正式员工更惨一点…… 可能大部分人都像这位网友所说,对外包员工还是比较友好的。 不过也有许多外包员工跳出来痛诉革命家史,有人说外包员工不能进本部园区,还得本部员工领着才能进。 有人说所在小组被评为优秀小组,但名单上却没有外包员工,端午福利外包员工啥也没有,外包工作毫无意义。 有人说月饼礼盒都只给正式员工,外包员工没有。 有人说被外包之后,不仅工作时间延长,端午节发粽子也没有,工作上也不被信任,这辈子都不想被外包,打死也不做外包员工了! 一个有五年外包经验的员工说,外包就是外包,福利待遇、归属感、学习和发展机会、别人的看法等都不是很好。外包会挑战人的苟活能力,低人一等,刚毕业的人最好不要去外包。 其实外包员工和正式员工都是给公司打工的,没人比别人低一等,就像这位网友所说,出了公司大门大家都一样。 外包员工和正式员工一样,都为公司做贡献,活不少干,力没少出。作为公司,最好格局大一点,别为了蝇头小利斤斤计较,区分对待,伤了员工的心,最后损害的还是公司利益。 作为外包员工,也别因为别人的区别对待就觉得自己低人一等,在心里摆正自己的位置,提升自己的能力,时刻做好准备,抓住机会去更好的公司和岗位。 你是否做过外包员工?欢迎留言分享你曾经的荣耀时刻和辛酸时刻! 特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:长按订阅更多精彩▼如有收获,点个在看,诚挚感谢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-25 关键词: 程序员 互联网

  • 请永远记住 “网景” 公司,互联网的缔造者!

    想象一下,一个没有百度、没有谷歌、没有阿里巴巴、没有腾讯、没有宽带的世界,几乎没有人听说过互联网是什么,这就是20多年前的现实。真正把我们带入互联网时代的是一个辉煌的昙花一现的公司:网景,它是真正引发互联网繁荣的火花。 1995年8月9日,星期三,硅谷一家成立16个月的初创公司网景准备上市,由于当时市场需求极度火爆,在当天早上将近两个小时的时间里,交易都无法开始,股票当时的定价是每股28美元,开盘当天一度飙升至75美元,最终收盘58美元。 这是开始,也是结束。 img标签的诞生 1992年11月,全球已知的万维网服务器只有26台,其中一台位于美国伊利诺伊大学厄巴纳-香槟分校(UIUC)的美国国家超级计算机应用中心(NCSA),两个月后,服务器的数量几乎翻了一番,达到50台。按照互联网的标准来看,这种增长速度是非常可观的,但是同时数量来看也就那样,Web仍然只是运行在网络上的众多应用程序之一,与电子邮件、 FTP 和所有其他在网络上运行的东西相比,HTTP的流量仍然只是小菜一碟。然后,仿佛一夜之间,一切都改变了,彻底改变了... ... 1993年春天,伊利诺伊州的一名学生发布了一款浏览器,他是一个改变Web历史的开端,它被称为Mosaic(没错,这就是后来的网景浏览器,中文翻译可以叫做马赛克... ...)。 创建 Mosaic 背后的主要驱动力可能是无聊,安德森厌倦了给万恶的资本家每天CRUD的工作。从1993年1月开始,持续不到三个月的时间,安德森和他的另外一位同事创造出了“Mosaic”,而代码只有9000行。 此后,Mosaic的UNIX版本像野火一样在全球计算机界传播开来,Mac和PC版本紧随其后。在几个月内,据估计(在那个阶段没有人保持精确的记录)下载量达到了数十万次,在1993年3月,也就是正式发布的一个月后,在UNIX浏览器的Alpha版本中,Web流量仅占被称为NSF骨干网的 Net 流量的0.1% ,到9月份,已知的服务器已经超过200台,Web流量占骨干网流量的1% ,也就是说,它在5个月多一点的时间里翻了10倍。 Mosaic并不是第一个浏览器,但它却是占领了市场并塑造了未来的浏览器。它是第一款看起来像现代个人电脑软件的浏览器,因为它有按钮、滚动条和下拉菜单等等现代化的东西。但也许Mosaic最重要的一点是,一个新的 HTML 元素“ img”诞生了 ,这样一来,网页第一次可以将图片和文本放在一起。 当时,决定扩展 HTML 以这种方式处理图像在某些方面是有争议的,主要是因为图像文件往往比文本文件大得多,许多人认为传输图像是对稀缺带宽的浪费,并且认为过多的图片会导致整个网络的瘫痪,但是安德森坚持认为,人们不会用无聊的图像文件淹没网络,而即使他们这样做了,他认为可以增加系统的负载能力来解决这个问题。 这个项目像野火一样蔓延到了全世界,与此同时,使用网络的人数开始呈指数级增长。随着用户数量的增加,服务器的数量也在不断增加,随着人们发现用 HTML 的便利性,网络用户可获得的信息量开始呈指数级增长,这是一个典型的正反馈循环。此后两年的时间里,涉及网页的互联网流量从几乎为零增长到了总流量的近四分之一。 网络的传播就像以前的通信技术传播的过程一样。早期的电话,人们不愿意对这项新技术进行投资,因为使用电话的人太少了,没有任何投资的价值,电子邮件也是一样。我该给谁发电子邮件呢?在电子邮件发展的早期,这是非学术界人士的普遍哀叹。但是,一旦一个人所在的知识、职业或社交群体中的用户数量突破了临界值,突然之间,电话、电子邮件就成了必需品。 在安德森而言,他并不知道,他创造的Mosaic是一团点燃Web的火花,而他马上也要成为富二代他爸爸了。 Javascript和SSL以及24岁的亿万富翁 1994年1月,吉姆 · 克拉克,1974年的斯坦福大学博士,他离开了自己一手创立的硅谷图形公司(SIG),和很多创业成功套现离场的人一样,接下来想干一票大的了。机缘巧合,他从同事那里看到了Mosaic,此后的事情就很简单了,克拉克有钱,创业精英,有人脉,有资源,安德森懂产品,会编程。 网景公司成立了。7个员工,每人1%的股份。安德森则成为了新公司的VP,持有2.6%的股份。 由于来自NCSA的Mosaic版权问题,他们必须做出一个全新的改进版本的Mosaic。此后,每周七天,每天十八小时编写、调试代码,靠着垃圾食品和肥宅神仙水,在12个月内,克拉克解雇了15个员工,花光了所有资金,终于推出了“网景浏览器”。 网景浏览器一经推出便大获成功,除了界面操作简单之外,还有前所未有的安全性,因为他们创造了SSL协议,这为未来的浏览器安全奠定了基石 。 除此之外,他们创造出了迄今为止仍然最火热的前端脚本语言:Javascript。 克拉克和安德森考虑到真正的收入来自于出售服务器软件,于是决定在网上免费赠送浏览器程序(搞清楚,你不可能去网上下载一个浏览器,因为你都没有浏览器... ...),许多公司为了在他们所有的台式机上安装浏览器购买了多种许可证,加上服务器软件的销售收入,在浏览器发布后的头两个星期内,网景总收入达到了36.5万美元。第二季度,电销金额高达1200万美元。在4个月内,网景在全球浏览器市场的份额从零增长到75% ,这是资本主义历史上市场份额增长最快的一次。 在选择使用网络作为他们的分销工具时,安德森和克拉克也将计算机行业带入了快进模式。以前,新产品的扩散速度受到制造和分销的惯性和滞后的限制。但是,通过摒弃传统产品的所有包装、仓储、运输和广告,网景开启了一个新时代:今天你可以完成一个产品,明天就可以拥有成千上万的用户。这其中的意义是无法估量的。 1995年8月9日,网景通信公司上市,最开始股价定在每股28美元,开盘当天一度飙升至75美元,最终收盘58美元,克拉克身价达到5.66亿美元,而安德森身价:5800万美元,不久之前,他还不过是一个刚刚毕业在一家公司写着代码的普通程序员,转眼间,换算成人民币的话,他已经是身价过亿的亿万富翁了,而且,随着网景的上市,安德森也登上了时代杂志的封面,这个男人,恐怖如斯。 根据《华尔街日报》表示,美国国防企业通用动力花了43年时间才达到27亿美元的估值,而网景呢?1分钟!历史上第一次,网景向世人证明了一个深深植根于虚拟世界的公司在真实世界中可能价值数十亿美元。 天堂与地狱 24岁的亿万富翁,再创业成功的神话,一夜之间科技界和媒体的宠儿,小说里的情节大概也就这样了吧。然而太过优秀,并非好事。 一段时间之内,网景疯狂扩张,到1995年12月,股价已经来到了170美元,而公司员工数量也达到了2000人,网景的高管们好像也已经飘了,他们开始告诉外界,网景浏览器就是计算机的未来,他们说,总有一天,当人们开机时看到的第一件事就是浏览器。而他们也推出了网景2.0版本,可以发送邮件、浏览网页等等,一个浏览器提供了用户需要的一切功能,安德森和他的团队说,这就是未来的发展方向——浏览器最终将成为操作系统。 而此时的微软,我们的世界首富比尔盖茨先生终于醒悟了,网景在逆天。在此之前,我们的首富先生二把手史蒂夫•鲍尔默先生连TCP/IP是啥都没听说过。没错,就是那个鲍尔默,快船的老板。 当时微软还没有浏览器产品,所以微软做了在这种情况下一贯做的事情... ...直接买了一个,然后重新命名叫做IE1.0。事实上,微软从一家名为 Spyglass 的公司获得了浏览器软件的许可,在此之前,望远镜公司曾与伊利诺伊大学厄巴纳香槟分校达成协议,获得 Mosaic 及其底层技术的授权。然后从1995年8月新操作系统发布的那一刻起,它就与Windows 95的每一个版本捆绑在一起了。 而对于网景来说,1995年8月9日就是他们的死刑日。比尔盖茨用行动告诉世人,沉睡的巨龙已经醒来。 后来为我们所熟知的“浏览器大战”已经开战,这就好像我们知道的3Q大战一样,王者打青铜,吊着打的那种。在这种级别的战斗中,就比谁能坚持到最后,比的就是钱多。微软有着堆积如山的现金,没有债务,而且收入源源不断。它可以在一整年不赚一分钱的情况下生存下去,因此,在其他条件相同的情况下,微软必将获胜。 大战开始后,网景股票大幅下滑,他们想重新定位公司的出路,他们想将重点放在企业内部市场、网络服务和其他可能有利可图的业务上,他们发布的Communicator包含了浏览器、实时会议、电子邮件、日记管理、日程安排一整套的东西,网景试图想用户传达“忘掉浏览器吧,我们已经转向了更高层次的东西。”。 然而,在微软面对全世界电桌面电脑的垄断面前,一切都是徒劳的挣扎罢了。他们已经不是互联网Web行业的标准了。 微软做的事情很简单,就是复制,网景做什么,我就做什么,就是用Windows让用户免费用IE。即便这种做法让微软收到了反垄断诉讼,也只不过让网景苟延残喘罢了。 这公平吗?是安德森和克拉克看到了Web的潜力,并且他们成功了一段时间,而可能在比尔盖茨的眼里,公不公平有什么关系呢?这是生意啊,小傻瓜。 遗产 1998年1月22日,网景通信公司发表了一份新闻声明,宣布决定开放网景Communicator的源码,这就意味着网景浏览器完全开源了,同时未来的网景浏览器也将免费,他们寄希望通过开源的方式重新获得市场。 而后,在宣布开源的当晚,网景注册了“mozilla.org”域名,后来孕育出了Mozilla基金会,这同时也是后来的Firefox浏览器诞生的基础,(Mozilla的故事在另外一篇文章中有描述)。这或许是另外一种对微软的复仇方式。 在1998年5月美国司法部提出了对微软的反垄断诉讼,但是此时一切为之晚矣,同年11月,美国在线AOL以42亿美元的估值收购了网景,而在1999年,网景的估值已经达到了100亿美元,2008年,AOL宣布放弃对网景浏览器的支持,一代传奇落下帷幕。这对安德森和克拉克来说至少也不错,至少他们还有AOL的股票,至少他们的起点比大多数人高的太多了。 虽然网景消失了,但是从安德森开始,从img标签开始,到创造javascript,开创SSL,奠定了未来几十年的互联网Web基础,当年的星星之火现已燎原。 正所谓三年五载不作数,胜负成败又何妨,你擎苍天作玉柱,我架瀚海紫金梁,有何惧,但见你,蛰龙云中起,一瞬迎风百万里! —————END————— 喜欢本文的朋友,欢迎关注公众号 程序员小灰,收看更多精彩内容 点个[在看],是对小灰最大的支持! 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-25 关键词: 网景通信 互联网

  • 今日头条、抖音推荐算法原理全文详解!

    本次分享将主要介绍今日头条推荐系统概览以及内容分析、用户标签、评估分析,内容安全等原理。 一、系统概览 推荐系统,如果用形式化的方式去描述实际上是拟合一个用户对内容满意度的函数,这个函数需要输入三个维度的变量。 第一个维度是内容。头条现在已经是一个综合内容平台,图文、视频、UGC小视频、问答、微头条,每种内容有很多自己的特征,需要考虑怎样提取不同内容类型的特征做好推荐。 第二个维度是用户特征。包括各种兴趣标签,职业、年龄、性别等,还有很多模型刻划出的隐式用户兴趣等。 第三个维度是环境特征。这是移动互联网时代推荐的特点,用户随时随地移动,在工作场合、通勤、旅游等不同的场景,信息偏好有所偏移。 结合三方面的维度,模型会给出一个预估,即推测推荐内容在这一场景下对这一用户是否合适。 这里还有一个问题,如何引入无法直接衡量的目标? 推荐模型中,点击率、阅读时间、点赞、评论、转发包括点赞都是可以量化的目标,能够用模型直接拟合做预估,看线上提升情况可以知道做的好不好。 但一个大体量的推荐系统,服务用户众多,不能完全由指标评估,引入数据指标以外的要素也很重要。 比如广告和特型内容频控。像问答卡片就是比较特殊的内容形式,其推荐的目标不完全是让用户浏览,还要考虑吸引用户回答为社区贡献内容。这些内容和普通内容如何混排,怎样控制频控都需要考虑。 此外,平台出于内容生态和社会责任的考量,像低俗内容的打压,标题党、低质内容的打压,重要新闻的置顶、加权、强插,低级别账号内容降权都是算法本身无法完成,需要进一步对内容进行干预。 下面我将简单介绍在上述算法目标的基础上如何对其实现。 前面提到的公式y = F(Xi ,Xu ,Xc),是一个很经典的监督学习问题。可实现的方法有很多,比如传统的协同过滤模型,监督学习算法Logistic Regression模型,基于深度学习的模型,Factorization Machine和GBDT等。 一个优秀的工业级推荐系统需要非常灵活的算法实验平台,可以支持多种算法组合,包括模型结构调整。因为很难有一套通用的模型架构适用于所有的推荐场景。 现在很流行将LR和DNN结合,前几年Facebook也将LR和GBDT算法做结合。今日头条旗下几款产品都在沿用同一套强大的算法推荐系统,但根据业务场景不同,模型架构会有所调整。 模型之后再看一下典型的推荐特征,主要有四类特征会对推荐起到比较重要的作用。 第一类是相关性特征,就是评估内容的属性和与用户是否匹配。显性的匹配包括关键词匹配、分类匹配、来源匹配、主题匹配等。像FM模型中也有一些隐性匹配,从用户向量与内容向量的距离可以得出。 第二类是环境特征,包括地理位置、时间。这些既是bias特征,也能以此构建一些匹配特征。 第三类是热度特征。包括全局热度、分类热度,主题热度,以及关键词热度等。内容热度信息在大的推荐系统特别在用户冷启动的时候非常有效。 第四类是协同特征,它可以在部分程度上帮助解决所谓算法越推越窄的问题。 协同特征并非考虑用户已有历史。而是通过用户行为分析不同用户间相似性,比如点击相似、兴趣分类相似、主题相似、兴趣词相似,甚至向量相似,从而扩展模型的探索能力。 模型的训练上,头条系大部分推荐产品采用实时训练。实时训练省资源并且反馈快,这对信息流产品非常重要。用户需要行为信息可以被模型快速捕捉并反馈至下一刷的推荐效果。 我们线上目前基于storm集群实时处理样本数据,包括点击、展现、收藏、分享等动作类型。 模型参数服务器是内部开发的一套高性能的系统,因为头条数据规模增长太快,类似的开源系统稳定性和性能无法满足,而我们自研的系统底层做了很多针对性的优化,提供了完善运维工具,更适配现有的业务场景。 目前,头条的推荐算法模型在世界范围内也是比较大的,包含几百亿原始特征和数十亿向量特征。 整体的训练过程是线上服务器记录实时特征,导入到Kafka文件队列中,然后进一步导入Storm集群消费Kafka数据,客户端回传推荐的label构造训练样本,随后根据最新样本进行在线训练更新模型参数,最终线上模型得到更新。 这个过程中主要的延迟在用户的动作反馈延时,因为文章推荐后用户不一定马上看,不考虑这部分时间,整个系统是几乎实时的。 但因为头条目前的内容量非常大,加上小视频内容有千万级别,推荐系统不可能所有内容全部由模型预估。 所以需要设计一些召回策略,每次推荐时从海量内容中筛选出千级别的内容库。召回策略最重要的要求是性能要极致,一般超时不能超过50毫秒。 召回策略种类有很多,我们主要用的是倒排的思路。离线维护一个倒排,这个倒排的key可以是分类,topic,实体,来源等。 排序考虑热度、新鲜度、动作等。线上召回可以迅速从倒排中根据用户兴趣标签对内容做截断,高效的从很大的内容库中筛选比较靠谱的一小部分内容。 二、内容分析 内容分析包括文本分析,图片分析和视频分析。头条一开始主要做资讯,今天我们主要讲一下文本分析。文本分析在推荐系统中一个很重要的作用是用户兴趣建模。 没有内容及文本标签,无法得到用户兴趣标签。举个例子,只有知道文章标签是互联网,用户看了互联网标签的文章,才能知道用户有互联网标签,其他关键词也一样。 另一方面,文本内容的标签可以直接帮助推荐特征,比如魅族的内容可以推荐给关注魅族的用户,这是用户标签的匹配。 如果某段时间推荐主频道效果不理想,出现推荐窄化,用户会发现到具体的频道推荐(如科技、体育、娱乐、军事等)中阅读后,再回主feed,推荐效果会更好。 因为整个模型是打通的,子频道探索空间较小,更容易满足用户需求。只通过单一信道反馈提高推荐准确率难度会比较大,子频道做的好很重要。而这也需要好的内容分析。 上图是今日头条的一个实际文本case。可以看到,这篇文章有分类、关键词、topic、实体词等文本特征。 当然不是没有文本特征,推荐系统就不能工作,推荐系统最早期应用在Amazon,甚至沃尔玛时代就有,包括Netfilx做视频推荐也没有文本特征直接协同过滤推荐。 但对资讯类产品而言,大部分是消费当天内容,没有文本特征新内容冷启动非常困难,协同类特征无法解决文章冷启动问题。 今日头条推荐系统主要抽取的文本特征包括以下几类。首先是语义标签类特征,显式为文章打上语义标签。 这部分标签是由人定义的特征,每个标签有明确的意义,标签体系是预定义的。 此外还有隐式语义特征,主要是topic特征和关键词特征,其中topic特征是对于词概率分布的描述,无明确意义;而关键词特征会基于一些统一特征描述,无明确集合。 另外文本相似度特征也非常重要。在头条,曾经用户反馈最大的问题之一就是为什么总推荐重复的内容。这个问题的难点在于,每个人对重复的定义不一样。 举个例子,有人觉得这篇讲皇马和巴萨的文章,昨天已经看过类似内容,今天还说这两个队那就是重复。 但对于一个重度球迷而言,尤其是巴萨的球迷,恨不得所有报道都看一遍。解决这一问题需要根据判断相似文章的主题、行文、主体等内容,根据这些特征做线上策略。 同样,还有时空特征,分析内容的发生地点以及时效性。比如武汉限行的事情推给北京用户可能就没有意义。 最后还要考虑质量相关特征,判断内容是否低俗,色情,是否是软文,鸡汤? 上图是头条语义标签的特征和使用场景。他们之间层级不同,要求不同。 分类的目标是覆盖全面,希望每篇内容每段视频都有分类;而实体体系要求精准,相同名字或内容要能明确区分究竟指代哪一个人或物,但不用覆盖很全。 概念体系则负责解决比较精确又属于抽象概念的语义。这是我们最初的分类,实践中发现分类和概念在技术上能互用,后来统一用了一套技术架构。 目前,隐式语义特征已经可以很好的帮助推荐,而语义标签需要持续标注,新名词新概念不断出现,标注也要不断迭代。其做好的难度和资源投入要远大于隐式语义特征,那为什么还需要语义标签? 有一些产品上的需要,比如频道需要有明确定义的分类内容和容易理解的文本标签体系。语义标签的效果是检查一个公司NLP技术水平的试金石。 今日头条推荐系统的线上分类采用典型的层次化文本分类算法。 最上面Root,下面第一层的分类是像科技、体育、财经、娱乐,体育这样的大类,再下面细分足球、篮球、乒乓球、网球、田径、游泳…,足球再细分国际足球、中国足球,中国足球又细分中甲、中超、国家队…,相比单独的分类器,利用层次化文本分类算法能更好地解决数据倾斜的问题。 有一些例外是,如果要提高召回,可以看到我们连接了一些飞线。这套架构通用,但根据不同的问题难度,每个元分类器可以异构,像有些分类SVM效果很好,有些要结合CNN,有些要结合RNN再处理一下。 上图是一个实体词识别算法的case。基于分词结果和词性标注选取候选,期间可能需要根据知识库做一些拼接,有些实体是几个词的组合,要确定哪几个词结合在一起能映射实体的描述。 如果结果映射多个实体还要通过词向量、topic分布甚至词频本身等去歧,最后计算一个相关性模型。 三、用户标签 内容分析和用户标签是推荐系统的两大基石。内容分析涉及到机器学习的内容多一些,相比而言,用户标签工程挑战更大。 今日头条常用的用户标签包括用户感兴趣的类别和主题、关键词、来源、基于兴趣的用户聚类以及各种垂直兴趣特征(车型,体育球队,股票等)。还有性别、年龄、地点等信息。 性别信息通过用户第三方社交账号登录得到。年龄信息通常由模型预测,通过机型、阅读时间分布等预估。 常驻地点来自用户授权访问位置信息,在位置信息的基础上通过传统聚类的方法拿到常驻点。 常驻点结合其他信息,可以推测用户的工作地点、出差地点、旅游地点。这些用户标签非常有助于推荐。 当然最简单的用户标签是浏览过的内容标签。但这里涉及到一些数据处理策略。 主要包括: 一、过滤噪声。通过停留时间短的点击,过滤标题党。 二、热点惩罚。对用户在一些热门文章(如前段时间PG One的新闻)上的动作做降权处理。理论上,传播范围较大的内容,置信度会下降。 三、时间衰减。用户兴趣会发生偏移,因此策略更偏向新的用户行为。因此,随着用户动作的增加,老的特征权重会随时间衰减,新动作贡献的特征权重会更大。 四、惩罚展现。如果一篇推荐给用户的文章没有被点击,相关特征(类别,关键词,来源)权重会被惩罚。当 然同时,也要考虑全局背景,是不是相关内容推送比较多,以及相关的关闭和dislike信号等。 用户标签挖掘总体比较简单,主要还是刚刚提到的工程挑战。头条用户标签第一版是批量计算框架,流程比较简单,每天抽取昨天的日活用户过去两个月的动作数据,在Hadoop集群上批量计算结果。 但问题在于,随着用户高速增长,兴趣模型种类和其他批量处理任务都在增加,涉及到的计算量太大。 2014年,批量处理任务几百万用户标签更新的Hadoop任务,当天完成已经开始勉强。集群计算资源紧张很容易影响其它工作,集中写入分布式存储系统的压力也开始增大,并且用户兴趣标签更新延迟越来越高。 面对这些挑战。2014年底今日头条上线了用户标签Storm集群流式计算系统。改成流式之后,只要有用户动作更新就更新标签,CPU代价比较小,可以节省80%的CPU时间,大大降低了计算资源开销。 同时,只需几十台机器就可以支撑每天数千万用户的兴趣模型更新,并且特征更新速度非常快,基本可以做到准实时。这套系统从上线一直使用至今。 当然,我们也发现并非所有用户标签都需要流式系统。像用户的性别、年龄、常驻地点这些信息,不需要实时重复计算,就仍然保留daily更新。 四、评估分析 上面介绍了推荐系统的整体架构,那么如何评估推荐效果好不好? 有一句我认为非常有智慧的话,“一个事情没法评估就没法优化”。对推荐系统也是一样。 事实上,很多因素都会影响推荐效果。比如侯选集合变化,召回模块的改进或增加,推荐特征的增加,模型架构的改进在,算法参数的优化等等,不一一举例。 评估的意义就在于,很多优化最终可能是负向效果,并不是优化上线后效果就会改进。 全面的评估推荐系统,需要完备的评估体系、强大的实验平台以及易用的经验分析工具。 所谓完备的体系就是并非单一指标衡量,不能只看点击率或者停留时长等,需要综合评估。 很多公司算法做的不好,并非是工程师能力不够,而是需要一个强大的实验平台,还有便捷的实验分析工具,可以智能分析数据指标的置信度。 一个良好的评估体系建立需要遵循几个原则,首先是兼顾短期指标与长期指标。我在之前公司负责电商方向的时候观察到,很多策略调整短期内用户觉得新鲜,但是长期看其实没有任何助益。 其次,要兼顾用户指标和生态指标。既要为内容创作者提供价值,让他更有尊严的创作,也有义务满足用户,这两者要平衡。 还有广告主利益也要考虑,这是多方博弈和平衡的过程。 另外,要注意协同效应的影响。实验中严格的流量隔离很难做到,要注意外部效应。 强大的实验平台非常直接的优点是,当同时在线的实验比较多时,可以由平台自动分配流量,无需人工沟通,并且实验结束流量立即回收,提高管理效率。 这能帮助公司降低分析成本,加快算法迭代效应,使整个系统的算法优化工作能够快速往前推进。 这是头条A/B Test实验系统的基本原理。首先我们会做在离线状态下做好用户分桶,然后线上分配实验流量,将桶里用户打上标签,分给实验组。 举个例子,开一个10%流量的实验,两个实验组各5%,一个5%是基线,策略和线上大盘一样,另外一个是新的策略。 实验过程中用户动作会被搜集,基本上是准实时,每小时都可以看到。但因为小时数据有波动,通常是以天为时间节点来看。动作搜集后会有日志处理、分布式统计、写入数据库,非常便捷。 在这个系统下工程师只需要设置流量需求、实验时间、定义特殊过滤条件,自定义实验组ID。系统可以自动生成:实验数据对比、实验数据置信度、实验结论总结以及实验优化建议。 当然,只有实验平台是远远不够的。线上实验平台只能通过数据指标变化推测 用户体验的变化,但数据指标和用户体验存在差异,很多指标不能完全量化。 很多改进仍然要通过人工分析,重大改进需要人工评估二次确认。 五、内容安全 最后要介绍今日头条在内容安全上的一些举措。头条现在已经是国内最大的内容创作与分发凭条,必须越来越重视社会责任和行业领导者的责任。如果1%的推荐内容出现问题,就会产生较大的影响。 现在,今日头条的内容主要来源于两部分,一是具有成熟内容生产能力的PGC平台 一是UGC用户内容,如问答、用户评论、微头条。这两部分内容需要通过统一的审核机制。如果是数量相对少的PGC内容,会直接进行风险审核,没有问题会大范围推荐。 UGC内容需要经过一个风险模型的过滤,有问题的会进入二次风险审核。审核通过后,内容会被真正进行推荐。这时如果收到一定量以上的评论或者举报负向反馈,还会再回到复审环节,有问题直接下架。 整个机制相对而言比较健全,作为行业领先者,在内容安全上,今日头条一直用最高的标准要求自己。 分享内容识别技术主要鉴黄模型,谩骂模型以及低俗模型。今日头条的低俗模型通过深度学习算法训练,样本库非常大,图片、文本同时分析。 这部分模型更注重召回率,准确率甚至可以牺牲一些。谩骂模型的样本库同样超过百万,召回率高达95%+,准确率80%+。如果用户经常出言不讳或者不当的评论,我们有一些惩罚机制。 泛低质识别涉及的情况非常多,像假新闻、黑稿、题文不符、标题党、内容质量低等等,这部分内容由机器理解是非常难的,需要大量反馈信息,包括其他样本信息比对。 目前低质模型的准确率和召回率都不是特别高,还需要结合人工复审,将阈值提高。目前最终的召回已达到95%,这部分其实还有非常多的工作可以做。别平台。 -END- 作者 | 朵朵066 | 整理文章为传播相关技术,版权归原作者所有 | | 如有侵权,请联系删除 | 【1】用C实现:均值计算的两种算法 【2】单片机DSP必备概念:快速教会你傅立叶算法 【3】几种常见的校验算法 【4】C语言编程:九种必会查找算法(附完整代码) 【5】图解机器学习:请不要再说看不懂算法! 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-24 关键词: 计算框架 互联网

  • WHAT???模拟工程师也要过程序员节!!!

    行政小姐姐发通知了—— 1024程序员节 参与程序项目的同事都放假一天!‍ 处理器和微控制器产品组的同事们 率先申请,通过! WOW,筒子们实名羡慕~‍ 放假!放假! 我也是程序员! 我不管! 立刻!现在!放假! 快去申请! 我不管我是程序员 他们都放假了! 我也要放假 其他项目组正努力工作的“程序员”们 随后。。。 ANC(主动降噪)项目组也提出申请—— Q:“降噪不都是模拟的事儿吗?!” A:“不不不,现在流行的是数字降噪了。” Q:“咱们的方案不是以24位ADC、DAC、低模拟到模拟延迟见长吗?” A:“不不不,咱们方案的SigmaDSP®音频处理器编程也很关键” Q:“SigmaDSP不是有SigmaStudioTM图形开发工具,可以非常轻松配置么?” A:“那,那,那也叫编程啊!话说,里面还涉及非常复杂的降噪处理算法,还有......” 工业状态监测(CbM)项目组也提出申请—— Q:“工业状态监测不都是传感器和信号链的事儿吗?” A:“不不不,没有信号解读的状态监测算啥事儿啊,咱们可是硬件软件、算法,还有机械设计咱们都负责。” Q:“机械设计???!!!” A:“咱们的CbM模块方案ADcmXL3021就是完整的振动检测系统,配有四个安装法兰,可使用标准机器螺丝进行安装,在宽频率范围内可实现与内核传感器的一致机械耦合……” Q:“哦哦哦,还是聊聊里面的程序设计吧” A:“咱们的CbM高级预测性维护OtoSense人工智能软件可以实现状态监测的数据采集模块、表征和可视化……”‍ 射频无线电工程化项目组也提出申请—— Q:“啊,你,你们??……无线电不都是模拟的事儿吗?” A:“不不不,千万别奥特,现在流行软件定义无线电了。” Q:“你是指我们的捷变频收发器产品?” A:“对对对,还有新一代宽带 RF 收发器、数字预失真收发器……” Q:“可以扫个盲吗?软件定义无线电在我们生活中有哪些应用啊,解释下呗?” A:“应用就太多了,急救员无线电、卫星通信、小型基站蜂窝。高速ETC收费路侧单元基于我们的软件定义无线电,实现数字解调设计与降噪处理算法,RSU可以实现优于-95dBm的极高Rx接收机灵敏度……”‍ . . . .  今天我们都是程序员,大家节日快乐 (本场景纯属虚构,请同事们别对号入座 ) 小tips: ADI的技术创新不仅着眼于在半导体领域提供高性能的硬件产品,还在硬件解决方案中引入了物联网、云分析等平台化功能设计思想,并在应用工具、安全和算法以及软件领域进行投资,持续构建基于硬件的完整集成式技术堆栈,为客户提供一整套的解决方案。 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-24 关键词: 程序员 互联网

  • 第八届“榜样中国·我心目中的名医”颁奖典礼举行

    第八届“榜样中国·我心目中的名医”颁奖典礼举行

    2020年9月20日,在成都正式举行了“智慧云端“医疗大健康产业论坛暨2020年第八届“榜样中国·我心目中的名医”的大型公益评选活动。本次活动由封面新闻和华西都市报共同主办。 我心目中的十大名医颁奖典礼 作为四川医疗界的一张“名牌”,2013年至2020年,封面新闻、华西都市报举办的“榜样中国·我心目中的名医”大型公益评选活动已走过8个年头了。今年的名医评选活动,从启动之初就获得了极大关注,上千名医务人员踊跃报名,经过一个月的网络投票,以及专家评审,100位名医脱颖而出,成为当天最闪耀的明星。 值得一提的是,新冠肺炎疫情发生后,全省卫生健康系统快速集结,先后向湖北派出10批医疗队、3批疾控队以及3名国家单独抽调的专家共1463人支援湖北。他们英勇逆行,怀揣使命担当和医者仁心。经协商,主办方为“四川省援助湖北医疗队”授予本次活动的特别大奖。 颁奖典礼期间,主办方还举办了“智慧云端”医疗大健康产业论坛及突发公共卫生事件中应急防控体系建设论坛。今年在新冠肺炎疫情期间,考验着我国突发公共卫生事件中的应急防控体系建设,也让互联网+医疗和线上诊疗方便了我们的生活,在两轮论坛中,来自省内医疗行业知名专家就互联网和大健康的有机结合,医疗健康大数据安全,智慧医院建设、突发公共卫生事件中应急防控体系建设等方面进行了热烈探讨,为四川医疗行业发展建言献策。 疫情发生后,面对市民防护物资缺乏、封路无法就医,农产品无销路、购买口罩被骗等困境,2月8日,封面新闻开通“云求助疫情防控通道”,为用户提供了一条畅通的沟通渠道,并解决了许多关乎市民切身利益的难题。为了传播正能量,弘扬主流媒体的社会担当,让身处困境的人获得帮助,9月20日颁奖典礼期间,封面传媒正式启动四川医疗“云求助”联盟。

    时间:2020-10-24 关键词: 系统 智慧云端 互联网

  • 招商银行将推出医保电子凭证和智慧医疗

    招商银行将推出医保电子凭证和智慧医疗

    在今年年初的时候,招商银行与国家医保局正式签署了医保电子凭证合作协议,双方将携起手来共同推出医保电子凭证和智慧医疗,让人民群众享受到更加优质的服务。 医保电子凭证是全国统一的医保信息平台重要组成部分,13亿参保人未来可以通过医保电子凭证享受各类在线医疗保障服务,包括医保业务办理、医保账户查询、医保就诊和购药支付等。招银银行昆明分行依托总行与国家医保局电子医保凭证的合作基础,积极对接云南省医保局,成为云南省首批医保电子凭证试点线上应用的金融机构之一,该电子医疗凭证于今年六月份正式上线。为积极推广该项工作,更好的服务广大市民,招行昆明分行成立了医保电子凭证推动小组,电子医保凭证激活量也纳入了分行考核指标,全行积极进行了线上线下推广活动,截止9月初通过招商银行手机下载渠道的用户量在所有金融机构APP中排名前五,得到了云南省医保局的高度认可。下一步,招商银行昆明分行将进一步对接好省市医保系统,继续加大电子医保凭证的推广力度,力争拓展出更多的便民服务场景,为更好的服务好本地市民打下夯实的基础。 同时,招商银行还紧跟国家政策导向,长期以来在全国范围内大力推进“智慧医疗”项目产品,利用互联网思维与金融的有效融合,通过移动医疗业务打造“智慧医院”,实现业务协同和资源共享,提高医疗服务效率和诊疗效率,同时为如今医疗资源紧缺、看病就医难等社会问题提出相应的解决方案,力争为我国医疗现代化、信息化改革做出贡献。如今,在总行的支持下,招商银行昆明分行已与云南省市多家医院合作建立了“智慧医疗”项目。

    时间:2020-10-24 关键词: 电子 智慧医疗 互联网

  • 程序员看过来!如果面试时大家都说真话……

    面试官:你好,这是你面试的第一家公司吗? 程序员小王:当然不是啦,面了30多家,都不要我。 面试官:哦哦哦,没事,我们面试了50多个,1个都不愿意来呢。你简历上写的5年Java开发经验… 程序员小王:大学编程设计也算进去了,全靠同学我划水!实际上工作不到3年… 面试官:曾参与主导十万级以上用户的中大型项目研发… 程序员小王:之前公司负责一个政府外包项目,我提了一丁点儿意见… 面试官:精通JAVA/JavaScript,熟练掌握IO,多线程、集合等基础类库;熟悉常见设计模式,熟悉dubbo以及dubbo的服务治理;精通Spring、MyBatis等流行开源框架;有高并发高流量互联网分布式开发经验;熟悉数据库原理和常用性能优化技术… 程序员小王:都是吹的,知道一点儿,也就性能优化稍微了解点儿。 面试官:那就好!吓我一跳,这些你要是都精通,我们肯定要不起!我们公司最近打算做个电商app项目,类似淘宝那种,那你就讲讲性能优化相关吧。 程序员小王:性能优化涉及到的是方方面面,从基础代码性能优化,到JVM深度调优、设计模式优化,再到数据库调优、并发编程性能优化,这些我虽然没用过,但是都听过!工作中一边百度,一边Google,大都可以解决的! 面试官:外瑞外瑞good啊!!!那谈谈薪资,你期望薪资是多少? 程序员小王:我期望薪资写的25K,但7K也可以干,就是会偷懒。钱多点,干活就勤快点! 面试官:Hmmm,我们写的是15~30K,实际上最多只给到10K,既然你水平有限,那我就大方点给到8K!但是要经常加班哦! 程序员小王:可以的!反正加班我也是摸鱼! 面试官:行吧,明天就来上班吧! 程序员小王:好嘞!  来源:程序员之家 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-23 关键词: 程序员 互联网

  • 25岁程序员 VS 35岁程序员,太真实!

    点击上方“大鱼机器人”,选择“置顶/星标公众号” 福利干货,第一时间送达! 25岁程序员 VS 35岁程序员 其中的酸甜苦辣 你中了几条 经常有人说: 35岁是程序员的魔咒。 但其实相比于刚毕业的年轻人,虽然35岁的程序员从精力上和年龄上都不再占有优势,但十几年的沉淀所造就的从容也是这个年龄段所独有的。 当然,也不只是程序员,任何行业到了35岁都会是一道槛,所以在职场一定要持续学东西,塑造自己的不可替代性,才能让自己更有价值。 小伙伴们不用慌,坚持提高专业和管理能力,35岁的你一定更强! -END- 往期好文合集 漫画科普:芯片是如何设计出来的 中国程序员 VS 印度程序员,太有味了... 漫画版:如何学习单片机?   最 后     若觉得文章不错,转发分享,也是我们继续更新的动力。 5T资源大放送! 包括但不限于: C/C++,Linux,Python,Java,PHP,人工智能,PCB、FPGA、DSP、labview、单片机、等等 ! 在公众号内回复「更多资源」,即可免费获取,期待你的关注~ 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-23 关键词: 程序员 互联网

  • 中国程序员 VS 印度程序员,太有味了...

    作者:不会笑青年 漫画师:Ys -END- 往期好文合集 漫画科普:芯片是如何设计出来的 漫画科普:天线的原理? 漫画版:如何学习单片机?   最 后     若觉得文章不错,转发分享,也是我们继续更新的动力。 5T资源大放送! 包括但不限于: C/C++,Linux,Python,Java,PHP,人工智能,PCB、FPGA、DSP、labview、单片机、等等 ! 在公众号内回复「更多资源」,即可免费获取,期待你的关注~ 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-23 关键词: 程序员 互联网

  • 程序员的11个等级,你修炼到第几级了?

    自西方文艺复兴以来,中国在自然科学方面落后西方,软件领域也不例外。当然现在中国的许多程序员们对此可能有许多不同的意见,有些人认为中国的程序员水平远落后于西方,有些则认为中国的程序员个人能力并不比西方的程序员差,只是整个软件产业落后而已。 那么,到底中国的程序员水平比西方程序员水平差,还是中国有许多优秀的程序员达到或超过了西方程序员同等水平呢?要解决这个问题,必须先知道程序员有多少种技术层级,每个层级需要什么样的技术水平,然后再比较中国和西方在各个技术层级的人数,就可以知道到底有没有差距,差距有多大。 当然,对于如何划分程序员的技术层级,不同公司或不同人会有不同的划分标准,下面的划分仅代表个人的观点,如有不当之处,还请砸板砖予以纠正。    1 菜鸟 01 第1层楼属于地板层,迈进这层楼的门槛是很低的。基本上懂计算机的基本操作,了解计算机专业的一些基础知识,掌握一门基本的编程语言如C/C++,或者Java,或者JavaScript,...,均可入门迈进这层。 在这层上,中国有着绝对的优势,除了从计算机专业毕业的众多人数外,还有大量的通信、自动化、数学等相关专业的人士进入这一行,此外还有众多的其他专业转行的人士,人数绝对比西方多出甚多。并且还有一个优势就是我们这层人员的平均智商比西方肯定高。 没有多少人愿意一辈子做菜鸟,因为做"菜鸟"的滋味实在是不咋的,整天被老大们吆喝着去装装机器,搭建一下测试环境,或者对照着别人写好的测试用例做一些黑盒测试,好一点的可以被安排去写一点测试代码。当然如果运气"好"的话,碰到了国内的一些作坊式的公司,也有机会去写一些正式的代码。 所以,菜鸟们总是在努力学习,希望爬更高的一层楼去。 2 大虾 02 从第1层爬到第2层相对容易一些,以C/C++程序员为例,只要熟练掌握C/C++编程语言,掌握C标准库和常用的各种数据结构算法,掌握STL的基本实现和使用方法,掌握多线程编程基础知识,掌握一种开发环境,再对各种操作系统的API都去使用一下,搞网络编程的当然对socket编程要好好掌握一下,然后再学习一些面向对象的设计知识和设计模式等,学习一些测试、软件工程和质量控制的基本知识,大部分人经过2~3年的努力,都可以爬到第2层,晋升为"大虾"。 中国的"大虾"数量和"菜鸟"数量估计不会少多少,所以这层上仍然远领先于西方。 大虾们通常还是有些自知之明,知道自己只能实现一些简单的功能,做不了大的东西,有时候还会遇到一些疑难问题给卡住,所以他们对那些大牛级的人物通常是非常崇拜的,国外的如Robert C. Martin、Linus Torvalds,国内的如求伯君、王志东等通常是他们崇拜的对象。其中的有些人希望有一天也能达到这些大牛级人物的水平,所以他们继续往楼上爬去。 3 牛人 03 由于"大虾"们经常被一些疑难问题给卡住,所以有了"大虾"们只好继续学习,他们需要将原来所学的知识进一步熟练掌握,比如以熟练掌握C++编程语言为例,除了学一些基础性的C++书籍如《C++ Primer》,《Effective C++》,《Think in C++》,《Exception C++》等之外,更重要的是需要了解C++编译器的原理和实现机制,了解操作系统中的内部机制如内存管理、进程和线程的管理机制,了解处理器的基础知识和代码优化的方法,此外还需要更深入地学习更多的数据结构与算法,掌握更深入的测试和调试知识以及质量管理和控制方法,对各种设计方法有更好的理解等。 学习上面说的这些知识不是一挥而就的,不看个三五十本书并掌握它是做不到的。以数据结构算法来说,至少要看个5-10本这方面的著作;以软件设计来说,光懂结构化设计、面向对象设计和一些设计模式是不够的,还要了解软件架构设计、交互设计、面向方面的设计、面向使用的设计、面向数据结构算法的设计、情感化设计等,否则是很难进到这个楼层的。 当然除了上面说的知识外,大虾们还需要去学习各种经验和技巧。当然这点难不倒他们,现在出版的书籍众多,网络上的技术文章更是不胜数,然后再去各种专业论坛里泡一泡,把这些书籍和文章中的各种经验、技能、技巧掌握下来,再去学习一些知名的开源项目如Apache或Linux操作系统的源代码实现等。此时对付一般的疑难问题通常都不在话下,菜鸟和大虾们会觉得你很"牛",你也就爬到了第3层,晋升为"牛人"了。 看了上面所讲的要求,可能有些大虾要晕过去了,成为牛人要学这么多东西啊!要求是不是太高了?其实要求一点也不高,这么点东西都掌握不了的话,怎么能让别人觉得你"牛"呢? 需要提一下的是,进入多核时代后,从第2层爬到第3层增加了一道多核编程的门槛。当然要迈过这道门槛并不难,已经有很多前辈高人迈进了这道门槛,只要循着他们的足迹前进就可以了。想迈进这道门槛者不妨去学习一下TBB开源项目的源代码(链接:http://www.threadingbuildingblocks.org/),然后上Intel的博客(http://softwareblogs-zho.intel.com/)和多核论坛(http://forum.csdn.net/Intel/IntelMulti-core/)去看看相关文章,再买上几本相关的书籍学习一下。 在国内, 一旦成为"牛人",通常可以到许多知名的公司里去,运气好者可以挂上一个架构师的头衔,甚至挂上一个"首席架构师"或者"首席xx学家"的头衔也不足为奇。有不少爬到这层的人就以为到了楼顶了,可以眼睛往天上看了,开始目空一切起来,以为自己什么都可以做了,什么都懂了,经常在网络上乱砸板砖是这个群体的最好写照。由此也看出,国内的牛人数量仍然众多,远多于西方的牛人数量,在这层上仍然是领先的。 也有不少谦虚的"牛人",知道自己现在还不到半桶水阶段。他们深知爬楼的游戏就像猴子上树一样,往下看是笑脸,往上看是屁股。为了多看笑脸,少看屁股,他们并没有在此停步不前,而是继续寻找到更上一层的楼梯,以便继续往上爬。 4 大牛 04 从第3层爬到第4层可不像上面说过的那几层一样容易,要成为大牛的话,你必须要能做牛人们做不了的事情,解决牛人们解决不了问题。比如牛人们通常都不懂写操作系统,不会写编译器,不懂得TCP/IP协议的底层实现,如果你有能力将其中的任何一个实现得象模象样的话,那么你就从牛人升级为"大牛"了。 当然,由于各个专业领域的差别,这里举操作系统、编译器、TCP/IP协议只是作为例子,并不代表成为"大牛"一定需要掌握这些知识,以时下热门的多核编程来说,如果你能比牛人们更深入地掌握其中的各种思想原理,能更加自如的运用,并有能力去实现一个象开源项目TBB库一样的东西,也可以成为"大牛",又或者你能写出一个类似Apache一样的服务器,或者写出一个数据库,都可以成为"大牛"。 要成为"大牛"并不是一件简单的事情,需要付出比牛人们多得多的努力,一般来说,至少要看过200~400本左右的专业书籍并好好掌握它,除此之外,还得经常关注网络和期刊杂志上的各种最新信息。 当"牛人"晋升为"大牛",让"牛人们"发现有比他们更牛的人时,对"牛人"们的心灵的震撼是可想而知的。由于牛人们的数量庞大,并且牛人对大虾和菜鸟阶层有言传身教的影响,所以大牛们通常能获得非常高的社会知名度,几乎可以用"引无数菜鸟、大虾、牛人竞折腰"来形容,看看前面提过的Linus Torvalds等大牛,应该知道此言不虚。 虽然成为"大牛"的条件看起来似乎很高似的,但是这层楼并不是很难爬的一层,只要通过一定的努力,素质不是很差,还是有许多"牛人"可以爬到这一层的。由此可知,"大牛"这个楼层的人数其实并不像想像的那么少,例如比尔·盖茨之类的人好像也是属于这一层的。 由于"大牛"这层的人数不少,所以也很难统计除到底是中国的"大牛"数量多还是西方的大牛数量多?我估计应该是个旗鼓相当的数量,或者中国的"大牛"们会更多一些。 看到这里,可能会有很多人会以为我在这里说瞎话,Linus Torvalds写出了著名的Linux操作系统,我国并没有人写出过类似的东西啊,我国的"大牛"怎么能和西方的比呢? 不知大家注意到没有,Linus Torvalds只是写出了一个"象模象样"的操作系统雏形,Linux后来真正发展成闻名全球的开源操作系统期间,完全是因为许多支持开源的商业公司如IBM等,派出了许多比Linus Torvalds更高楼层的幕后英雄在里面把它开发出来的。 可能有些菜鸟认为Linus Torvalds是程序员中的上帝,不妨说个小故事: Linus,Richard Stallman和Don Knuth(高德纳)一同参加一个会议。 Linus 说:"上帝说我创造了世界上最优秀的操作系统。" Richard Stallman自然不甘示弱地说:"上帝说我创造了世界上最好用的编译器。" Don Knuth一脸疑惑的说:"等等,等等,我什么时候说过这些话?" 由此可以看出,Linus Torvalds的技术水平并不像想像中那么高,只是"牛人"和"大虾"觉得"大牛"比他们更牛吧了。在我国,有一些当时还处于"大虾"层的人物,也能写出介绍如何写操作系统的书,并且书写得非常出色,而且写出了一个有那么一点点象模象样的操作系统来。我想中国的"大牛"们是不会比西方差的,之所以没有人写出类似的商业产品来,完全是社会环境的原因,并不是技术能力达不到的原因。 "大牛"们之所以成为大牛,主要的原因是因为把"牛人"给盖了下去,并不是他们自己觉得如何牛。也许有很多菜鸟、大虾甚至牛人觉得"大牛"这层已经到顶了,但大多数"大牛"估计应该是有自知之明的,他们知道自己现在还没有爬到半山腰,也就勉强能算个半桶水的水平,其中有些爬到这层没有累趴下,仍然能量充沛,并且又有志者,还是会继续往更上一层楼爬的。 看到这里,也许有些菜鸟、大虾、牛人想不明白了,还有比"大牛"们更高的楼层,那会是什么样的楼层?下面就来看看第5层楼的奥妙。 5 专家 05 当大牛们真正动手做一个操作系统或者类似的其他软件时,他们就会发现自己的基本功仍然有很多的不足。以内存管理为例,如果直接抄袭Linux或者其他开源操作系统的内存管理算法,会被人看不起的,如果自动动手实现一个内存管理算法,他会发现现在有关内存管理方法的算法数量众多,自己并没有全部学过和实践过,不知道到底该用那种内存管理算法。 看到这里,可能有些人已经明白第5层楼的奥妙了,那就是需要做基础研究,当然在计算机里,最重要的就是"计算"二字,程序员要做基础研究,主要的内容就是研究非数值"计算"。 非数值计算可是一个非常庞大的领域,不仅时下热门的"多核计算"与"云计算"属于非数值计算范畴,就是软件需求、设计、测试、调试、评估、质量控制、软件工程等本质上也属于非数值计算的范畴,甚至芯片硬件设计也同样牵涉到非数值计算。如果你还没有真正领悟"计算"二字的含义,那么你就没有机会进到这层楼来。 可能有人仍然没有明白为什么比尔·盖茨被划在了大牛层,没有进到这层来。虽然比尔·盖茨大学未毕业,学历不够,但是家有藏书2万余册,进入软件这个行业比绝大部分人都早,撇开他的商业才能不谈,即使只看他的技术水平,也可以算得上是学富五车,顶上几个普通的计算机软件博士之和是没有问题的,比起Linus Torvalds之类的"大牛"们应该技高一筹才对,怎么还进不了这层楼呢? 非常遗憾的是,从Windows操作系统的实现来看,其对计算的理解是很肤浅的,如果把Google对计算方面的理解比做大学生,比尔·盖茨只能算做一个初中生,所以比尔·盖茨永远只能做个大牛人,成不了"专家"。 看到这里,也许国内的大牛们要高兴起来了,原来比尔·盖茨也只和我等在同一个层次,只要再升一层就可以超越比尔·盖茨了。不过爬到这层可没有从"牛人"升为"大牛"那么简单,人家比尔·盖茨都家有2万多册书,让你看个500-1000本以上的专业书籍并掌握好它应该要求不高吧。当然,这并不是主要的条件,更重要的是,需要到专业的 学术站点去学习了。 到ACM,IEEE,Elsevier,SpringerLink,SIAM等地方去下载论文应该成为你的定期功课,使用Google搜索引擎中的学术搜索更是应该成为你的日常必修课。此外,你还得经常关注是否有与你研究相关的开源项目冒出来,例如当听到有TBB这样针对多核的开源项目时,你应该第一时间到Google里输入"TBB"搜索一下,将其源代码下载下来好好研究一番,这样也许你的一只脚已经快迈进了这层楼的门槛。 当你象我上面说的那样去做了以后,随着时间的推移,总会有某天,你发现,在很多小的领域里,你已经学不到什么新东西了,所有最新出来的研究成果你几乎都知道。此时你会发现你比在做"牛人"和"大牛"时的水平不知高出了多少,但是你一点也"牛"不起来,因为你学的知识和思想都是别人提出来的,你自己并没有多少自己的知识和思想分享给别人,所以你还得继续往楼上爬才行。 我不知道国内的"专家"到底有多少,不过有一点可以肯定的是,如果把那些专门蒙大家的"砖家"也算上的话,我们的砖家比西方的要多得多。 6 学者 06 当"专家"们想继续往上一层楼爬时,他们几乎一眼就可以看到楼梯的入口,不过令他们吃惊的是,楼梯入口处竖了一道高高的门槛,上面写着"创新"二字。不幸的是,大多数人在爬到第5层楼时已经体能消耗过度,无力翻过这道门槛。 有少数体能充足者,可以轻易翻越这道门槛,但是并不意味着体力消耗过度者就无法翻越,因为你只是暂时还没有掌握恢复体能的方法而已,当掌握了恢复体能的方法,将体能恢复后,你就可以轻易地翻越这道门槛了。 怎么才能将体能恢复呢?我们的老祖宗"孔子"早就教导过我们"温故而知新",在英文里,研究的单词是"research",其前缀"re"和"search"分别是什么意思不用我解释吧。或许有些人觉得"温故而知新"和"research"有些抽象,不好理解,我再给打个简单的比方,比如你在爬一座高山,爬了半天,中途体力不支,怎么恢复体力呢?自然是休息一下,重新进食一些食物,体力很快就可以得到恢复。 由此可知,对体能消耗过度者,休息+重新进食通常是恢复体能的最佳选择。可惜的是,国内的老板们并不懂得这点,他们的公司里不仅连正常国家规定的休息时间都不给足,有些公司甚至有员工"过劳死"出现。所以国内能翻越"创新"这道门槛的人是"少之又少",和西方比起来估计是数量级的差别。 再说说重新进食的问题,这个重新进食是有讲究的,需要进食一些基础性易消化的简单食物,不能进食山珍海味级的复杂食物,否则很难快速吸收。以查找为例,并不是去天天盯着那些复杂的查找结构和算法进行研究,你需要做的是将二分查找、哈希查找、普通二叉树查找等基础性的知识好好地复习几遍。 以哈希查找为例,首先你需要去将各种冲突解决方法如链式结构、二次哈希等编写一遍,再试试不同种类的哈希函数,然后还需要试试在硬盘中如何实现哈希查找,并考虑数据从硬盘读到内存后,如何组织硬盘中的数据才能快速地在内存中构建出哈希表来,...,这样你可能需要将一个哈希表写上十几个不同的版本,并比较各个版本的性能、功能方面的区别和适用范围。 总之,对任何一种简单的东西,你需要考虑各种各样的需求,以需求来驱动研究。最后你将各种最基础性的查找结构和算法都了然于胸后,或许某天你再看其他更复杂的查找算法,或者你在散步时,脑袋里灵光一现,突然间就发现了更好的方法,也就从专家晋升为"学者"了。 学者所做的事情,通常都是在前人的基础上,进行一些小的优化和改进,例如别人发明了链式基数排序的方法,你第1个发现使用一定的方法,可以用数组替代链表进行基数排序,性能还能得到进一步提高。 由于学者需要的只是一些小的优化改进,因此中国还是有一定数量的学者。不过和国外的数量比起来,估计少了一个数量级而已。 也许有人会觉得现在中国许多公司申请专利的数量达到甚至超过西方发达国家了,我们的学者数量应该不会比他们少多少。因此,有必要把专利和这里说的创新的区别解释一下。 所谓专利者,只要是以前没有的,新的东西,都可以申请专利;甚至是以前有的东西,你把他用到了一个新的领域的产品里去,也可以申请专利。比如你在房子里造一个水泥柱子,只要以前没有人就这件事申请专利,那么你就可以申请专利,并且下次你把水泥柱子挪一个位置,又可以申请一个新的专利;或者你在一个柜子上打上几个孔,下次又把孔的位置改一改,...,均可申请专利。 这层楼里所说的创新,是指学术层面的创新,是基础研究方面的创新,和专利的概念是完全不同的,难度也是完全不同的。你即使申请了一万个象那种打孔一类的专利,加起来也够不到这层楼里的一个创新。 当你爬到第6层楼时,你也许会有一种突破极限的快感,因为你终于把那道高高的写着"创新"二字的门槛给翻过去了,实现了"0"的突破。这时,你也许有一种"独上高楼,欲望尽天涯路"的感觉,但是很快你会发现看到的都是比较近的路,远处的路根本看不清楚。如果你还有足够的体力的话,你会想爬到更高一层的楼层去。 7 大师 07 从第6层楼爬到第7层楼,并没有多少捷径可走,主要看你有没有足够的能量。你如果能象Hoare一样设计出一个快速排序的算法;或者象Eugene W. Myers一样设计出了一个用编辑图的最短路径模型来解决diff问题的算法;或者象M.J.D. Powell一样提出了一个能够处理非线性规划问题的SQP方法;或者你发现基于比较的排序算法,它的复杂度下界为O(NLogN);或者你发现用栈可以将递归的算法变成非递归的;或者你设计出一个红黑树或者AVL树之类的查找结构;或者你设计出一个象C++或Java一样的语言;...,你就爬到了第7层,晋升为"大师"了。 上面举的这些例子中,其中有些人站的楼层比这层高,这里只是为了形象说明而举例他们的某个成就。从上面列出的一些大师的贡献可以看出,成为大师必须要有较大的贡献。首先解决问题必须是比较重要的,其次你要比前辈们在某方面有一个较大的提高,或者你解决的是一个全新的以前没有解决过的问题;最重要的是,主要的思路和方法必须是你自己提供的,不再是在别人的思路基础上进行的优化和改进。 看了上面这些要求,如果能量不够的话,你也许会觉得有些困难,所以不是每个人都能成为"大师"的。中国软件业里能称得上是"大师"的人,用屈指可数来形容,估计是绰绰有余。值得一提得是,国外的"大师"就象我们的"大牛"一样满天飞的多。 我把我猜测本国有可能进到这层楼的大师列一下,以起个抛砖引玉的作用。汉王的"手写识别"技术由于是完全保密的,不知道它里面用了什么思想,原创思想占的比重有多少,因此不知道该把它划到这层楼还是更高一层楼去。原山东大学王小云教授破解DES和MD5算法时,用到的方法不知道是不是完全原创的,如果是的话也可进到这层楼来。 陈景润虽然没有彻底解决哥德巴赫猜想,但他在解决问题时所用的方法是创新的,因此也可以进到这层楼来。当然,如果能彻底解决哥德巴赫猜想,那么可以算到更高的楼层去。 求伯君和王志东等大牛们,他们在做WPS和表格处理之类的软件时,不知是否有较大的原创算法在里面,如果有的话就算我错把他们划到了大牛层。由于所学有限,不知道国内还有那些人能够得上"大师"的级别,或许有少量做研究的教授、院士们,可以达到这个级别,有知道的不妨回个帖子晾一晾。 鉴于"大师"这个称号的光环效应,相信有不少人梦想着成为"大师"。或许你看了前面举的一些大师的例子,你会觉得要成为大师非常困难。不妨说一下,现在有一条通往"大师"之路的捷径打开了,那就是多核计算领域,有大量的处女地等待大家去挖掘。 以前在单核时代开发的各种算法,现在都需要改写成并行的。数据结构与算法、图像处理、数值计算、操作系统、编译器、测试调试等各个领域,都存在大量的机会,可以让你进到这层楼来,甚至有可能让你进到更高一层楼去。 8 科学家 08 科学家向来都是一个神圣的称号,因此我把他放在了“大师”之上。要成为科学家,你的贡献必须超越大师,不妨随便举一些例子。 如果你象Dijkstra一样设计了ALGOL语言,提出了程序设计的三种基本结构:顺序、选择、循环,那么你可以爬到第8层楼来。顺便说一下,即使抛开这个成果,Dijkstra凭他的PV操作和信号量概念的提出,同样可以进到这层楼。 如果你象Don Knuth一样,是数据结构与算法这门学科的重要奠基者,你也可以进到这层楼来。当然,数据结构和算法这门学科不是某个人开创的,是许多大师和科学家集体开创的。 如果你象巴科斯一样发明了Fortran语言,并提出了巴科斯范式,对高级程序语言的发展起了重要作用,你也可以进到这层楼来。 或者你象Ken Thompson、Dennis Ritchie一样发明了Unix操作系统和功能强大、高效、灵活、表达力强的C语言,对操作系统理论和高级编程语言均作出重大贡献,那么你也可以进到这层楼来。 或者你有Frederick P. Brooks一样机会,可以去领导开发IBM的大型计算机System/360和OS/360操作系统,并在失败后反思总结,写出《人月神话》,对软件工程作出里程碑式的贡献,你也可以进到这层来。 或者你提出了面向对象设计的基本思想,或者你设计了互联网的TCP/IP协议,或者你象Steven A.Cook一样奠定NP完全性的理论基础,或者你象Frances Allen一样专注于并行计算来实现编译技术,在编译优化理论和技术取得基础性的成就,…,均可进入这层。 当然,如果你发明了C++语言或者Java语言,你进不到这层来,因为你用到的主要思想都是这层楼中的科学家提出的,你自己并没有没有多少原创思想在里面。 看了上面列出的科学家的成就,你会发现,要成为“科学家”,通常要开创一门分支学科,或者是这个分支学科的奠基者,或者在某个分支学科里作出里程碑式的重大贡献。如果做不到这些的话,那么你能象Andrew C. Yao(姚期智)一样在对计算理论的多个方向如伪随机数生成,密码学与通信复杂度等各个方向上作出重要贡献,成为集大成者,也可以进入这层楼。 成为“科学家”后,如果你有幸象Dijkstra一样,出现在一个非常重视科学的国度。当你去世时,你家乡满城的人都会自动地去为你送葬。不过如果不幸生错地方的话,能不挨“板砖”估计就算万幸了。 从上面随便举的一些例子中,你可能能猜到,西方科学家的数量是非常多的,于是你会想中国应该也有少量的科学家吧?我可以很负责任地告诉你一个不幸的结果,中国本土产生的科学家的数量为0。目前在国内,软件领域的唯一的科学家就是上面提过的姚期智,还是国外请回来的,并不是本土产生的。 可能你不同意我说的本土科学家数量为0的结论,因为你经常看到有许多公司里都有所谓“首席XX科学家”的头衔。我想说的是,这些所谓的“首席XX科学家”都是远远够不到这层楼的级别的,有些人的水平估计也就是一个“牛人”或“大牛”的级别,好一点的最多也就一个“学者”的级别。尤其是那些被称作“首席经X学家”的,基本上可以把称号改为“首席坑大家”。 虽然我国没有人能爬到这层楼上来,但是西方国家仍然有许多人爬到了比这层更高的楼上。如果要问我们比西方落后多少?那么可以简单地回答为:“落后了三层楼”。下面就来看看我们做梦都没有到过的更高一层楼的秘密。 9 大科学家 09 进入这层楼的门槛通常需要一些运气,比如某天有个苹果砸到你头上时,你碰巧发现了万有引力,那么你可以进到这层楼来。当然,万有引力几百年前就被人发现了,如果你现在到处嚷嚷着说你发现了万有引力,恐怕马上会有人打110,然后警察会把你送到不正常人类的聚集地去。因此,这里举万有引力的例子,只是说你要有类似的成就才能进到这层楼来。 牛顿发现万有引力定律开创了经典物理运动力学这门学科,如果你也能开创一门大的学科,那么你就从科学家晋升为“大科学家”。比如爱因斯坦创建了相对论,从一个小职员变成了大科学家。当然大科学家可远不止这两人,数学界里比物理学界更是多得多,如欧几里得创建了平面几何,笛卡尔开创解析几何,还有欧拉、高斯、莱布尼茨等数不清的人物,跟计算相关的大科学家则有图灵等人。 从上面列出的一些大科学家可以发现,他们的成就不仅是开创了一个大的学科,更重要的是他们的成就上升到了“公理”的层面。发现公理通常是需要一点运气的,如果你的运气不够好的话,另外还有一个笨办法也可以进到这层楼来,那就是成为集大成者。例如冯·诺伊曼,对数学的所有分支都非常了解,许多领域都有较大的贡献,即使撇开他对计算机的开创贡献,成为大科学家照样绰绰有余。 当然,程序员们最关心的是自己有没有机会变成大科学家。既然计算机这门大学科的开创性成果早就被冯·诺伊曼、图灵等人摘走了,那么程序员们是不是没有机会变成大科学家了呢?我们的古人说得好:“江山代有才人出,各领风骚数百年”,现在在计算机这门学科下面诞生了许多非常重要的大的分支,所以你还是有足够的机会进到这层楼的。 如果你能够彻底解决自然语言理解(机器翻译)这门学科中的核心问题, 或者你在人工智能或者机器视觉(图像识别)方面有突破性的发现,那么你同样可以轻易地晋升为“大科学家”。这样当某天你老了去世时,或许那天国人已经觉醒,你也能享受到如Dijkstra一样的待遇,有满城甚至全国的人去为你送葬。 现在还剩下另外一个大家感兴趣的问题没有讨论,那就是这层中已经出现了牛顿、爱因斯坦、高斯等我们平常人都认为是顶级的科学家,是不是这层已经是楼顶了呢?相信还记得本文标题的人应该知道现在仅仅是第9层,还有第10层没有到达呢。可能不少人现在要感到困惑了,难道还有人站在比牛顿、爱因斯坦、高斯等人更高的楼层上? 这个世界上确实存在可以用一只手的手指数得清的那么几个人,他们爬到了第10层楼上。因此,第10层楼不是虚构的,而是确实存在的。如果对此有疑惑或者认为我在胡诌一番的话,那么不妨继续往下看下去,窥一下第10层楼的秘密。 10 大哲 10 看了这层楼的名字“大哲”,可能不少人已经猜到了这层楼的秘密,那就是你的成果必须要上升到哲学的高度,你才有机会能进到这层来。 当然,上升到哲学高度只是一个必要条件,牛顿的万有引力似乎也上升到了哲学的高度,因为不知道引力到底是怎么来的,但是牛顿没有被划到这一层,因为进到这层还有另外的条件,那就是你的成果必须引起了哲学上的深度思考,并能让人们的世界观向前跨进一大步。窃以为牛顿、爱因斯坦等人的成就还达不到让人们世界观向前跨进一大步的程度。 所以,这层楼中的人的成就对我们普通人认识世界非常重要,你可以不学相对论,但是你不可以不对这层楼的人所作出的成就不了解,否则你的世界观就是极其不完整的,会犯许多认识上的错误。不幸的是,中国的科普知识普及还不够到位,知道这层楼成就的人好像并不多,程序员中恐怕更少。下面就来看看这些用一只手的手指数得清的大哲们,到底有什么成就,能比万有引力定律和相对论还重要。 第1位进到此楼层是一位名叫“希尔伯特”的大数学家,如果你学过《泛函分析》,那么你在学习希尔伯特空间时可能已经对这位大数学家有所了解;如果你不是学数学出身的,又对数学史不感兴趣的话,恐怕你从来没有听说过这个名字。不过如果我问一下,知不知道二次世界大战前世界数学中心在那里,你肯定会有兴趣想知道。 不妨说一下,二战前整个世界的数学中心就在德国的哥廷根,而我们这位大数学家希尔伯特便是它的统帅和灵魂人物。即使在二战期间,希特勒和丘吉尔也有协定,德国不轰炸牛津和剑桥,作为回报,英国不轰炸海德堡和哥廷根。 整个二十世纪上半期的超一流数学家,几乎都出自其门下。这里不妨举几个我们熟悉的人物,例如冯·诺伊曼就曾受到他和他的学生施密特和外尔的思想影响,还到哥廷根大学任过希尔伯特的助手,钱学森的老师冯·卡门是在哥廷根取得博士学位的。这位大数学家发现当时物理学上出了很多大的成果如相对论和量子力学,但是这些物理学家的数学功力明显不足,因此有一段时间带领他的学生们研究过物理学,并独立发现了广义相对论,只是不好意思和物理学家争功劳,将广义相对论的功劳全部让给了爱因斯坦。 广义相对论相对于这位大数学家在数学上的贡献,其实是算不了什么的,只是由此可看出这位大数学家品格的高尚之处。如果再去看看牛顿之流的人物的品行,整天和莱布尼茨、虎克等人争功劳,利用自己的优势地位打压他人,甚至闹得上法庭,和这位希尔伯特先生比起来,简直就是个小丑。 说到这里,你可能对这位大数学家“希尔伯特”有了一些初步映象,感觉到了他的重要性,不过他在数学上的主要成就可不是几句话说得清楚的。首先,他是一位集大成者,精通当时数学所有分支领域,在数学的各个领域都有较大的贡献,当然这些成就只能让他成为一个大科学家,不能带他进入这层楼。事实上这位“希尔伯特”解决的任何一个数学问题都够不到这层楼的高度,那么他怎么混到这层楼来了呢? 话得从1900年说起,当时还很年轻的希尔伯特在当时的世界数学大会上做了一个报告,高屋建瓯地提出了著名的23个未解决的数学问题,然后整个二十世纪上半期,全世界的数学家们都在这23个问题的指导下展开研究,直到现在仍然有许多数学家受这23个问题的指导在进行研究。例如我们熟知的哥德巴赫猜想,就属于其中第8个问题素数分布的一个子问题。 如果用“高瞻远瞩”来形容这位大数学家的话,那么这个世界上恐怕没有第二个人再配得上“高瞻远瞩”这四个字,不论是欧拉、高斯、牛顿、爱因斯坦还是被誉为最有才华的数学家伽罗华,概不例外。 虽然那23个问题是归纳总结出来的,并不全是原创,但是其中有不少问题是可以上升到哲学的高度,引起深度思考的。可能大多数人都会觉得希尔伯特是进不到这层楼的,我们知道提出问题的人和解决问题的人是一样伟大的,何况他提出的问题是如此之多,基于这点,个人觉得应该让希尔伯特跨进这层楼的门槛里。 看完这位希尔伯特的成就,你可能会觉得对你的世界观并没有产生任何影响。确实如此,他提出的问题不是用来影响你的,而是用来影响其他大科学家和大哲的。 也许到现在你仍然无法理解为什么把大哲们划在了大科学家的上一层,你可能仍然觉得万有引力、相对论等成果是最伟大的。下面就来谈谈为什么大哲比大科学家高一层。 如果把人类在现有能力情况下,将来所能够拥有的知识总集看成是一个集合A,人类现在已有的知识总集看成是集合B,显然,集合B只是集合A的一个子集,并且是很小的一个子集。牛顿力学、相对论这些理论只能算作集合B里的一个子集,相对于集合A,只能算作是沧海一粟。换句话说,在人类现有能力可做的事情集合中,牛顿力学和相对论等理论给出了详细的办法让你可以做其中的一些事情,当然剩下的更多的事情是牛顿力学和相对论所无法解决的。 哥德尔不完全性定理和测不准关系的意义在于,它指出集合A的范围,即将人类现有能力发挥到极限的情况下,那些事情是你能做到的,那些是你不能做到的。当然,它并没有给出具体的方法让你去做你能做到的事情,它只是告诉我们我们人类现在发现的能力所能达到的极限。或许将来发现人类有其他新的未发现的能力,那么这个极限就被打破了。比如将来能发现不依赖于基本粒子的其他测量方法,并且测量过程中不会改变其他粒子的状态,那么测不准关系就被打破了。 看到这里,估计你已经发现了一些秘密,科学兜了一大圈,最终还是回到了哲学,也就是我们所认为的玄学上。同时你也会发现,我们老祖宗提出的所谓玄学,原来和现代科学是相通的,并非象某些人想像的那样全是糟粕。如果有人认为西方现代暂时领先我们,进而就认为西方古代就已经超越我们,我们老祖宗就已经落后西方,他们的思想都是糟粕的话,那么我认为他可能犯了崇洋媚外的毛病。我不得不化用一句周杰伦在春晚上的歌词送给他:“你不妨抓一副我们祖传的中医良方,治一治你那崇洋媚外的内伤”。顺便告诉他一下,中医用的阴阳五行理论,它的前提假设就是宿命论。 上面说的大哲的成果,可能对你的世界观会有很大的影响,于是你可能会羡慕起这些大哲们的成果来。如果你有大志的话,你会希望有朝一日,你也能变成大哲,但是你发现上面的大哲是研究数学和物理学的,而你是学计算机的程序员,那么是不是没有机会变成大哲呢? 如果你能将NP难题给彻底解决掉,意味着计算机内的计算的奥秘基本被揭开,或许你可以进到这层楼来;或者你能发现另外一套计算机可以理解的数学公理系统,并且这个公理系统是完备的,那么计算机取代人类进行思维的一个必要条件就满足了,计算机将具有真正意义上的“逻辑思维和推理能力”,你可以轻松地进到这层楼来。如果你发现了新的方法可以打破测不准关系,同样你也可以轻松地进到这层楼来。 如果你能彻底揭开人类抽象思维的奥妙,并让计算机懂得了如何创建抽象,具备抽象思维能力,那么也就具备了“设计能力”,可以取代人类进行各种设计了,你也可以轻松地进到这层楼来。顺便说一下,如果你对软件设计有真正深刻理解的话,就会明白这不是在写科幻小说。对此感兴趣者,不妨好好地研究一下程序切片方面的技术,会让你对软件设计和测试等方面的理解有质的提高,或许有一天你能打开这扇大门。 当然,计算机要完全取代人还有其他必要条件,后面还会提及。值得一提的是,虽然第10层楼是本文中所写的最高层,但是大哲们并没有觉得他们到了顶层,他们通常都还会努力寻找通往更高一层的楼梯。如果你也有成为天下第一的想法,那么你或许会想要做什么事情才能超越大哲们的成就,当然,这都得依赖于找到更高一层楼的楼梯。 个人认为,再往上一层楼的楼梯是通往天堂的道路,也就是说第11层楼的名字叫“天堂”,是“上帝”住的地方,而不是人住的地方。如果将来某天有人能爬到天堂的话,那么他已经不是人了,而是由人变成了“上帝”。 你也许会怀疑这个世界到底有没有“天堂”,“上帝”是否根本就不存在,我也很有同感。因此有必要再写上一段文字,讨论一下“上帝”的问题。如果你想了解天堂的奥妙,有没有办法让你变成“上帝”,不妨看看继续往下看看第11层楼的玄妙。注意我这里用的是“玄妙”二字,因为上帝在大部分人眼里估计都是“玄之又玄”的东西。 11 上帝 11 看了上面的小标题,你可能会觉得奇怪,这篇文章不是讲“程序员的十层楼”吗?怎么冒出了第11层来了? 其实这并不矛盾,程序员确实只有十层楼,因为爬到第11层时,已经变成上帝,不再是程序员了;所以超出10层楼本身并不重要,关键的问题是看你有没有能力变成上帝。 1、谁是上帝? 菜鸟们认为Linus Torvalds是程序员中的上帝,看完了前面各层楼的介绍,此时再看到这句话,相信你要忍不住在心里笑起来。当然,你会不会笑起来是事先注定的。Don Knuth也不是上帝,他离上帝还有三层楼的距离。即使是大哲们,他们离天堂也还差一层楼,因此这个世界上有史以来还没有任何一个人变成过上帝。 我们感兴趣的是,将来会不会有人爬到比大哲们更高的楼层上,变成了上帝。要变成上帝,你得有上帝一样的能力,上帝会造人,你会吗?你也许会怯生生地问:“我可以和爱人生小孩,算不算造人?”,你可能还会理直气壮地说:“现在生物学上都可以克隆人了,早就有人掌握了造人的方法”。 事实上克隆人需要有人的体细胞,必须要先有人才会有体细胞。上帝造人时,这个世界上并没有人,是从无生命的物质“尘土”中创造出的人。因此,用最原始的方法生人和克隆人都是从有生命信息的物质中生人,不能算作造人。这样看来,你根本不会造人,不过我可以告诉你一个“玄方”,让你有机会学会如何造人。 如果你揭开了人类情感的奥秘,让计算机也可以拥有和人类一样的情感,那么计算机将可以理解人类的需求,具有了“情商”,将具有完整的和人一样的能力。此时,人类进化到了机器人,科幻小说将变成现实,也就是说你已经掌握了真正的造人能力,晋升为“上帝”了。 未来到底有没有人能变成“上帝”,人能不能进化到机器人,这是宿命论中事先注定了的。说到这里,不妨再告诉你一个打破宿命论的方法,这个方法就是你要爬到比上帝还要高的楼层。 “还有比上帝还高的楼层?”,你可能会第1时间内冒出这个问题,其实我也有同样的怀疑。因此在写第12层楼前,有必要弄清楚它到底存不存在,即你可不可以骑到上帝的头上的问题。 2. 骑到上帝的头上? 为了解决是否可以骑到上帝的头上这个问题,不妨先假设存在比上帝高的楼层,也就是存在打破宿命论的方法。宿命论的本质原因是因为时间是单向运行,不可逆转造成的。如果你找到一种可以使时间逆转的方法,那么你就打破了宿命论,爬到了比上帝还高的楼层。 看到这里,你也许会摆脱刚才陷于宿命论的困惑情绪,变得充满希望般高兴起来。不过,如果你的逻辑思维能力足够好,仔细思考一下,会发现存在一个逻辑上的悖论。 在你找到时间逆转的方法之前,显然这个世界仍然是需要服从宿命论的,也就是说你能不能找到打破宿命论的方法是事先注定的。假设你在某个时间点t0处找到了打破宿命论的方法,你在打破宿命论后,想利用时间逆转的方法回到某个时间点t2。下面来看看你到底能不能回到时间点t2。 取位于t0和t2之间的任意一个时间点t1,你在回到时间点t2之前,必须先经过时间点t1,考虑你到达t1的那一时刻,由于t1比t0要早,这个时间点上你还没有找到时间逆转的方法,所以到了时间t1点后,你无法再使用时间逆转的能力回到时间点t2去,所以你永远也回不到时间点t2,由于时间点t2是任意取的,因此,你永远也无法使时间逆转,或者说你根本就没打破过宿命论,这与你在时间点t0打破了宿命论产生了矛盾。 上面这段话看起来似乎有点像“人永远迈不出一步”的诡辩一样,你可能会想返回到时间点t1时,仍然可以拥有时间逆转能力啊。不过你又会发现一个新的问题,时间点t1本来是没有时间逆转能力的,现在又认为时间点t1又有时间逆转能力,那时间点t1到底是有还是没有时间逆转能力呢?或者说在时间点t0前,宿命论注定了时间点t1是没有时间逆转能力的,现在你又认为时间点t1具有时间逆转能力,那么这两个时间点t1究竟是不是同一个时间点?如果不是同一个时间点,说明你没有回到过去;如果是同一个时间点的话,岂不是自相矛盾吗? 为了说得更形象一些,不妨假设你坐一艘超光速飞船,准备从时间点t0回到时间点t2去,假设你回到t2后,随着时间的流逝,又达到了时间点t0,如果这时你又再次坐超光速飞船返回时间点t2,那么一个值得思考的问题就出现了,“你在时间点t2能不能看到上次返回时间点t2的飞船?” 如果回答不能看到飞船,那么上次返回的飞船那里去了呢?显然很难解释通。如果回答能看到飞船,那么你可以到达时间点t2后,下次时间到达t0时,你又坐飞船返回t2,这次你将可以看到上两次的两艘飞船。如果这样一直循环下去,最后你会发现你可以在时间点t2看到无穷多的飞船。用程序员的术语说,叫做“程序陷入了死循环”,最后系统必然会出现“Out of Memory”现象而崩溃。 当然,你也可以认为有其他的方法,不需要飞船,可以一次性从时间点t0直接跳跃到时间点t2,并不需要经过时间点t1。下面不妨来分析一下这个方法是否可行。 既然是直接跳跃到时间点t2,那么你必然是在一个无穷小的时间里出现在时间点t2的某个空间里,例如你要在时间点t2回到某个广场上。首先说明一下为什么是无穷小的时间里出现的,因为如果不是无穷小的时间里出现的话,那么必然可以取到一个时间点t1,会导致前面所说的时间点t1上出现悖论。 你在广场上出现的时,广场上的空气必然要为你让开空间,而这是在无穷小的时间里完成的,那么很容易推导出你周围的空气获得的加速度和速度都是无穷大,因而它具有的动能也是无穷大,无穷大的能量和无穷大的速度意味着什么?一只鸟都可以将飞机撞下来,如果宇宙是有限大的话,它可以让这个宇宙炸毁无穷次;即使宇宙是无限大,它也足以让宇宙炸毁一次。宇宙都毁灭了,又何来的时间?还能说你回到了时间点t2吗? 也许上面说的这些你仍然难以相信,不妨再说得更现实一些,假设你要回到100年前的一个时间点,这100年中,天上有多少流星湮灭了?有多少新星生成了?宇宙膨胀了多少?你有能力让湮灭的流星复原、生成的新星重新返回未生成前的状态,膨胀的宇宙收缩回去吗?如果这些东西的状态没有回复到100年前,又怎么能说明你回到的是100年前的时间点呢? 根据上面的推导和分析,个人认为使时间逆转的方法是不存在的,所以第12层楼是不存在的,自然没有人可以骑到“上帝”的头上。宿命论将在有时间的时间里永远统治这个世界。 宿命论将在有时间的时间里永远统治这个世界。 来源:技术让梦想更伟大 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-23 关键词: 程序员 互联网

  • 90后马来西亚女孩闯华为

    心怀不惧,方能翱翔于天际 马来西亚女孩闯华为 Soo Sin Yi 01 “回车”是个什么车? 2016年末,我即将大学毕业。作为一名马来西亚华人,当时的我对华为知之甚少,大概知道它是一家很有名的中国公司。没想到不久后,我幸运地通过了一系列面试,正式加入马来西亚华为软件售前投标部,成为了一名地道的“华为er”。  正当我怀着对未来职业的无限憧憬,立志做出一番成绩时,残酷的现实如同马来西亚38度高温炙烤一般,不适感扑面而来。这个岗位主要是负责软件项目的售前技术投标,刚入职,我就遇到了几大难关:语言关、专业关、职场关,几乎每天都在“Culture Shock”中度过,这令我一度怀疑自己的适应能力和学习能力。 由于大学专业是IT,主修电子商务,所以对于通信领域的知识我几乎是一片空白。我搜罗了大量的产品和技术文档、胶片资料,准备开始从头学起,可是刚一打开便遇到了“拦路虎”——虽然我是华人,会说中文也看得懂中文,但中学以后的课程都是英文授课,现在看起中文资料来,很多地方我很难抓住其真正含义;而对于英文材料呢,我也很难准确给出对应中文的精确表达。刚开始,我和中方同事们讨论问题时,经常“大眼瞪小眼”,互相不懂对方表达的意思是什么。 有一次,同事教我操作配置器:“点一下这个,然后回车就行了。”“回车?什么车?哪有车?”从未听过这个词汇的我,当时那叫一个满头雾水。看到我的表情,同事瞬间忍俊不禁,敲了一下键盘上的“Enter”键,我这才明白,原来“Enter”的中文叫“回车”啊! 后来,我开始有意识地慢慢去积累、训练自己掌握一些中文专业术语和惯用的表达方式,平时坚持多聊、多看、多理解,逐渐掌握了要领。时间一长,沟通自然顺畅了很多,我的中文表达越来越溜了。每当我说了什么内部“行话”,同事们就会打趣我说:“欣仪,你真的不是中国人吗?” 语言虽然关过了,但我还在努力适应华为的工作节奏和风格。马来西亚人的生活节奏比较慢,大家都是慢悠悠地生活和工作。但是华为的风格给我感觉就是“雷厉风行,讲究效率”,尤其在投标项目的时候,每天都像打仗一样,目标明确、节奏紧张,所有人都在陀螺般地高速运转,这对我来说真是不小的挑战。 刚开始做项目时,我有很多问题想向专家请教,于是在邮件上洋洋洒洒地写得十分详细,发送后就默默地等待回复,哪怕有时候半天都没有得到回应。导师见状,告诉我:“别等了,直接给他打电话。”“没接电话?那直接打手机看看。” 后来同事告诉我,做项目一定要懂得push, 要主动engage,遇到紧急事情可以直接打电话,千万不要害羞,不要怕张口。渐渐地,我化被动为主动,遇到问题就推动解决。随着一次次熟悉的机器女声“Welcome to join the conference”响起,我逐渐适应了主动积极的快节奏工作,这样的氛围像是一个助推器,将我迅速推进轨道,快速成长起来。 与软件组的同事们共度新年 02 波分,下一个路口遇见你 2017年至2019年期间,我从一个初出茅庐的小丫头逐渐成长为一个可以独当一面的“一姐”(谁让我们软件组只有我一个本地女生呢,哈哈)。软件部门兵强马壮,我身边不仅有热心指导我的导师,还有在各领域都非常厉害的前辈们,他们对新人格外关照,将各种业务知识倾囊相授,毫无保留地向我分享他们的宝贵经验。 然而很快挑战就来了。2019年年中,软件改革正在进行,部门人员有所调整,中方员工都要回到深圳总部,其余本地员工需要转到各个产品小组。当时,摆在我面前的选择有无线、数通、波分、核心网等等。 我想加入波分组,心想可以尝试做下波分网设,挑战下自己。波分的组长给了我很多建议,他问我:“坦白说,波分产品比较复杂,想要做深的话,需要比较长的时间,也比较辛苦,你确定吗?如果你没考虑清楚,我不建议你选这个产品。” 回去之后我又考虑再三,觉得还是听从内心的声音,如果我单纯只是因为“难”而放弃,我怕自己以后会为“没去做”而后悔。组长见我这么坚定,点头同意了。 刚刚转入波分小组第一周,组长已经开始给我分配项目,这一下我感受到了很大的压力:“如果我不拿出刚入职时学习软件的那股劲头,面对更复杂的波分系统,我可能会进步很慢。”我憋了一股劲,开始加班加点学习波分产品知识。每天下班后,只要看到组长有时间,我便请求他帮忙给我“开小灶”,给我恶补业务知识。从波分基础到波分设计,我力求掌握每个环节并且融会贯通。 组长的辅导专业而又细致,不仅帮我制定了详细的培训计划,还帮助我有节奏循序渐进地展开学习。每天培训之前,他都会要求我自行讲解一遍前一天的课程内容,碰到有“盲点”的地方,他会再仔仔细细、深入浅出地为我解释一遍,无论工作如何繁忙,在我请教时,他总是不厌其烦地为我解答。同时,组长还为我分配了非常专业的前辈做我的导师,稍有空闲,导师就会与我讨论波分的知识,分享项目经验,锻炼我积极思考问题的能力。组长和导师给了我莫大的帮助和指导,让我感受到组织对我的关注与期待,更加鞭策着我积极发挥起主观能动性。 学习是枯燥的,但是获得知识的成就感是令人喜悦的,一步一步,我从那个初来乍到、一问三不知的波分小白,在随后不到三个月的时间里,渐渐具备初步网络规划及承接小项目的能力。 这天,组长找到我说:“欣仪,印尼有一个项目快发标了,比较紧急,你出差支持下吧,签证下来马上出发,你也好好锻炼锻炼。”就这样,我带着小小的自信又有些忐忑不安的复杂心情来到了印尼,投入到紧张的投标项目中。 这个项目最大的挑战就是需要两周快速交标,包括技术标和商务标,项目组面临的压力很大。考虑到同时要满足客户需求和保证商务竞争力,项目组决定采用最新产品进行竞标,但由于新产品尚未上市,资料较少,现有工具无法提供支持,我们只好争分夺秒地开始一条一条地手动输入报价。为了避免出错,新产品的每一个特性、每一个细节,我都找到研发同事一一确认清楚;为了保证交标件的质量,项目组与机关专家反复沟通评审方案,确保方案具备竞争力和可实施性。 功夫不负有心人,最后我们的项目成功中标了。初战告捷,代表处发了喜报表示祝贺和表彰,看到自己的名字在上面,我感到这是对我莫大的鼓励和肯定。 印尼日惹-婆罗浮屠 03 穿上黑袍,两次闯中东 我曾两次出差沙特。2019年中,当时还在软件小组,由于部门扩展业务,组长让我出差沙特担任项目投标经理,那会儿沙特刚刚放开女性可以单独入境的政策,恰好让我有了这样的机会。 之前一提到沙特,白袍、黑袍、石油、沙漠、王子、土豪国家,这一串关键字就会从脑海里冒出来,构成了我对这个国家的全部印象。等到真要去了,人生第一次出差,第一次一个人飞去那么远的地方,第一次穿上黑色长袍,我胆战心惊地踏上了这个神秘的国度。 第一次承担投标经理的工作,说实话心里还真没底,刚开始时项目组成员热火朝天讨论着项目时,我根本融入不了。所幸负责跟我接口的是一名中文说得比我还溜的中东员工,大家都亲切的称呼他为“老穆”。作为PMO(项目管理办公室)“老司机”,老穆悉心指导我,从发标到交标,需要走的流程、注意事项,他都事无巨细、一丝不苟地教给我。 渐渐地,我找到了状态,一线同事看到我每天的学习劲头,打趣我说:“欣仪,原来你是来短期出差的,我还以为你是来当老穆的徒弟呢。”不负老穆的教导,在项目运作中,积极响应一线需求,协调项目组成员输出无质量问题的交付件,并确保项目运作规范,最后项目顺利交标。 项目顺利结束后,我在回马来西亚的路上思考着此次中东之行的收获。之前做投标项目,我对项目还没有全局的认识,现在做了投标经理以后,我的思维得到了不同的锻炼,考虑事情也更加全面了。 沙特阿拉伯-Edge of the world 2020年2月,沙特波分项目发标,需要人到现场支持项目投标。组长问我:“欣仪,你想去再去一次沙特吗?”我想到这是一个能更快将波分网络设计规划这一块能力建立起来的好机会,于是毫不犹豫地答应了。 待到三月中旬,由于疫情原因,沙特开始实行封城宵禁,客户也因此推迟发标。但项目组成员并没有松懈下来,大家持续优化方案,仔细打磨好方案和网络设计,希望在项目正式发标前,做好万全的准备。 等到四月末,客户正式发标。由于项目范围大,很多细节需要优化,而此时距离交标只有两周时间,非常紧迫。我开始与项目组成员开会沟通方案,每一天从早晨到凌晨,我几乎没有挪动过位子,反复沟通方案、评审方案、刷新报价,只为呈现给客户呈现最佳方案和高质量的交标件。  顺利交标的当天,我站在窗前,欣赏了一下久违的蓝天,还没来得及好好休息,转头就参与多轮澄清和方案优化之中,直到最终项目成功中标,我心里一块大石头这才落了地。 尽管外部条件恶劣,胜利来之不易,不知不觉中,我也变成了真正的“奋斗者”,体会到了“胜则举杯相庆,败则拼死相救”的华为精神内核。在华为的工作总是特别的忙碌,但在忙碌之余,我和小伙伴们也喜欢玩两局“王者农药”,我特别喜欢里面的一个英雄角色——赵云,非常认同他的那句台词:“心怀不惧,方能翱翔于天际!”与诸君共勉之。 -END- 来源 | 《华为人》人荐人爱电子专栏 | 整理文章为传播相关技术,版权归原作者所有 | | 如有侵权,请联系删除 | 【1】嵌入式研发10多年,工程师悟出这些道理 【2】当谈起嵌入式工程师,究竟在谈些什么 【3】嵌入式工程师出路之我见:就业,技术,行业... 【4】为什么嵌入式工程师会对8位MCU有误解? 【5】嵌入式工程师结合经历聊硬件工程师和软件工程师哪个更有前途? 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-23 关键词: 程序员 互联网

  • 那些程序员爆笑段子,扎心了…

    特殊 “2020是属于程序员的一年。” “怎么说?” “2020-1024=996。” 真相 “你们程序员是不是没见过下班时候的太阳?” “也不是啦,夏天的时候还是能看到的。” “哦哦,夏天黑得比较晚。” “不是,是天亮得比较早。” 理由 一个程序员去面试。 面试官:你毕业到现在才两年,履历上三年经验是怎么来的? 程序员:加班来的。 愿望 一位程序员无意中救了一个妖怪,妖怪说可以满足他一个愿望,条件是:无论什么愿望,他的仇人都将得到他所得到东西的两倍。 程序员点点头说:我希望每天睡满12小时。 区别 很多男孩子听到Mac觉得是电脑; 很多女孩子听到Mac觉得是口红; 程序员听到Mac觉得是物理地址。 资质 程序员简直是世界上最适合谈恋爱的人:他们整天都在思考一个问题:我又哪里做错了。 结果 程序员A:我去相亲网站找女朋友了。 程序员B:找到了吗? 程序员A:找到了他们页面的一个bug。 失望 我本来以为和一个做IT的书呆子女谈恋爱会很有趣。 直到她在脱下我的内裤后大喊:“404!” 方案 一句话教你成为IT专家:重启解决90%的问题,重装解决99%的问题,重买解决100%的问题。 对策 四个工程师同乘一辆车,车打不着火。 机械工程师:启动装置坏了。 电气工程师:电池坏了。 化学工程师:油不干净。 IT工程师:要不咱们先下车再上车试试? 扎心 青年问禅师:我是搞IT的,每天压力很大,吃不好,睡不香,不能顾家,还挣不到多少钱。我该怎么办? 禅师右手捂着左胸,不语。 青年追问道:您是说不要抱怨,只要问心无愧,对得起心中的梦想,对吗? 禅师摇摇头:我出家前就是搞IT的,今天又听你说这些,心里堵得慌! 悲剧 去程序员朋友家里蹭住,晚上洗澡的时候,翻遍了整个卫生间,都没有找到洗发水,刚想开口问突然眼眶就湿了。 -END- 来源 | 菜鸟教程 | 整理文章为传播相关技术,版权归原作者所有 | | 如有侵权,请联系删除 | 【1】嵌入式研发10多年,工程师悟出这些道理 【2】当谈起嵌入式工程师,究竟在谈些什么 【3】嵌入式工程师出路之我见:就业,技术,行业... 【4】为什么嵌入式工程师会对8位MCU有误解? 【5】嵌入式工程师结合经历聊硬件工程师和软件工程师哪个更有前途? 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-10-23 关键词: 程序员 互联网

首页  上一页  1 2 3 4 5 6 7 8 9 10 下一页 尾页
发布文章

技术子站

更多

项目外包