小心分享

那是我到公司的第一个项目。我刚毕业一心想要证明自己,每天都调代码到很晚。当我每get到一个新特性时,都很认真地把学到的东西——尽可能注释、日志、推送到代码共享库中,就这样工作着。但对我认为很OK的代码审查却让我醍醐灌顶——重用得不好。

为什么会这样?整个大学的复用被认为是高质量软件工程的缩影。我读了所有的条款,书籍,接受过非常有经验的软件专家的教育。这些全是错的?

事实证明我确实错过了一些关键事情。

上下文

系统中两处有复用接口的地方实际执行相同逻辑情况比我想象中少。就算我把代码从库里再拉取一遍,这些部分也没有其他依赖。彼此独立推进,独立修改逻辑以适应系统业务需求的改变。有四行相似的代码出问题了——时间异常、耦合。直到我继续深究。

我创建的这个代码共享库就像把鞋带相互绑在每只脚上。创建一个业务领域之前必须先与另一个进行同步。这样独立的功能维护成本可以忽略不计,但公共库则需要巨量的测试。

当我想要减少一定数量的代码行数时,我却要增加同等数量的依赖。这些依赖对上下文必须非常严谨——确保被分配过,有正确合理的赋值。当这些依赖得不到检查时,即便代码看上去没问题,整个系统也会被它们绕死。

这些错误就潜伏在那,当然从核心来看貌似是不错的想法。当调用它们的上下文正确时,这些技术会很有价值。但当上下文本身不好时,它们给系统带来的负担已经超过其价值。当入库的代码存在大量不懂技术的复用时,我都会在最近几天非常留意这次分享。

小心分享。检查你的上下文。确保OK,再继续。

0%