科技壹零扒|再读《重构》( 二 )
对于如何让我们代码越来越健康 ， 而不是逐渐腐化 ， 我常常在团队里面给大家这样分享：我们每个人都应当在提交代码时停下来想一下 ， 我们这次提交是让代码更健康了 ， 还是更腐化了 ， 还是没变化？只有我们每次提交代码都至少没有让代码更腐化 ， 代码才能越来越健康 。 一些腐化的例子比如我们引入了一个坏味道 ， 我们测试覆盖率降低了等等 。 而一个健康的例子就是我们在增加功能的时候 ， 顺便重构了原来的代码 ， 让其可读性更高 ， 可复用性更好等等 。
在老马谈论捡垃圾式重构法时提到了营地法则–我们应该至少在离开营地时 ， 让营地比我们到来时更干净 。 如果每次经过一段代码 ， 都让其变得更干净 ， 积少成多 ， 垃圾总是会被处理掉 。
仔细一想 ， 这样的观点竟然出奇的一致 。 与大家共勉 。
使用PR进行代码复审还是专门组织代码复审活动？
在谈论到如何在代码复审进行重构时 ， 老马提到我们可以在阅读他人代码之后 ， 如果有一些点子 ， 就可以直接进行重构 ， 从而获得比想象出来的更直观的认识 。 这样的代码复审活动最好能有代码作者一起pair ， 不仅可以有机会充分理解原来的代码 ， 还能一起分享重构的意图 。
文章图片
现在有些团队热衷于使用PullRequest的方式进行代码复审 ， 并在代码后面留下大篇大篇的评论 ， 以便让代码作者去修复问题 。 这样的风潮大概是兴起于GitHub的流行 ， 多分支管理策略如GitFlow和GitHubFlow中建议以PullRequest的方式进行代码复审和合并 。 看起来由于多了一道关卡 ， 我们合入主干的代码质量能有所提高 。 但是这样的分支管理策略是不够敏捷的 ， 它之所以适合在GitHub上推行 ， 是由于GitHub上面的项目多是由分布式的团队完成 。 有一大群水平参差不齐的 ， 对代码理解也差异巨大的开发者可能要一起修改代码 ， 并且大家还要跨地域跨时区进行协作 。 要支持这样的团队开发 ， 多分支策略有其优势 。 但是对于我们日常的敏捷团队而言 ， 大家每天坐一起 ， 专注在同一个项目上 ， 这样的多分支策略就显得过于重量级了 ， 发挥不出团队可以随时沟通交流的优势 。
那么对于敏捷团队而言 ， 更好的代码复审方式是怎么样的呢？我们可以尝试少数人pair的方式进行复审 ， 我个人更推荐回归到每天的团队代码复审活动中来 。
重构与单分支管理策略
与上面代码复审类似 ， 敏捷团队中更推荐的是单分支管理策略 ， 因为这样的分支策略可以让我们更快的集成 ， 从而更好的支持重构 。 试想 ， 如果不是单分支 ， 当我们在代码库里面进行重构之后 ， 又必须得经过一个复杂而耗时的流程才能合入主干 ， 这个时候合并代码会有多痛苦 。 我们很可能发现在一个两天前的提交中使用的一个接口 ， 已经被另一个人通过重构改名了 。 有人说我们可以通过频繁拉取主干的代码来缓解这个问题 ， 但是合并是双向的过程 ， 当修改太多的时候 ， 每次的合并操作也会让人累的够呛 ， 而且我可能长时间看不到别人的修改 ， 潜在的合并代码风险无形中变大了 。 总之 ， 特性分支游离的时间越长 ， 合并越痛苦 。 基于单分支的策略 ， 只要代码能通过测试 ， 我们就可以随时将本地可用的代码推送到分支上 ， 随时集成 。 这对于重构带来的压力将会小很多很多（将减少很多没必要的合并操作和破坏代码的机会） 。
单分支管理策略不是说完全不使用分支 ， 我们还是可以适当使用分支完成一些探索性的工作 ， 或者完成产品发布工作 。 在这里 ， 快速的合并代码和快速的集成是最重要的 。
所以 ， 对于一些热衷于GitFlow或者GitHubFlow的团队 ， 我们可能尤其需要注意这个问题 。
重构与测试
测试是重构的保护伞 ， 我们需要有一组可靠的测试才能放手进行重构 。 测试的重要性不言而喻 ， 这里我想提及的一点是我们应该何时停止写测试 。
推荐阅读
- 三星公司发布2021款数字座舱 集成诸多高科技
- 刚有望“出人头地”就被三大科技巨头围剿，“挺川者”新阵地下线
- 谷歌建立新AI系统 可开发甜品配方
- 柔性电子市场广阔，领头羊柔宇科技获更多关注
- 曝LG也将推出卷轴屏手机 你怎么看？
- AI战疫、真5G来了，十大最热门科技应用演绎速度与温度
- 又爆炸！联电科技传来一声巨响，或把8 英寸晶圆市场"炸"了
- 唐山四维智能科技有限公司：双臂机器人引领人机协作新纪元
- 国家超算郑州中心首批重大科技专项启动
- 青岛海科展：五年磨一剑，科技力量助力海洋强国