程序员需要知道的97件事情之 ------- 不要盲目的"reuse"

   本人英语抄过4级，奇烂无比，翻译这个实属蛋疼，错误是肯定有的，而且是翻不出出来就是随便猜，欢迎指出，谢谢啦。但愿我能够翻完我看的懂的....
    原链接：oreilly的程序员需要知道的97件事http://programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book

   这是一个经常出现的场景： 这是我在公司的第一个项目，我不仅仅满足于完成任务，我想去证明自己，每天都待到很晚去通读现有的代码，当我完成了我第一个功能的时候，我额外去留意我学习过所有事情，包括注释，日志等。并且尽量抽出公有的代码到共享库里去。在code reiw的时候，让我震惊的是居然遭到了前辈们粗鲁的抛弃 ----
软件工程中奉上神龛的 “重用” 居然被阻止了！！

    为什么会发生这样的事情？尽管所有的大学里面重用都是支撑软件工程的核心理念之一，我们的读的文章，前辈们的教导，等等，难道都是错的吗？

   其实这正告诉了我们，我们忽略了一些决定性的东西。

    比如所处的具体环境 （老土的是具体问题具体分析）。

   事实是这样的： 2个完全迥异的模块恰巧有些相同的逻辑，而不是我想象的需要“公有”方法。直到我把相似的逻辑抽出到公有库之前，他们本来是完全独立，彼此不干涉。现在使得他们无法独立，每次需求导致逻辑变更的时候，都需要去考虑对方。那些重用的代码看起来是那么的格格不入。当然。这都是我“重用”“逻辑相似”代码的后果。
那些共享库的“公用代码”束缚住了对方导致设计这部分的需求变更时需要考虑的时候很多，这样也增加了维护成本。以前对于两段独立而相似的逻辑代码，维护起来都只要管好自己就成，但是现在可能导致数量级的维护成本上升。

   看起来我减少了整体代码的行数，但是我却增加彼此之间的耦合度。代码所依赖的业务上下文是华丽的分割线---------它们相同逻辑被局部化而没有公有化的原因，可能是他们已经被证明这样更好，或者是他们有些相对的值需要当前上下文决定，等等之类。
当他们的依赖上下文或者约束没有被认真检查，即使reuse让代码看起来很不错，也可以让完全不相关的模块产生千丝万缕的关系!!!

   由于这些错误是很隐蔽的，因为他们本身看起来是一个好主意。当然，在一个正确的业务场景下，这些技术很有价值，在错误的条件下，它们带来的价值比开销要大的多。
所以： 当在对业务环境毫无所知的情况准备去抽出部分看似被几个模块公用的代码的时候，我更加关注什么东西是真正共享的！！

   记住：一定要确定，什么才是真正公用的！

    谨慎的做这些动作，检查你的业务场景，只有完全肯定的情况，再去处理它（reuse）！