编程的97件事——7、小心处理相似代码

小心处理相似代码

这是我在公司的第一个项目。我刚刚完成学业，急于证明自己，每天都处理公司现有的代码到很晚。在处理第一个功能的工作中，我尽可能地将所有我学过的东西都包含进去——注释、日志，并将重复代码提取出来，封装到类库中去。我本以为准备就绪的代码评审却给了我当头一棒——他们不赞成我重用代码！

这怎么可能？在学校期间代码重用被视作高质量软件工程的象征。所有我读过的文章、笔记里，经验丰富的软件专家都是这么教导我的。哪里出了问题？

是我忽视了一些重要的信息。

上下文。

事实上系统里两个无关的部分使用相同的方式处理一些逻辑，并不像我以为的那样意味着什么。直到将这些代码提取出来封闭到类中，我才发现它们之间并无关联。它们都独立运行。当系统的业务环境发生变化时，要修改代码的逻辑以适应新的需求。那四行相似代码只是个意外——暂时的巧合而已。就是这样，直到我的出现。

我提炼的类把它们绑到了一起，就像把两只脚上的鞋带绑到了一起。不先同步其他业务领域，这个业务领域的步骤就无法完成。维护这些独立功能的代价在过去是可以忽略不计的，但公共类就需要一系列的测试了。

我在减少了系统代码行数的同时，却增加了模块间的依赖。这些依赖的上下文至关重要——如果依赖是局部的，它们可能有一些已被证明的积极意义。当依赖脱离控制，就会引起我们对系统的担心，即使代码本身看上去很不错。

这些错误的隐蔽之处在于，从错误的本质上来看，它们像是不错的主意。当应用在正确的上下文环境中时，这些技术都是有价值的。在错误的上下文环境中，它们增加了成本而不是价值。现在再遇到历史代码，在不了解模块的使用上下文场景时，我对待重用代码的态度要谨慎得多。

小心处理相似代码。检查你的上下文。确认无误，再继续前进。

Udi Dahan

---

 Beware the Share

It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned — commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt so ready for came as a rude awakening — reuse was frowned upon!

How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong?

It turns out that I was missing something critical.

Context.

The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those four lines of similar code were accidental — a temporal anomaly, a coincidence. That is, until I came along.

The libraries of shared code I created tied the shoelaces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing.

While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.

These mistakes are insidious in that, at their core, they sound like a good idea. When applied in the right context, these techniques are valuable. In the wrong context, they increase cost rather than value. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.

Beware the share. Check your context. Only then, proceed.

By Udi Dahan

转载于:https://www.cnblogs.com/micro-potato/p/6918163.html