读代码前先跑5个「Git命令」？方法火了，网友却吵起来了

机器之心编辑部向大家提出一个问题, 那就是, 当你碰到一个陌生的代码库之际, 第一步所做的事情是什么呢?多数人的做法是开启之后, 自目录起始, 逐行依次向下阅读。然而当下, 部分工程师采用一种截然不同的方式: 于查看代码以前, 先查看Git。近期, 有一篇称作「在阅读任何代码之前, 我会运行的 Git 命令」的文章, 引起网友热烈讨论, 文章里提出一个看上去简单, 实际却极具颠覆性的观点, 即代码仅是结果, Git 才是过程。如何理解作者Ally觉得, 针对一个全新的代码库而言, 先打开终端, 接着运行一组Git命令, 在还未查看任何文件以前, 其中的「提交历史」能够给出一幅与这个项目相关的「诊断图」, 具体内容包括: 是谁构建了它, 问题集中于哪些地方, 团队是充满自信地进行交付, 还是在雷区边缘小心翼翼地探索……所以, Ally 给出建议, 在阅读代码以前, 可以先去运行这五个 Git 命令:一、哪些地方改动最多利用这一Git命令, 能够查看到在过去一年里被改动数量最多的20个文件那处于最前列位置的那个文件, 基本上常常是别人会事先进行提醒的那一个: 「哦对, 便是那个文件, 没有人胆敢去动它。」。自然, 高频次的改变并不必然就表明代码质量欠佳有时仅仅是开发活动较为活跃而已, 然而要是一个文件被频繁改动, 并且与此同时又没有任何人愿意接手处理, 那么这极有可能就是最为确切的「代码困扰」信号。此处的每一番修改, 通常都是「于旧有的修补之处再度施加修补」。一次微小改动所产生的影响范围难以进行预估。团队在开展估算工作时会特意予以加计, 因为他们清楚这块代码「会产生抵触」。2005年, 微软研究院有一项研究, 此项研究发现, 基于“变更频率”也就是churn的指标, 相比单纯的复杂度指标, 更能够预测缺陷。通常情况下, 存在一个文件, 这个文件同时具备“高churn 高bug”的情况, 而这样的文件就是最大的风险点。二、谁在写这些代码按照提交数量进行排序, 查看所有的那些贡献者, 要是有一个人所贡献的达到了百分之六十以上, 那么这有可能就是处于名为「关键人依赖」bus的情况了, 然而要是这个人早在六个月之前就已经离开了, 那这便成为了危机。此外在末尾部分, 比如说存在着 30 个贡献者这种情况, 然而过去的一整年当中仅有 3 个是处于活跃状态的。这所表明的是, 去构建这个系统的那些人, 并非是当下正在对它实施维护操作的人。需留意的是, 若是团队运用merge压缩合并, 作者信息会被压缩, 在此情形下, 结果所反映的是「谁合并了代码」, 而非「谁写了代码」所以在下结论以前, 最好预先知晓团队的合并策略。三、Bug 都集中在哪这个命令的结构, 于 churn 分析而言是类似的, 不过呢, 它仅仅筛选那些包含 Bug 关键词的提交。把这个列表拿去和前面的 churn 热点作对比, 在这两个列表里都出现的文件, 那便是最高风险代码了: 它们持续地出现问题, 持续地被修补, 然而却从来都没有被根本性地解决。然而与此同时, 这还取决于所提交信息的规范状况, 要是团队每一回都书写「stuff」, 那么基本上难以获取到有效的信息。可是即便只是粗略的 Bug 分布图, 那也比全然没有要好。四、项目是在加速还是在停滞此命令能够查看整个仓库历史里每一个月的提交数量, 要是节奏保持稳定, 那就表明项目是健康的, 要是某个月提交量忽然减半, 往往意味着有人已离开, 如果6至12个月显示为下降趋势那就说明了团队正在丧失动能是, 如果呈现周期性高峰外加低谷, 那就表明团队是搞的「集中发版」, 而非持续交付。五、团队有多频繁在「救火」此命令用于查看「回滚」以及「热修复」的频率。在一年时间里, 偶尔有几次这种情况属于正常范畴, 然而要是每隔几周就出现一次「回滚」现象, 那就表明团队对自身的发布流程缺乏信任, 而这往往预示着存在更深层次的一些问题, 比如存在测试不够可靠的状况, 或者不存在缺乏预发布环境的情况, 或是存在导致部署流程致使「回滚」变得困难的情况。如若结果呈现为零, 亦然算作一种信号, 也就是要么系统极其稳定, 要么团队压根就不撰写清晰明了的提交信息。危机模式是很容易识别的要么存在要么不存在。在文章末尾之处, 作者宣称, 这五个Git命令所需时间仅为几分钟, 然而却能够让你明晰, 应当优先去阅读哪些代码, 并且知晓阅读期间需重点留意些什么, 以此能够使你从一开始便具备策略性地去理解代码库, 并非是毫无头绪地在其中四处探寻。事实上, 依据作者所进行的分享而言, 这几个Git命令, 对传统针对代码库的理解途径作出了变更, 给出了一种全新的视角, 所察觉到的并非仅仅是「当前代码的呈现模样」, 而是「当前代码达成这般状态的缘由」。与此同一时间, 这般新颖的那种视角于News当中并未被全然接受, 众人热烈讨论着: 这, 真的是可靠的吗?有网友认为Git 数据并不总是可靠 也会很水。他宣称, “要是团队具备规范的提交信息, 这些办法方才具备效用。”然而实际上, 不管是大型公司还是中小型企业, 提交记录常常处于混乱状态, 全都是清一色的「」、随意进行merge、情况莫名, 并且存在一些人, 明明团队已经约定使用, 可依旧会提交merge。所以, 他持有这样的看法, 即, “这一组办法主要仅仅是在中型以及大型的开源项目里头才切实具备用处 —— 就是那些有着清晰的.md/.md, 还有明确晓得的提交规范以及合并流程的项目。”。有网友觉得, 这般方式是于过度解析Git数据, Git剖析并不常常等同于实情, 极易误导判断。经他依据自身所经历之事进行剖析, 有时那些开发者提交次数较多, 或许仅仅是由于他们自身能力欠佳。当然, 他亦表明, 这并非意味提交次数多便等同于开发者欠佳。不过只是想要提醒众人, 倘若将这些Git命令的结果视为事情本身, 那就有可能无法窥见全貌。要是有这么一个人, 在跑完那些命令后, 跑过来跟我讲, 说发现某某是提交最为频繁、量数最多的人, 然而这个人在X个月之前就已经离职不干了, 还问我们到底该采取怎样的办法去应对这种状况, 我呀, 或许得使出浑身解数、拼尽全力, 才能够强忍着不发出笑声来……此外还有一个争议点在于高 churn 是否等于高风险网友觉得, 于测试期间接触数目最多的那些文件, 通常就是最没什么重要性可言的文件, 举例来讲, 像依赖文件.json、锁文件、持续集成配置, 还有一些自动生成出来的文件等等, 这些文件会频繁地产生变动, 然而这并不意味着它们具备复杂性的特质。因此更准确的做法是将 churn 结合复杂度来看。那么你, 你对于代码库是怎样进行看待的? 或者说是觉得如此这般的方式是不是存在着启发, 欢迎各位在评论区留下话语、得以交流参考链接