中科白癜风医院怎么样 https://baike.baidu.com/item/北京中科白癜风医院/9728824黄俊亮（Jay），优维科技资深DevOps前端开发专家，OpenSSL、node.js等开源项目贡献者，前端外刊特约评论/撰稿人。全量格式化还是渐进格式化？对于一个历史悠久又没有执行强制代码规范的代码库，全量格式化看起来是一件风险不可控的事情：它产生了大量的难以评估的格式改动，也使得格式化以后的代码库运行gitblame几乎都会定位到进行格式化的人（而非是这段逻辑的上一次有意义的修改者）。相比之下，理想的做法似乎应该是渐进格式化：对于新代码，使用强制的代码规范；对于老代码，除非它被修改，不然不进行强制代码规范。真的是这样子吗？全量格式化风险并不随代码量变大而显著变大。全量格式化往往会产生改变巨大的提交，代码改变得越多，看起来引入问题的风险就会越大。然而，对于代码格式器而言，代码格式器需要处理的是语言规范里面定义的有限几种语法结构的组合，绝大部分的业务逻辑代码都不会有像编译器的测试用例一般复杂的语法结构，对于代码格式器而言，只要代码库中的语法结构都被测试覆盖，改一百行代码和改十万行代码并没有本质区别。换言之，如果代码格式器出错，那么导致的代码错误一定很容易被查出来（因为同样的语法结构在系统各个角落都会用到）。只要十万行代码用到的语法结构组合不是一百行代码的语法结构组合的一千倍，那么全量格式化十万行代码引入的问题就不会是只格式化一百行代码的一百倍，因此全量格式化代码引入的风险关于代码量完全不成线性关系。一致的代码风格降低开发成本。全量格式化立刻使得代码库形成一致的代码风格，项目的每一个开发者都会备受鼓舞，一致的风格让开发者的阅读流不必被异常的代码格式阻断，对代码块的视觉识别也更加迅速（你的大脑很快习得了function后面一个空格的位置一定是一组参数，你不必为多一个或者少一个空格而额外消耗认知能力），配合上代码提交阶段的自动格式化，开发者甚至可以在开发过程中完全不需理会代码格式——反正最后提交时都会被计算机誊抄一遍进入到代码库中。增量格式化容易扩大化合并时的代码冲突。可是渐进代码格式化给我更多的安全感？在GitFlow的分支管理模式中，假设一个未被格式化的文件分别在特性分支和补丁分支有了改动，那么改动将会触发该文件的格式化，我们会在后面指出——当两个分支的同一个文件分别进行化后，合并时的冲突块大小将会被格式化放大（因为git并不理解哪些改动是格式化，哪些改动是修改业务逻辑），很快你将会淹没在无处不在的合并冲突之中，更糟糕的是，因为git不理解格式化和业务逻辑修改的区别，你需要仔细核对才能知道哪些改动压根没有修改业务逻辑，这无疑增大了合并的时候错漏的风险。那么，不如毕其功于一役吧。如何全量格式化GitFlow分支模型代码库？下图一个典型的采用GitFlow分支模型的代码库历史图：历史图在GitFlow模型中，考察分支的生命周期，假设所有分支都是根据需求合理存在的，可以发现：所有的release分支都是历史分支，它们不会再汇入到master分支所有的hotfix分支都将汇入master分支，hotfix分支生命周期很短每一次发小版本的时候，master分支作为hotfix的汇入者，也会汇入到develop分支每一次发大版本的时候，develop分支会汇入到master分支，并从新的master分支拉出release分支所有的feature分支都将汇入develop分支根据这个生命周期，我们可以按照以下策略对代码库进行格式化，下面我们简称这个策略为两步格式化：一，准备代码格式化配置。对所有活跃分支准备好代码格式器的配置，我们不推荐全局安装代码格式器，而是把代码格式器作为项目的开发依赖，这样历史版本可以用老版本的代码格式器，新代码可以用到新的代码格式器。你可以从开发分支拉出一个分支增加格式器配置，再遴选到各个活跃分支。只添加格式化配置对代码业务不会产生影响。二，挑选一个合适的时间点进行批量的格式化处理。我们建议是在刚发完小版本之后，此时master刚刚汇入develop分支。然后再将develop分支都汇入到开发中的feature分支。此时历史如图所示。批量格式化这个时候，这些分支的领先程度满足下面的关系：领先程度关系这里的是严格领先，也就是feature分支包含了develop分支的所有改动，develop分支包含了master分支的所有改动。三，单独对历史分支格式化。对所有的还在维护的release分支，进行全量格式化，通过测试后提交，在下面的历史图中，我们简单记release/1.0.0的全量格式化
转载请注明：http://www.aierlanlan.com/cyrz/7739.html
