被神化的架构和被夸大的CTRL+C、CTRL+V

为什么我想谈谈架构，和代码的复制粘贴这两个话题呢，主要是前几天看到一篇文章提到这两个话题，在这里想谈谈我的一些看法。

很多新人，都很谈架构，好象贴了架构这个标签就显示高档似的，把设计模式当作圣经，实在可笑。做架构，不是捧着书，然后闭门苦思就能想出来的。

架构是做出来的，不是设计出来的

架构，说穿了就是解耦，把变化的东西抽离出来，这个是它的本质。一般来说，越接近底层的东西越是稳定，越接近业务层的东西越容易变化。如果想在业务层上作封装，也就是说想作架构设计，必须充分了解业务，没有足够的编码经验是不可能做好的。所以我经常说，架构不是设计出来的，而是做出来的，只要你做完了，整个业务都确定了下来了，了解充分了，你才可能设计出合理的架构。因为，架构是依赖于需求的，都需求没有确定下来的情况下做架构，需求一变，那些所谓的架构不是要改得一踏糊涂，最后连自己都看不下去了，再推倒重来。事实上，应该是在项目的后期，完工了，业务流程也确定了，这个时候才有架构可谈。

架构设计，还要考虑成本，很多新手，往往会忽视这个问题，也就是说，你必须考虑做这个架构要花多少时间，能节省多少时间。如果花费远大于收益，那就没有意义了。但是他们往往会解释，现在多花点时间，后期就能少花很多时间了。但是事实往往是，前期多花时间，后期也多花时间，老是想让这个架构变得更完美而沉迷其中，不能自拔。我们往往过度沉迷于架构，而忘了做项目的目的。做项目的，是为了解决客户业务上的问题，能够提高他们的业务水平，这才是本质。

架构，其实没啥的，你的代码看得多了，写得多了，自然就会有架构了，记住封装变化这个核心就行了。其实阅读代码、分析代码、编写代码都是真正的基本功，正所谓“练拳不练功，到老一场空”，写程序也是，作为新人，应该多花时间去阅读代码，编写代码上面，把自己的基本功练扎实才是最为重要的。

代码的复制、粘贴不是洪水猛兽

很多人都习惯性地鄙视CTRL+C，CTRL+V，好象一旦和它们沾边，就是烂代码，其实大可不必。我们考虑一下，为什么不能CTRL+C，CTRL+V 呢？因为这些代码不好维护，打个比方说，有两处相同的代码，那么有可能就要改两处。但是，你们有没有碰到这么一种情况呢，我们先来假设一下，有三个地方，A、B，C，都调用到一个函数，这个函数称为 M 吧。

但是，不久之后，接到一个需求上的变化，A 的业务改变了，需要修改 M 的函数，但B，C 的没有变，那么我们习惯性的在函数 M 里加个 if 来判断，如果是 A 的业务，就如何如何。

不久之后，又收到需求变化，B 的业务改变了，那么习惯性的，又会在 M 函数里加一个 if 逻辑块。

不久之后，又收到需求变化，C 的业务改变了，那么习惯性的，又会在 M 函数里加一个 if 逻辑块。

请问，这样 M 函数充满这么多的 if ，还容易维护吗？还不如写成三个函数呢。

所以，我们大可不必视复制粘贴为洪水猛兽，只要在可控的范围内就行了，当然，如果业务确定下来是不会变化的，还是一个。什么是可控呢？我觉得复制只有两、三个地方，都问题不大。总之，存在这是合理，很多时候，我们总习惯于高估自己，而低估别人。

 

最后，还是那句话，我现在失业中，想寻找一份从事研发方面工作，最好和数据库、编译技术打交道的，想找技术牛人的可以联系。 希望各位乡亲父老多多关照，谢谢大家。^_^