精华内容
下载资源
问答
  • VSCode格式化代码功能失效的bug解决方法 前不久我装上了黑苹果,那么为了快速转移开发环境,我使用了VSCode(Visual Studio Code下面简称VSCode)的插件Settings Sync来同步个人设置和其他常用插件,如果不熟悉...
        

    VSCode格式化代码功能失效的bug解决方法

    前不久我装上了黑苹果,那么为了快速转移开发环境,我使用了VSCode(Visual Studio Code下面简称VSCode)的插件Settings Sync来同步个人设置和其他常用插件,如果不熟悉Settings Sync的可以参考之前我写的一篇文章《Visual Studio Code 设置同步到github的插件介绍及使用方法(Settings Sync)》来使用。

    现象

    当然本文并不是介绍同步,而是要说同步后的编码过程中出现的异常。在Mac下安装好VSCode,用Settings Sync同步成功后,接着git clone正在开发的项目到本地,开发过程中,却发现一个非常奇怪的问题:所有的格式化代码的功能都失效了。Mac下使用快捷键“Alt+Shift+F”(我用的windows键盘),却提示,“当前没有安装“xxx”文件的文档格式化程序。”!我的Vue,SCSS代码都无法正常格式化!这个非常令人不爽,难道Mac下的VSCode会有格式化代码功能的缺失?和Windows版本的VSCode功能不一致?我觉得不太可能。于是重启回到Windows 10,重新拉了项目测试,毫无问题。无论是Windows还是Mac,都是最新版的Visual Studio Code。

    分析

    无奈之下去google了一下格式化代码的问题,发现很多人都遇到过,有的人说重装VSCode,但是我才新装的,所以排除了,但是重装这个词让我想起一个东西,就是这些格式化代码工具,例如VeturPrettier,他们正常运行的时候都是会在编辑器中产生一个服务或者提示,而失效状态下是看不到的。于是我尝试把Vetur插件停用,重新加载再启用,然而还是无效!

    想来想去,插件也安装了,编辑器也是新装的,为何插件没起到作用,突然记起之前Windows下的输出面板中是有Vue Language Server的,而现在却没有,是不是要重新安装插件呢,或者说通过Settings Sync自动化同步插件安装的功能还存在一些其他的问题呢?

    解决方案

    带着疑问我尝试着将Vetur和Prettier卸载,然后再重新安装,启动VSCode,打开项目,切换到一个Vue页面,终于看到了Vetur的服务,比如下面这张图中表现了正常的格式化功能的效果(截图为我解决问题后的图片)

    正常的格式化插件效果

    图中看到这里有个Vue Language Server,才是真正表示Vetur插件正常,右下角还有个Prettier,说明一切正常,再试了一下使用快捷键“Alt+Shift+F”,也终于可以正常格式化代码了!问题完美解决。

    结论

    有时候自动化工具安装的插件可能会存在一些问题,虽然不排除我这个问题发生的偶然性。

    另一方面,重装软件有时候能解决问题,不过需要针对问题分析,从最小的改变逐渐排除故障。如果我把VSCode重装,再用Settings Sync同步一次,也许的确可以解决问题,但是也有可能依旧存在问题,而从插件重装下手才是比较省时省力的。

    那么,如果开发中依赖插件的部分功能失效了,你也可以尝试重装插件,或许问题就能快速解决了~

    补充(2018年07月03日)

    最近GitLens插件也是时好时坏。上面的方法又不奏效了。查了插件相关文档和Issues也没找到怎么解决。

    后来无奈之下只得重装VSCode,重新使用settings sync同步了代码,问题才得以解决。

    因此,如果实在是遇到莫名其妙的插件无法正常工作的情况,看样子还是要重装编辑器了。

    这里介绍下Mac下的VSCode卸载正确姿势。开启终端:

    sudo rm -rf $HOME/Library/Application\ Support/Code
    sudo rm -rf $HOME/.vscode

    此时你可以重新下载最新的VSCode,覆盖你的Visual Studio Code.app,或者你不想用了就直接删除Visual Studio Code.app就彻底卸载了。

    展开全文
  • 代码,想说爱你不容易

    千次阅读 多人点赞 2021-02-15 17:58:41
    方面,“低代码”这个概念确实非常火,其热度丝毫不亚于曾经的“中台”。有人说,2021年是属于“云原生”的时代,看起来我们每一年都被技术的“娱乐圈”抛弃,明明连 Kubernetes 都还没有入门呢?人们已然...

    一直想写篇文章,聊一聊“低代码”这个话题。一方面,“低代码”这个概念确实非常火,其热度丝毫不亚于曾经的“中台”。有人说,2021年是属于“云原生”的时代,看起来我们每一年都在被技术的“娱乐圈”抛弃,明明连 Kubernetes 都还没有入门呢?人们已然在欢呼雀跃般地声称要抛弃 Docker 。这个世界有时就是如此地魔幻,明明我们生活在一个拥有大量基础设施的时代,我们不必再像前辈们“刀耕火种”一般地去开发软件,可我们的生存空间为什么就越来越狭窄了呢?拼多多事件过去没有多久,腾讯的阳光普照奖再次让“打工魂”觉醒,也许果真像大鱼海棠里设定的一样,人的记忆只有7秒。而另一方面,我想结合我最近开发“工作流”的感受,来吐槽下这个看起来美好的“低代码”。也许,对企业而言,引入“低代码”的确能减少研发成本,可博主并不认为,它会降低业务本身的复杂性,如果所有声称“低代码”或者“无代码”的项目,最终依然需要研发人员来作为收场。对此,我想说,对不起,这不是我想要的“低代码”。

    低代码发展现状

    或许,一个人成熟的标志就是,在面对一个未知的事物的时候,决不会不由分说地一通吐槽,就像一个人在职场上,你不能永远都只是学会抱怨,相对于抱怨,人们更希望听到的是解决方案。所以,一个人的成长,本质上就是不断学会为自己、为别人找解决方案的过程,前者是为了认识自我,而后者是为了交换资源。所以,在听我吐槽“低代码”前,不妨先一起来看看低代码的发展现状。

    低代码产品发展现状

    国外趋势

    有人认为,“低代码”的兴起源于钉钉的低代码应用 易搭 的落地。诚然,巨头企业的每一个动向都引领着整个行业的风潮,可低代码这个概念最早要追溯到1980年。彼时,IBM 的快速应用程序开发工具(RAD)被冠以新的名字——低代码,这是低代码这个概念首次面向大众,此后的40年里,国外诞生了诸如 OutsystemMendixZoho Creator 等等的产品,整体发展相对缓慢。直到2015年以后,AWS、Google、Microsoft 和 Oracle 等巨头开始入局低代码领域。2018年,西门子更是宣布以 6 亿欧元收购低代码应用开发领域的领导者 Mendix 、快速应用开发的低代码平台 Outsystem 获得 3.6 亿美金的投资,低代码平台市场开始火爆起来,我们所熟悉的 Power Platform,其实就是微软的低代码开发平台,低代码领域通常都需要大量的积累和研发,需要有10到20年左右的技术沉淀。

    国内风云

    国内的低代码领域,相比国外发展起步较晚,可依然涌现出像牛刀APICloudiVX搭搭云、氚云、简道云、云表、宜搭云等等产品。从整体上而言,这类这类产品基本上都提供了可视化搭建环境,都声称无需编码即可完成业务系统的搭建。其实,从一名程序员的初心出发,我们所做的一切努力都是为了以后不写代码。经常有人问,怎么样可以做到零缺陷、零 Bug ,其实不写代码就好啦!我们并不担心低代码让我们失业,相反地,如果低代码可以消化掉 30% 的垃圾项目,那么,我们将会有更多的时间去做些有意义的事情,而不是在一个“劣币驱逐良币”的市场里,靠着 996 来争个你死我活。而从低代码的商业价值角度来看,SalesforceAppianJoget 这三家公司均已上市,MendixOutsystem 更是估值 10 亿美元以上的独角兽公司,这正是巨头们入局低代码的原因所在。

    低代码领域,目前关注的重点主要集中在:表单生成和处理工作流生成和管理办公协作人力资源客户关系ERP 等企业应用上,就如同 SAP金蝶SCM 等企业软件一样,每一个软件都曾声称能帮助企业解决某一类问题,低代码领域同样遵循“二八原则”,即 80% 的场景,通过定义的方法论、方式、工具集能够实现;而剩下的 20% 的场景或许实现不了,需要使用者通过扩展的方式来自行解决。譬如,针对大多数企业都存在的 CRUD 的需求,通过在线的 Excel 表格来实现基于表的业务驱动。例如 SeaTable 就是这类主打协同工作的产品;针对大多数企业都存在的审批类的需求,则可以通过可视化的工作流设计系统来完成。例如 葡萄城SpreadJS活字格 ,同样可以视为低代码平台,甚至早期的 .NET 开发者被人“黑”只会拖控件,这难道不是广义上的低代码吗?

    低代码产品形态

    搞清楚整个低代码的发展现状以后,那么,整个低代码领域主要的产品形态有哪些呢?了解其主要的产品形态,对于我们形成低代码的直观印象非常有帮助。在我看来,主要分为四类:

    • 表单生成类:以 宜搭云JNPF 为代表,主张通过可视化的设计器来完成页面布局、编排、设计,即所谓的“所见即所得”,类似的还有 iVX
    • 工作流生成类:以 Mendix 和 Outsystems 为代表,提供组件式的服务,通过编排工作流来实现特定的业务,即通过流程图的方式来实现业务逻辑部分,不同的节点代表不同的功能,不同的线条代表不同的分支。
    • 协同工作类:以 SeaTable 为代表,基于表的业务驱动开发平台,可以以不同的维度管理数据、对数据可视化、共享协作等等,同时具备自动化规则、脚本运行等能力。
    • 服务聚合类:以 APICloud 为代表,基于API聚合的组件市场工具,通过流程管理工具,可以管理整个应用的开发周期,从产品、设计开始,到研发测试和运营。

    所以,整体而言,低代码产品的核心是表单引擎流程引擎(BPM),外围支撑是BI引擎、*协同工作服务聚合等等,目前,市面上主流的低代码产品,表单引擎和流程引擎(BPM)基本是标配,所以,严格地说起来,上面的分类并不严谨,因为基本上都是混合式的产品形态。下面是部分低代码产品的截图:

    某“低代码”二维码应用

    某“低代码”人力资源管理系统

    某“低代码”可视化搭建系统

    低代码研发痛点

    相信大家都知道了,接下来的内容是本文真正的重点。为什么要这样说呢?这主要和博主自身的工作有关系,简单来说,公司需要一个想象中的可视化设计器,业务人员只需要通过拖拽就可以完成业务逻辑的编排,而开发人员则需要负责对外输出组件供业务人员使用。这听起来特别像我们刚刚讨论的第二种产品形态对不对?听起来非常美好对不对?我承认这个想法真的符合潮流、非常的“低代码”。所以,我们前期采用了微软的 Windows Workflow Foundation 框架,使用以后的效果大概是下面这个样子:

    Windows Workflow Foundation 设计器

    多人协作不便

    那么,我们在这个过程中到底遇到了哪些问题呢?首先,这种可视化编辑的场景,遇到的第一个问题就是多人协作,如果你使用过腾讯文档、钉钉文档这类在线文档类产品,你应该能领悟到我说的这个点。微软的这个框架是采用XMAL这种格式来储存数据的,虽然理论上可以通过 Git 实现多人协作,实际维护起来表示非常地麻烦,所以,我们最终由单人去维护这些工作流。那么,更广义上的低代码又该如何解决这个问题呢?流程图这种东西,就是一种看起来非常清晰,改起来非常麻烦的东西,就像一条锁链一样,你要不停地断开和接上。

    孱弱的表达能力

    其次,是流程图这种表现方式的“表达”问题,就像你如果需要在SQL里表示循环要用到游标一样,这类工作流都无法表达程序三个结构中的循环,更不用说表达力孱弱的表达式啦,所以,这就造成一个非常尴尬的问题,你在流程图里写不了太复杂的表达式,一旦业务人员写不出来,就需要开发人员去写辅助性质的代码,类似正则字符串插值字符串处理、格式化等等的函数或者API非常缺乏。当然,我最无法忍受的,就是组件与组件间传值的方式,你除了返回JSON和写表再没有其它方式,更何况这个JSON返回给某个组件了,人家还未必能直接解析直接使用呢?因为编辑器无法绑定这种复杂的数据结构。

    混乱的变量和参数

    接下来,我最想吐槽的是,关于全局变量参数的问题,在流程图中你经常需要各个分支的标志位(Flag)或者是临时变量,然后你就看到了那种“变量满天飞”的混乱局面,简直像极了你刚开始写的代码,你需要顺着每个线条,逐个点开每个组件的属性面板,查看它都使用了哪些参数或者变量,至此,你终于明白了它的数据是如何流动的。从前,乡愁是成千上万行的代码;现在,乡愁是剪不断理还乱的“蜘蛛网”。多年前,我对虚幻引擎(Unreal)的蓝图功能有多么憧憬;多年后,我对这种基于流程引擎的低代码就有多排斥。尤其是,当我需要复用某一段逻辑的时候,我只能小心翼翼地选中节点和线条,然后再拷贝过去。

    动态计算/事件顺序/黑盒子

    最后,我参考了一位被 Power Apps 所折磨的朋友的意见,除了上面提到的这些问题, 属性面板或者公式无法使用动态计算的值,类似Vue 里面的计算属性,从实际使用的体验来看,这类以流程引擎和表单引擎为主要卖点的低代码工具,其实都会存在这样的问题,而面对这种问题,一般只能通过trick的手段来解决。同样地,Power Apps 事件顺序的不确定问题,因为低代码实际上是框架提供了某种机制,可以帮你完成某个事情,所以,低代码内部对于使用者来说,完全就是一个黑盒子,譬如 Power Apps 在无网络的环境下使用会卡顿,调试起来非常不便等等。

    本文小结

    坦白来讲,这篇博客实在没什么“技术含量”,无非是按照一个月前的计划在整理内容。我对“低代码”持一种中立的态度,作为程序员,我是希望有这样的技术来简化流程,可以让研发人员从枯燥的“增删改查”中解放出来,留出时间去做更多有意义、有价值的事情。当我了解了低代码和零代码的差异以后,我突然明白,我需要的其实是零代码,因为我希望那帮业务人员能自己搞定,这样就不用再来烦我,可经历这段时间的“低代码”,我清醒地认识到,这个想法根本不现实。一来业务人员并不像他们想象的那样,除了不会写代码以外无所不能;二来业务的复杂性满足守恒定律,它永远不会消失,只会从一种形式变成另一种形式也许,低代码真的能帮企业省不少钱;也许,企业最喜欢做的事情,就是花点小钱招人外包做这种事情。但我依然想告诫开发者们,不要去追逐这些看起来美好的东西,对企业来说,它今天使用 A 技术,明天使用 B 技术,完全无关紧要。可对于个人而言,这个选择显得非常重要。看一看曾经的 SAP 咨询顾问就知道了,如果有一天 SAP 都倒闭了,你掌握着这些只有在 SAP 上能发挥作用的技术有什么用呢?对技术人员来说,学习通用型的知识和技能,永远比把鸡蛋放在一个篮子里要更保险

    展开全文
  • 数据链路层的主要功能

    万次阅读 多人点赞 2019-05-28 11:03:46
    数据链路层主要功能数据传输差错控制数据链路层的三个基本问题1.封装成帧2. 透明传输3. 差错检测 数据传输 透明传输其实就是指无论是什么报文都可以传输。数据链路层将网络层协议封装成帧时,会首部和尾部分别...

    主要功能概述

    数据链路层最基本的服务是将源计算机网络层来的数据可靠的传输到相邻节点的目标计算机的网络层。为达到这一目的,数据链路层必须具备一系列相应的功能,主要有:如何将数据组合成数据块(在数据链路层中将这种数据块称为帧,帧是数据链路层的传送单位);如何控制帧在物理信道上的传输,包括如何处理传输差错,如何调节发送速率以使之与接收方相匹配;在两个网路实体之间提供数据链路通路的建立、维持和释放管理。这些功能具体表现在以下几个方面。

    数据链路层的三个基本问题

    1. 封装成帧

    为了向网络层提供服务,数据链路层必须使用物理层提供的服务。而物理层我们知道,它是以比特流进行传输的,这种比特流并不保证在数据传输过程中没有错误,接收到的位数量可能少于、等于或者多于发送的位数量。而且它们还可能有不同的值,这时数据链路层为了能实现数据有效的差错控制,就采用了一种“帧”的数据块进行传输。而要采帧格式传输,就必须有相应的帧同步技术,这就是数据链路层的“成帧”(也称为“帧同步”)功能。

    • 封装成帧(framing):就是在一段数据的前后分别添加首部和尾部,这样就构成了一个帧。接收端在收到物理层上交的比特流后,就能根据首部和尾部的标记,从收到的比特流中识别帧的开始和结束。
    • 分组交换的一个重要概念:就是所有在因特网上传送的数据都是以分组(即IP数据报)为传送单位。
    • 网络层的IP数据报传送到数据链路层就成为帧的数据部分。在帧的数据部分的前面和后面分别添加上首部和尾部,就构成了一个完整的帧。
    • 帧长等于数据部分长度加上帧首部和帧尾部的长度,而首部和尾部的一个重要作用就是进行帧定界(即确定帧的界限)。
    • 首部和尾部还包含许多必要的控制信息,在发送帧时,是从帧首部开始发送。
    • 各种数据链路层协议都要对帧首部和帧尾部的格式有明确的规定。
    • 为了提高帧的传输效率,应当使帧的数据部分长度尽可能大于首部和尾部的长度。但是,每一种链路层协议都规定了帧的数据部分的长度上限——最大传送单元MTU(Maximum Transfer Unit)。
      在这里插入图片描述
    • 当数据是由可打印的ASCII码组成的文本文件时,帧定界可以使用特殊的帧定界符。
    • 控制字符SOH(Start Of Header)放在一帧的最前面,表示帧的首部开始。另一个控制字符EOT(End Of Transmission)表示帧的结束。他们的十六进制编码分别是01(二进制是00000001)和04(二进制是00000100)。
      在这里插入图片描述
    • 采用帧传输方式的好处是,在发现有数据传送错误时,只需将有差错的帧再次传送,而不需要将全部数据的比特流进行重传,这就在传送效率上将大大提高。但随后很快又恢复正常,于是重新从头开始发送刚才未发送完的帧。由于使用了帧定界符,在接收端就知道前面收到的数据时个不完整的帧(只有首部SOH,没有传输结束符EOT),必须丢弃。而后面收到的数据有明显的帧定界符(SOH和EOT),因此这是一个完整的帧,应当收下

    但同时也带来了两方面的问题:(1)如何识别帧的开始与结束;(2)在夹杂着重传的数据帧中,接收方在接收到重传的数据帧时是识别成新的数据帧,还是识别成已传帧的重传帧呢?这就要靠数据链路层的各种“帧同步”技术来识别了。“帧同步”技术既可使接收方能从以上并不是完全有序的比特流中准确地区分出每一帧的开始和结束,同时还可识别重传帧。

    2. 透明传输

    在上面提到了在数据链路层实现透明传输和封装成帧时,使用到了转义字符。在假设没有使用转义字符的前提下我们来分析一下存在的问题:

    • 由于帧的开始和结束的标记是使用专门指明的控制字符,因此,所传输的数据中的任何8比特的组合一定不允许和用作帧定界的控制字符的比特编码一样,否则就会出现帧定界的错误。
    • 当传送的帧使用文本文件组成的帧时(文本文件中的字符都是从键盘上输入的),其数据部分显然不会出现像SOH或EOT这样的帧定界控制字符。可见不管从键盘上输入什么字符都可以放在这样的帧中传输过去,因此这样的传输就是透明传输。

    问题:当数据部分是非ASCII码的文本文件时(如二进制代码的计算机程序或图像等),情况就不同了,如果数据中的某个字符的二进制代码恰好和SOH或EOT这种控制字符一样,数据链路层就会错误地找到帧的边界,把部分帧收下(误认为是完整的帧),而把剩下的那部分数据丢弃(这部分找不到帧定界控制字符SOH)。这样的帧的传输显然就不是透明传输。

    在这里插入图片描述

    • 问题分析:为了解决透明传输的问题,就必须设法使数据中可能出现的控制字符“SOH”和“EOT”在接收端不被解析为控制字符
    • 解决方法:发送端的数据链路层在数据中出现控制字符”SOH”和”EOT”的前面插入一个转义字符”ESC”(其十六进制编码是1B)。而在接收端的数据链路层在将数据送往网络层之前删除这个插入的转义字符。这种方法称为字节填充(byte stuffing)或字符填充(character stuffing)。如果转义字符也出现在数据当中,那么解决方法仍然是在转义字符的前面插入一个转义字符。因此,当接收端收到连续的两个转义字符时,就删除其中前面的一个
      在这里插入图片描述

    3. 差错检测

    传输差错:可分为两大类,一类就是最基本的比特差错,另一类就是收到的帧并没有出现比特错误,但却出现了帧丢失帧重复帧失序

    • 比特差错:就是比特在传输过程中可能会产生差错,即1可能会变成0,0可能会变成1。比特差错是传输差错中的一种。
    • 三个帧:[#1]-[#2]-[#3],假定在接收端收到的却有可能出现的情况:
      (1)帧丢失:收到[#1]-[#3](丢失了[#2])。
      (2)帧重复:收到[#1]-[#2]-[#2]-[#3](收到两个[#2])。
      (3)帧失序:收到[#1]-[#3]-[#2](后面发的帧反而先到达了接收端,这与一般的数据链路层传输概念不一样)。
    • 误码率BER(Bit Error Rate):就是在一段时间内,传输错误的比特占所传输比特总数的比率。例如,误码率为10 ^ (-10)时,表示平均每传送10^10个比特就会出现一个比特的差错。误码率与信噪比有很大的关系,如果提高信噪比,就可以使误码率减小

    问题:实际的通信链路并非理想的,它不可能使误码率下降到零。
    问题分析:为了保证数据传输的可靠性,在计算机网络传输数据时,必须采用各种检测措施。
    解决方法:目前在数据链路层广泛使用了循环冗余检验CRC(Cyclic Redundancy Check)的检测技术。
    注:在数据链路层使用CRC检验,能够实现无比特差错的传输,但这还不是可靠传输

    补充:
    OSI的观点是必须把数据链路层做成是可靠传输的。因此在CRC检测基础上,增加了帧编号、确认和重传机制。收到正确的帧就要向发送端发送确认。发送端在一定的期限内若没有收到对方的确认,就认为出现了差错,因而就进行重传,直到收到对方的确认为止。
    这种方法在历史上曾经起到很好的作用。但现在的通信线路的质量已经大大提高了,由通信链路质量不好引起差错的概率已经大大降低。

    因特网广泛使用的数据链路层协议都不适用确认和重传机制,即不要求数据链路层向上层提供可靠传输的服务(因为这要付出的代价太高,不合算)。如果在数据链路层传输数据时除了差错并且需要进行改正,那么改正差错的任务就由上层协议(如,运输层TCP协议)来完成。实验证明,这样可以提高通信效率。

    MAC寻址

    这是数据链路层中的MAC子层主要功能。这里所说的“寻址”与“IP地址寻址”是完全不一样的,因为此处所寻找地址是计算机网卡的MAC地址,也称“物理地址”、“硬件地址”,而不是IP地址。在以太网中,采用媒体访问控制(Media Access Control, MAC)地址进行寻址,MAC地址被烧入每个以太网网卡中。这在多点连接的情况下非常必需,因为在这种多点连接的网络通信中,必须保证每一帧都能准确地送到正确的地址,接收方也应当知道发送方是哪一个站。

    链路层向网络层提供的服务

    数据链路层的设计目标就是为网络层提供各种需要的服务。实际的服务随系统的不同而不同,但是一般情况下,数据链路层会向网络层提供以下三种类型的服务:

    1. 无确认的无连接服务

    “无确认的无连接服务”是指源计算机向目标计算机发送独立的帧,目标计算机并不对这些帧进行确认。这种服务,事先无需建立逻辑连接,事后也不用解释逻辑连接。正因如此,如果由于线路上的原因造成某一帧的数据丢失,则数据链路层并不会检测到这样的丢失帧,也不会恢复这些帧。出现这种情况的后果是可想而知的,当然在错误率很低,或者对数据的完整性要求不高的情况下(如话音数据),这样的服务还是非常有用的,因为这样简单的错误可以交给OSI上面的各层来恢复。如大多数局域网在数据链路层所采用的服务也是无确认的无连接服务。

    2. 有确认的无连接服务

    为了解决以上“无确认的无连接服务”的不足,提高数据传输的可靠性,引入了“有确认的无连接服务”。在这种连接服务中,源主机数据链路层必须对每个发送的数据帧进行编号,目的主机数据链路层也必须对每个接收的数据帧进行确认。如果源主机数据链路层在规定的时间内未接收到所发送的数据帧的确认,那么它需要重发该帧。 这样发送方知道每一帧是否正确地到达对方。这类服务主要用于不可靠信道,如无线通信系统。它与下面将要介绍的“有确认的面向连接服务”的不同之处在于它不需要在帧传输之前建立数据链路,也不要在在帧传输结束后释放数据链路。

    3. 有确认的面向连接服务

    大多数数据链路层都采用向网络层提供面向连接确认服务。利用这种服务,源计算机和目标计算机在传输数据之前需要先建立一个连接,该连接上发送的每一帧也都被编号,数据链路层保证每一帧都会被接收到。而且它还保证每一帧只被按正常顺序接收一次。这也正是面向连接服务与前面介绍的“有确认无连接服务”的区别,在无连接有确认的服务中,在没有检测到确认时,系统会认为对方没收到,于是会重发数据,而由于是无连接的,所以这样的数据可能会复发多次,对方也可能接收多次,造成数据错误。这种服务类型存在3个阶段,即:数据链路建立、数据传输、数据链路释放阶段。每个被传输的帧都被编号,以确保帧传输的内容与顺序的正确性。大多数广域网的通信子网的数据链路层采用面向连接确认服务。

    以太网采用无连接的工作方式,读发送的数据帧不进行编号,也不要求对方发回确认。目的站收到有差错的帧就把他丢弃,不采取其他行为。

    其他知识点

    • 局域网的优点:具有广播功能,从一个站点可以很方便的访问全网;便于系统的扩展和逐渐演变;提高了系统的可靠性、可用性和生存性。
    • 以太网采用的协议是具有冲突检测的载波监听多点接入CMSA/CD。协议的要点是:发送前先监听,便发送边监听,一旦发现总线上出现了碰撞,就立即停止发送。然后按照退避算法等待一段随机时间后再次发送。因此,每一个站在自己发送数据之后的一小段时间内,存在着遭遇碰撞的可能性。以太网上各站点都平等的争用以太网信道。
    展开全文
  • 谷歌开源内部代码评审规范

    千次阅读 2019-10-08 15:33:58
    谷歌成立于 1998 年,以搜索起家,到目前为止已经发展了 21 年。过去的 21 年中,谷歌不断创新,开发了七款产品,拥有超过 10 亿级活跃用户,谷歌的工程师文化...代码评审的主要目的是确保代码库的整体质量随时间...

    谷歌成立于 1998 年,以搜索起家,到目前为止已经发展了 21 年。在过去的 21 年中,谷歌不断创新,开发了七款产品,拥有超过 10 亿级活跃用户,谷歌的工程师文化一直被认为是优秀且特别的。近日,谷歌开源了其内部一直在使用的代码评审规范,InfoQ 对其进行了翻译和整理,分享给广大开发者,看看谷歌工程师是如何评审代码的。

    谷歌开源内部代码评审规范

    代码评审标准

    代码评审的主要目的是确保代码库的整体质量随时间推移逐步得到提升,所有代码评审工具和过程都是为了实现这一目标而设计的。

    为了实现这个目标,必须做出一系列权衡。首先,开发人员的开发任务必须要有所进展。如果他们不提交改进的代码,代码库质量就得不到改善。此外,如果评审人员过于严格,开发人员就没有动力进行持续改进。

    评审人员的职责是确保每个 CL(变更列表)的质量,保证代码库整体质量不会随着时间的推移而下降。这是一项艰巨的任务,因为代码库整体质量常常会随着每次提交代码质量的小幅下降而退化,特别是有时候开发团队时间很紧,并认为必须走捷径才能完成交付任务。

    评审人员要对他们评审的代码负起责任,确保代码库保持一致性和可维护性。

    以下是可在代码评审中使用的准则:

    一般来说,如果 CL 达到可以提升系统整体代码质量的程度,就可以让它们通过了,即使它们可能还不完美。

    这是所有代码评审准则的最高原则。

    当然,也有例外的时候。例如,如果 CL 中包含了系统不需要的功能,那么即使代码写得很好,评审人员也可以拒绝让它们通过。

    这个世界上没有“完美”的代码,只有更好的代码。评审人员不应该要求开发人员对 CL 中的每一个微小部分都进行细致入微的打磨,而应该在满足需求和变更重要性之间做出权衡。评审人员不应该追求完美,而应该追求持续改进。如果一个 CL 能够从整体上提高系统的可维护性、可读性和可理解性,那它就不应该仅仅因为它不够“完美”而被延迟几天甚至几周。

    评审人员应该提供建议,告诉开发人员哪些方面可以做得更好。但如果这些建议不是很重要,可以在前面加上像“Nit:”这样的前缀,让开发人员知道这只是一个改进建议,他们也可以选择忽略。

    指导

    代码评审的一个作用是向开发人员传授知识,比如关于一门语言、一个框架或一般软件设计原则的知识。分享知识是提升系统代码质量的一个组成部分。但要注意,如果你的建议纯粹是带有教育性质的,并且对于满足本文所描述的标准来说并不是那么重要,那么请在前面加上“Nit:”,或者以其他方式告诉开发人员,他们并不一定要在 CL 中解决这些问题。

    原则

    • 客观的技术和数据比个人意见和偏好更重要。

    • 在代码风格方面,可以参考谷歌风格指南( http://google.github.io/styleguide )。任何没有在这个风格指南中出现的东西(比如空格等)都属于个人偏好。代码风格应该与原有代码保持一致,如果之前没有规定代码风格,可以使用代码提交者的代码风格。

    • 软件设计从来就不只风格问题,也不只是个人偏好问题。它们建立在一些基本原则之上,所以我们应该基于这些原则做出权衡,而不只是基于个人偏好。有时候,一个问题有多种解决方案,如果开发人员能够证明(通过数据或基于可靠的工程原理)几种解决方案是同样有效的,那么评审人员应该接受开发人员的选择,否则就应该基于软件设计标准原则做出决定。

    • 如果没有其他适用的原则,评审人员可以要求开发人员与当前代码库保持一致,只要不破坏系统的整体代码质量。

    解决冲突

    在代码评审过程中出现冲突时,开发人员和评审人员首先要尝试根据本文、CL 作者指南( https://google.github.io/eng-practices/review/developer/ )和评审人员指南( https://google.github.io/eng-practices/review/reviewer/ )达成一致意见。

    如果很难达成一致意见,评审人员和开发人员可以进行面对面会议或者视频会议,而不是只是试图通过代码评审评论板来解决冲突。

    如果还不能解决问题,那么就要考虑把问题升级,进行更广泛的团队讨论。让团队负责人参与进来,请求代码维护人员作出决定,或请求工程经理提供帮助。不要因为开发人员和评审人员无法达成一致意见就让 CL 一直挂在那里。

    代码评审要注意哪些事情?

    设计

    代码评审中最重要的部分是 CL 的总体设计。CL 中不同代码段之间的交互是有意义的吗?这个变更应该属于代码库,还是属于某个包?它与系统的其他部分可以良好地集成吗?现在是引入这个变更的好时机吗?

    功能

    这个 CL 是否达到了开发人员的目的?开发人员的意图对代码用户来说有好处吗?代码“用户”可以是指最终用户(他们受代码变更的影响)和开发人员(将来要“使用”这些代码)。

    大多数情况下,我们希望开发人员先测试好 CL,确保它们能够正确运行。但作为评审人员,你仍然要考虑一些边缘情况,比如查找并发问题,尝试像用户一样思考问题,并找出只是通过阅读代码无法看到的错误。

    如果愿意,你也可以验证一下 CL。如果一个 CL 会影响用户,比如做出了 UI 变更,那么这是验证 CL 的好时机。如果只是看代码,很难理解一些变更将如何影响用户。对于这样的更改,如果不方便自己运行,可以让开发人员提供功能演示。

    另一个重要的考虑点是 CL 中是否存在可能导致死锁或竞态条件的并发问题。只是简单地运行代码很难发现这类问题,通常需要有人(开发人员和评审人员)仔细思考这些问题,确保不会把它们引入到系统中。

    复杂性

    CL 比实际需要的更复杂吗?从每一层面检查 CL,细到每一行代码,它们是不是太复杂了?函数是否过于复杂?类复杂吗?“太复杂”通常意味着“阅读代码的人难以很快理解它们”,也意味着“开发人员在调用或修改这些代码时可能会引入 bug”。

    过度设计是一种特殊的复杂性,开发人员把代码写得比实际需要的更通用,或者增加了系统当前不需要的功能。评审人员要警惕过度设计,鼓励开发人员只解决现在需要解决的问题,而不是将来可能需要解决的问题。未来的问题应该在它们出现之后再去解决,因为到了那个时候我们可以看到它们的实际状况和需求。

    测试

    要求开发人员进行单元测试、集成测试或端到端测试。一般来说,CL 中应该包含测试,除非这个 CL 只是为了处理紧急情况。

    确保 CL 中的测试是正确、合理和有用的。因为测试本身无法测试自己,而且我们很少会为测试编写测试,所以必须确保测试是有效的。

    如果代码出了问题,测试会失败吗?如果代码发生改动,它们会误报吗?每一个测试都有断言吗?是否按照不同的测试方法对测试进行分类?

    请记住,测试代码也是需要维护的。

    命名

    开发人员是否使用了良好的命名方式?好的命名要能够充分表达一个项(变量、类名等)是什么或者用来做什么,但又不至于让人难以阅读。

    注释

    开发人员有没有用自然语言写出清晰的注释?他们所写的注释都是必需的吗?通常,注释应该用于解释代码的用处,而不是解释它们在干什么。如果代码不够清晰,无法自解释,那就应该简化代码。当然也有一些例外(例如,正则表达式和复杂的算法,如果能够解释它们在做什么,会让阅读代码的人受益匪浅),但大多数注释都应该指出代码中不可能包含的信息,比如这些代码背后的缘由。

    CL 附带的其他注解也很重要,比如告知一个可以移除的待办事项,或者一个不要做出代码变更的建议,等等。

    注意,注释不同于类、模块或函数文档。文档的目的是为了说明代码的用途、用法和行为。

    代码风格

    谷歌为主要编程语言和大多数次要编程语言提供了代码风格指南( http://google.github.io/styleguide/ ),所以要确保 CL 遵循了适当的指南。

    如果你想对指南中没有提及的风格做出改进,可以在注释前面加上“Nit:”,让开发人员知道这是一个你认为可以改进的地方,但不是强制性的。但请不要只是基于个人偏好来阻止 CL 的提交。

    开发人员不应该将风格变更与其他变更放在一起,这样很难看出 CL 发生了哪些变化,导致合并和回滚变得更加复杂。如果开发人员想要重新格式化整个文件,让他们将重新格式化后的文件作为单独的 CL,并将功能变更作为另一个 CL。

    文档

    如果 CL 导致用户构建、测试、交互或发布代码的方式发生了变化,请确保相关的文档也得到了更新,包括 README、g3doc 页和其他生成的参考文档。如果 CL 有移除或弃用代码,请考虑一下是否也应该删除相关的文档。如果文档缺失,要向开发人员索要。

    查看每一行代码

    查看每一行代码。有些东西可以看一看,比如数据文件、生成的代码或大型数据结构,但不要只是粗略地扫一下类、函数或代码块,并假定它们都能正常运行。显然,有些代码需要仔细检查,至于是哪些代码完全取决于你,但你至少应该要理解这些代码都在做些什么。

    如果代码很复杂或者你难以快速看懂它们,导致评审速度变慢,你要让开发人员知道,并在进行进一步评审之前让他们做一些澄清。如果你看不懂这些代码,其他开发人员很可能也看不懂。因此,要求开发人员澄清代码其实也是在帮助未来的开发人员更好地理解代码。

    如果你理解代码,但又觉得没有资格做代码评审,可以确保有资格的 CL 评审人员在代码评审时考虑到了安全性、并发性、可访问性、国际化等问题。

    上下文

    代码评审工具通常只显示被修改的代码,但有时候你需要查看整个文件,确保代码变更是有意义的。例如,你可能只看到新添加了四行代码,但如果你看一下整个文件,会发现这四行代码位于一个 50 多行的方法中,这个时候需要将这个方法拆分为更小的方法。

    你需要基于整个系统来考量 CL。这个 CL 是提升了系统的代码质量,还是让整个系统变得更复杂、更不可测?不要接受导致系统代码质量退化的 CL。大多数系统都是因为累积了很多小的变更而变复杂的,所以要尽量避免小的变更带来的复杂性。

    好的一面

    如果你在 CL 中看到一些不错的东西,要让开发人员知道,特别是当他们以一种很好的方式解决了问题。代码评审通常只关注错误的东西,但其实也应该鼓励和赞赏好的代码实践。有时候,让开发人员知道他们做对了事情比让他们知道做错了事情更有价值。

    总结

    在进行代码评审时,你要确保:

    • 良好的代码设计。
    • 功能对代码用户来说是有用的。
    • UI 变更应该是合理的。
    • 并行编程是安全的。
    • 代码复杂性不要超过应有的程度。
    • 不需要实现可能会在未来出现的需求。
    • 有适当的单元测试。
    • 精心设计的测试用例。
    • 使用了清晰的命名方式。
    • 清晰而有用的代码注释,要解释“为什么”,而不是“什么”。
    • 恰如其分的代码文档化。
    • 代码要遵循风格指南。

    检查每一行代码,查看上下文,确保你正在改进代码质量,并为表现不错的开发人员点赞。

    检查 CL

    在知道了代码评审要关注哪些东西之后,如何有效地进行跨文件代码评审呢?

    • 代码变更有意义吗?它们有没有良好的描述?
    • 先看一下代码变更中最重要的部分,它整体设计得如何?
    • 按照适当的顺序检查 CL 的其余部分。

    第一步:从整体查看代码变更

    先看一下 CL 描述,看看这个 CL 做了些什么。做出这个变更有意义吗?如果这个变更是不必要的,请立即做出回复,并解释为什么不应该发生这个变更。在你拒绝这样的变更时,可以向开发人员建议他们应该做些什么。

    例如,你可以说:“看起来你在这方面做得不错,谢谢!不过,我们正打算移除这个系统,所以现在不想对它做任何修改。或许你可以重构一下另外一个类”?

    注意,评审人员在拒绝一个 CL 并提供替代建议时要做得很有礼貌。礼貌是很重要的,因为作为开发人员,我们要彼此尊重,即使可能意见不一致。

    如果有很多 CL 是你不希望出现的,就要考虑重新调整开发团队或外部贡献者的开发流程,以便在开发新的 CL 之前进行更多的沟通。提前告诉人们哪些事情不要做,这比等他们做完了这些事情再把它们扔掉或者进行彻底重写要好得多。

    第二步:检查 CL 的主要部分

    找到 CL 的主要文件。通常一个 CL 会有一个包含了主要逻辑变更的文件,也就是 CL 的主要部分。先看看这些主要部分,有助于了解整个上下文,加快代码评审速度。如果 CL 太大,以致于你无法确定哪些部分是主要的,可以询问开发人员,或者让他们把 CL 拆分成多个 CL。

    如果 CL 的主要部分存在严重的设计问题,要立即回复开发人员,即使你还没有时间检查 CL 的其余部分。这个时候检查 CL 的其余部分可能是在浪费时间,因为如果主要部分存在严重的设计问题,那么其他部分就变得无关紧要了。

    为什么要立即回复开发人员?原因有二:

    • 开发人员在发出一个 CL 之后会继续开始后续的开发工作。如果你正在评审的 CL 存在严重的设计问题,他们也需要重写后续的 CL。所以,最好赶在开发人员在有问题的设计上花费不必要的时间之前告诉他们。

    • 大的设计变更比小的变更需要更长的时间。为了让开发人员能够在截止日期之前提交代码,同时又能保持代码库的质量,要尽早让他们开始重写工作。

    第三步:按照适当的顺序检查 CL 的其余部分

    在确认整体 CL 没有严重的设计问题之后,试着按照某种逻辑顺序来检查其他文件,确保不会错过任何一个需要检查的文件。通常,在你检查完主要文件之后,按照代码评审工具显示它们的顺序来浏览每个文件就可以了。你也可以在检查主要代码之前先查看测试代码,这样可以对代码变更有一个大致的概念。

    代码评审的速度

    为什么代码评审要快速进行?

    在谷歌,我们对开发团队的整体交付速度(而不是针对个体开发人员写代码的速度)进行了优化。个体开发速度也很重要,但其重要性比不上整个团队的开发速度。

    如果代码评审的速度很慢,就会发生以下这些事情:

    • 团队的整体开发速度降低了。如果个体开发人员无法快速地对评审做出响应,可能是因为他们有其他事情要做。但是,如果每个 CL 都要等待一次又一次的评审,那么其他成员的新特性和 bug 修复就会被延迟,可能是几天、几周甚至是几个月。

    • 开发人员开始对代码评审流程提出抗议。如果评审人员要隔几天才回复一次,但每次都要求对 CL 进行重大修改,开发人员可能会觉得很沮丧。通常,他们会抱怨评审人员太过严苛。如果评审人员能够快速提供反馈,抱怨就会消失,即使他们要求做出的修改是一样的。代码评审过程的大多数抱怨实际上可以通过加快评审速度来解决。

    • 代码质量受影响。如果评审速度很慢,开发人员的压力也会随之增加,因为他们不能提交不甚完美的 CL。缓慢的评审流程还会阻碍代码清理、重构和对现有 CL 做出进一步改进。

    代码评审应该要多快?

    如果你不是在集中精力完成手头的任务,那就应该在第一时间评审代码。

    对代码评审做出响应最好不要超过一个工作日。

    如果遵循这些原则,那么一个典型的 CL 在一天内(如果需要的话)可以进行多轮评审。

    速度和中断

    有一种情况,即如果你正在集中精力完成手头的任务,比如写代码,那就不要打断自己去做代码评审。研究表明,开发人员被中断之后可能需要很长时间才能恢复到之前的状态。因此,从团队整体上看,在写代码时打断自己比让另一个开发人员等待代码评审要付出更大的代价。

    所以,对于这种情况,可以等到你手头工作可以停了再开始代码评审。可以是在完成手头的编码任务之后,午饭后,会议结束后,休息结束后等。

    快速响应

    我们所说代码评审速度指的是响应时间,而不是 CL 完成整个评审过程并提交到代码库所需的时间。理想情况下,整个评审过程也应该是很快的,但单次评审请求的响应速度比整个过程的响应速度更重要。

    有时候可能需要很长时间才能完成整个评审过程,但在整个过程中评审人员的快速响应可以极大减轻开发人员对“慢”评审的沮丧感。

    如果你太忙了,可以先向开发人员发送一个响应,让他们知道你什么时候可以开始评审,或者建议让其他可以更快做出响应的评审人员来评审代码,或者提供一些初步反馈。

    最重要的是评审人员要花足够的时间进行评审,确保代码符合标准。但不管怎样,最好响应速度还是要快一些。

    跨时区代码评审

    在进行跨时区代码评审时,试着在开发人员还在办公室的时候做出响应。如果他们已经回家了,那么最好可以确保他们在第二天回到办公室时可以看到代码评审已经完成。

    带有注解的 LGTM

    为了加快代码评审速度,对于以下两种情况,评审人员应该给出 LGTM(Look Good to Me,没有问题)或者通过,即使他们在 CL 中留下了未解决的问题:

    • 评审人员确信开发人员将会处理好评审人员给出的建议和意见。
    • 其余的改动是次要的,不一定要求开发人员完成。

    当开发人员和评审人员处于不同的时区时,最好可以使用带有注解的 LGTM,否则开发人员可能需要等上一整天才能获得“LGTM,批准”。

    大型的 CL

    如果有人给你发了一个很大的代码评审,而你不确定是否有足够时间完成评审,通常的做法是要求开发人员把 CL 拆分成几个较小的 CL。这样做通常是合理的,对评审人员来说是有好处的,即使开发人员需要做点额外的工作。

    如果一个 CL 不能拆分成更小的 CL,并且你没有足够的时间进行快速评审,至少要对 CL 的总体设计写一些注解,并发给开发人员。评审人员的目标之一是在不影响代码质量的情况下快速对开发人员做出响应,或者让他们能够快速采取进一步行动。

    持续改进代码评审

    如果你遵循了这些指导原则,并且对代码评审过程严格要求,你会发现,随着时间的推移,整个代码评审过程会变得越来越快。开发人员知道为了保证代码质量需要做些什么,并从一开始就向你发送非常棒的 CL,这样评审所需的时间就会越来越少。评审人员也学会了如何快速做出响应。但不要为了提高评审速度而牺牲代码评审标准或质量——从长远来看,这样做并不会让任何事情变得更快。

    紧急情况

    在一些紧急情况下,CL 必须非常快速地通过整个评审过程,在质量方面会有些许的放松。请参看这些“紧急情况”,看看哪些符合紧急情况标准,哪些不符合。

    评审注解

    概要

    • 礼貌。
    • 解释你的理由。
    • 给出明确的方向,指出问题,并让开发人员决定如何在两者之间做出权衡。
    • 鼓励开发人员简化代码,或者添加代码注释,而不只是让他们解释代码的复杂性。

    礼貌

    一般来说,礼貌和尊重是很重要的。一个是要确保你的评论是针对代码而不是针对开发人员。你不一定要一直这么做,但当你想说一些可能会让开发人员感到激动或有争议的话时,绝对有必要这么做。例如:

    不好的说法:“为什么你要在这个地方使用线程,这样做显然不会获得任何好处”。

    好的说法:“在这里使用并发模型增加了系统复杂性,但我看不到任何实际的性能好处,所以这段代码最好使用单线程,而不是多线程”。

    解释理由

    从上面的正面示例可以看出,这样有助于开发人员理解你为什么要给出这些建议。你并不一定总是要在评审中提供这些信息,但如果你能够为你的意图、所遵循的最佳实践或你的建议将如何改进代码质量给出更多的解释会更好。

    给予指导

    一般来说,修复 CL 是开发人员的责任,而不是评审人员的责任。你不需要为开发人员提供详细的解决方案或者为他们写代码。

    不过,这并不意味着评审人员就不应该帮助开发人员。你最好可以在指出问题和给予指导之间做出权衡。指出问题,并让开发人员做出决策,这样有助于开发人员学到东西,并让代码评审变得更容易。这样还可以产出更好的解决方案,因为开发人员比评审人员更了解代码。

    不过,有时候直接给出指令、建议或代码会更有用。代码评审的主要目的是获得尽可能好的 CL。第二个目的是提高开发人员的技能,这样以后需要的评审就会越来越少。

    接受注解

    如果你要求开发人员解释一段你不理解的代码,他们通常会去重写代码,并把代码写得更清晰。有时候在代码中添加注解也是一种恰当的做法,只要它不只是用来解释太过复杂的代码。

    不要只是把注解写在代码评审工具里,因为这对于将来要阅读代码的人来说并没有多大帮助。只有少数情况可以接受这种做法,例如,你对评审的东西不太熟悉,而开发人员的解释却是很多人所熟知的。

    代码评审回推

    有时候,开发人员会回推代码评审。他们可能不同意你的意见,或者他们抱怨你太严格了。

    谁是对的?

    如果开发人员不同意你的意见,先花点时间想一下他们是不是对的。通常,他们比你更熟悉代码,所以可能对代码的某些方面更了解。他们的论点有道理吗?从代码质量角度来看,他们的回推是有道理的吗?如果是,就让他们知道他们是对的,这个问题就解决了。

    然而,开发人员并不总是正确的。在这种情况下,评审人员要进一步解释为什么他们的建议是正确的。

    如果评审人员认为他们的建议可以改善代码质量,并认为评审所带来的代码质量改进值得开发人员做出额外的工作,那么他们就应该坚持。改善代码质量往往是由一系列的小步骤组成的。

    有时候你需要花很多时间反复解释,但要始终保持礼貌,并让开发人员知道你知道他们在说什么。

    激动的开发人员

    有时候,评审人员会认为如果他们坚持要开发人员做出改动,会让开发人员感到不安。开发人员有时候确实会感到沮丧,但这种感觉通常都很短暂,之后他们会非常感谢你帮助他们提高了代码质量。如果你在评审过程中表现得很有礼貌,开发人员一点都不会感到不安,这种担心可能是多余的。通常,令开发人员感到不安的是你写注解的方式,而不是你对代码质量的坚持。

    稍后再解决

    一种常见的回推原因是开发人员希望尽快完成任务。他们不想经过一轮又一轮的代码评审,他们说他们会在后续的 CL 中解决遗留问题,你现在让 CL 通过就可以了。一些开发人员会做得很好,他们在提交 CL 后立即就开发后续的 CL。但经验表明,开发人员开发原始 CL 的时间越长,他们进行后续修复的可能性就越小。除非开发人员在提交 CL 之后立即进行修复,否则在通过之后通常不会再去做这件事情。这并不是因为开发人员不负责任,而是因为他们有很多工作要做,而修复工作通常会被遗忘。所以,最好让开发人员马上把 CL 修复掉。

    如果 CL 引入了新的复杂性,在提交之前必须将其清理掉,除非是紧急情况。如果 CL 暴露了一些目前还无法解决的问题,开发人员需要把 bug 记录下来,并将其分配给自己,这样它就不会被遗漏。他们还可以在代码中加入 TODO 注释,指向已经记录好的 bug。

    抱怨评审太严格

    如果你之前的代码评审很放松,然后突然变得严格起来,可能会引起一些开发人员的抱怨。不过没关系,加快代码评审速度通常会让这些抱怨逐渐消失。

    有时候,这些抱怨可能需要几个月的时间才能消除,但开发人员到最后通常会看到代码评审的价值,因为他们看到了严格的代码评审有助于产出优秀的代码。有时候,抗议最大声的人甚至会成为你最坚定的支持者。

    解决冲突

    如果你遵循了上述方法,但仍然会在评审过程中遇到无法解决的冲突,请再次参阅代码评审标准,了解那些有助于解决冲突的指导原则。

    原文链接: https://google.github.io/eng-practices/review/reviewer/

     

     
    展开全文
  • 如何Android上编写高效的Java代码

    万次阅读 2015-05-18 22:53:35
    转自:http://www.ituring.com.cn/article/177180Java平台一般有三个版本:Java ME(微型版,用于某些手机)、Java SE(标准版,用于...首先,Java代码会被编译成称为字节码的中间格式。当字节码目标电脑上运行时,虚
  • 基于MATLAB的拼图游戏设计 内容摘要:MATLAB强大的运算和图形展示功能,使图像...本博文基于MATLAB编程语言,详细介绍了如何利用MATLAB及其图像处理函数进行经典拼图游戏设计,并通过具体方法步骤及相应代码逐...
  • Web前端开发学习3:SEO代码优化

    千次阅读 2015-10-31 18:28:17
    识,因此网上看了一些关于这方面的知识,简单的整合一下,梳理自己所了解的代码优化问题。  所谓代码优化是指对程序代码进行等价(指不改变程序的运行结果)变换。程序代码可以是中间代码,也可以是 目标代码。...
  • 代码审计--20--Checkmarx CxSuite详细

    千次阅读 2018-10-06 12:17:06
    CxSuite是目前最强有力的下一代静态源代码安全扫描测试方案,专门设计为识别、跟踪和修复软件源代码上的技术和逻辑方面的安全缺陷。首创了以查询语言定位代码安全问题,其采用独特的词汇分析技术和CxQL专利查询技术...
  • 优化代码的重要性

    千次阅读 多人点赞 2015-04-19 17:55:25
    方面是缺乏编程方面的经验,写出的代码不能够考虑全面地情形;另一方面可能是需求设计的频繁性变动,导致代码的结构的不稳定性变动。这些都直接或间接地影响代码的质量,而代码质量的好坏将会直接影响到产品的性能...
  • 这篇文章将介绍基于机器学习的恶意代码检测技术,主要参考郑师兄的视频总结,包括机器学习概述与算法举例、基于机器学习方法的恶意代码检测、机器学习算法工业界的应用。同时,我再结合自己的经验进行扩充,详细...
  • 编写可读性代码的艺术

    千次阅读 2016-07-16 10:30:42
    原文地址: ... PDF文件下载地址: ... 译者序 做IT的公司里,尤其是软件开发部门,一般不会要求工程师衣着正式。我工作过的一些环境相对宽松的公司里,很多程序员的衣着连得
  • 2B 领域下低代码的探索之路

    万次阅读 2021-03-23 11:30:15
    今天的分享我们不讲技术细节,主要会分享下我们这五年的探索过程和当前的市场分析,希望能给大家带来一个对低代码搭建不一样视角的认识。 什么是低代码 说起低代码(Low-Code)这个词,是 2014 年,...
  • 代码错误分类

    千次阅读 2012-11-09 16:28:45
    代码错误可以分为方面:性能问题,功能错误。  性能问题又可以分为时间性能和空间性能。时间性能就是执行效率不符合预期。空间性能就是所占用的资源超出预期。由于单元测试面对的测试目标是比较小的代码单元,...
  • 读《驯服烂代码——编程操练中悟道》 第2章 按图索骥地编写代码 第4章 调试一下 第5章 用TDD重做编程操练题目 第6章 消除假数据所带来的重复代码 第8章 嗅出代码腐臭和新的测试点 第9章 测试后行 vs 测试先行 TDD...
  • 开源代码网站

    万次阅读 2018-01-17 09:29:04
    (1)到sourceforge上查找相关代码; (2)到google code上面查找具体的代码; (3)到apache网站上寻找java的相关代码; (4)直接到开源项目网站上面寻找代码; (5)到csdn等网站下载代码,偶尔会有...
  • 关于烂代码的那些事

    千次阅读 2016-03-14 12:10:32
     最近写了不少代码,review了不少代码,也做了不少重构,总之是对着烂代码工作了几周。为了抒发一下这几周里好几次到达崩溃边缘的情绪,我决定写一篇文章谈一谈烂代码的那些事。这里是上篇,谈一谈烂代码产生的原因...
  • 如何编写优雅的代码

    千次阅读 2019-01-11 11:02:58
    讨论关于如何编写优雅代码的观点之前,先抛出个问题,希望我们对这一点能够达成共识: 为什么要编写优雅的代码? 有的人说,代码写得好不好无关紧要,能完成功能,并且不出什么bug就好了。 有的人说,项目进度...
  • snippet,也即代码片,指的是能够帮助输入重复代码模式,比如循环或条件语句,的模板。本文即旨于详实地介绍如何 vscode 中设置 snippet。
  • 什么样的代码才算得上是好代码

    千次阅读 2017-03-14 20:26:42
    什么样的代码才是好代码?衡量代码的好坏的指标或者维度有很多,比如性能好、架构好、高内聚等,这些指标的侧重点各不相同,不同的开发人员的关注的重点也...可工作的包含有层含义:一是从功能角度来说能满足用户的需
  • 代码分析方法

    千次阅读 2009-11-12 22:08:00
     最近半年多时间一直做新产品的预研和代码分析方面的工作。整个过程是及其富有挑战性和探索性的,回顾这半年多时间的工作和学习,对代码分析方法有一些总结和心得,隧记录下来以备遗忘。这篇文档并非最终文档,...
  • 程序员的迷茫不仅仅是面对技术繁杂的无力感,更重要的是因为长期埋没于软件 世界的浩大的分工体系中,无法看清从业务到软件架构的价值链条,无法清楚定位自 己分工体系的位置,处理不好自身与技术、业务的关系所致...
  • 笔者前言:最近发现这个被发明于1982年的方法如今得到了极为广泛的应用,提倡深度学习的时候,基于...主要功能是将输入的 n 维空间数据映射到一个较低的维度 (通常是一维或者二维 )输出 ,同时保持数据原有的拓扑逻
  • NetBeans vs eclipse 的主要方面的介绍

    千次阅读 2006-05-23 18:34:00
    NetBeans Eclipse 主要赞助商 Sun Microsystems IBM Corporation 版本号 NetBeans IDE 3.6 Eclipse Platform 3.0.1主要功能插件:Eclipse Java 开发工具(JDT) 3.0.1Graphical Editing Framework ...
  • Python Django实现简单购物车功能

    万次阅读 2017-06-26 14:30:40
    这是一个商品的详情,这里有2个按钮功能,一个是立即购买,一个加入购物车,两者都是生成一个订单,但两者实现的方法是不相同的。我按照这个设计,实现简单功能。 这里生成2个App,一个ProductInfo,用于商品详情...
  • 写好代码的一些基本原理

    千次阅读 2012-03-09 00:20:08
    v 影响局部化原理F 代码需要通过精心的组织和设计,这样修改某处代码的时候只会影响局部的范围F 当修改一处代码会导致不得不修改多个文件多处地方的代码时,修改的代价就会急剧上升F 当代码中的元素具有局部影响...
  • 代码优化--避免全局变量

    千次阅读 2013-12-15 21:50:45
    当全局变量过多,就会导致内存占用过大,代码维护测试就更难,所以,代码优化--要尽量避免全局变量的出现。 本篇文章内容主要参考:“编写可维护的JavaScript”和“JavaScript高级程序设计...主要表现在: 1,命名冲突
  • 代码的写法

    千次阅读 2016-04-09 17:42:34
    代码(Pseudocode)是一种算法描述语言。使用伪代码的目的是为了使被描述的算法可以容易地以任何一种编程语言(Pascal,C,Java,etc)实现。因此,伪代码必须结构清晰、代码简单、可读性好,并且类似自然语言。 ...
  • 为什么保持代码整洁如此重要?

    万次阅读 多人点赞 2021-02-05 10:47:21
    对于代码整洁,没有唯一的或者严格的定义,而且可能无法正式地衡量怎样才算代码整洁,因此你不能在代码仓库上运行一个可以告诉你代码是好是坏、可维护性如何的工具。当然,你可以运行检查器、代码校验器、静态分析器...
  • 代码review总结

    万次阅读 2017-11-28 09:26:41
    Code Review应该是软件工程最最有价值的一个活动,之前,本站发表过《简单实用的Code Review工具》,那些工具主要是用来帮助更有效地进行这个活动,这里的这篇文章,我们主要想和大家分享一下Code Review代码审查的...
  • 前端代码规范手册

    千次阅读 2018-08-15 15:43:15
    前端代码规范手册       Web Coding Guidelines     前言 本手册的愿景是码出高效,码出质量。现代软件架构都需要协同开发完成,高效 协作即降低协同成本,提升沟通效率,所谓无规矩不成方圆,无规范不...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 199,847
精华内容 79,938
关键字:

代码的功能主要表现在两方面