【IT168 评论】“懒人创造了世界”是时下很流行的一种说法，懒人因为懒，所以他们会在方式方法上找捷径，想出各种巧妙的方法来解决问题。这一说法在程序员中也得到了印证，在解决实际问题时，老实的程序员会自己编写手工编写代码，懒的程序员会复制已有的代码，而又懒又聪明的程序员连复制都懒得做，他把这些代码写成一个组件下次直接使用。

　　框架的应用限制了代码重用?

　　框架出现的目的很明确，就是因为程序员需要重用一段代码，所以把它提取出来。但是当需求出现变化时，当前的框架不再满足需求，而程序员不想重复劳动，所以就会选择修改框架代码。但需求一再变化，程序员不得不再次修改代码，直至这个框架变得无比得大。

　　这时，当项目中有一个新功能出现，程序员一看框架，“哇呀，我就用一个小功能，这个框架这么大呀!”于是，程序员就开始自己动手再写一个框架，长此以往，框架的数量也不断增长。

　　虽然框架最初的目标是为了追求便捷，但是数量和体量的不断增加反而对于程序员代码重用造成了困扰。

　　代码重用有好处，但有可能代价更高

　　世界上任何事情都是有代价的，代码重用也不例外，在解决了灵活性的问题时，也会在性能和代码可读性方面自然会有所牺牲。所以归根结底，对于问题的解决方法总是权衡每个选择的利弊，然后从中选出经典方案。

　　所以，如果是从这个角度出发，那么代码重用的最大阻力可能就是项目本身。代码重用的目的往往只是整个项目的一小部分，而不是项目的最终目标。所以一旦项目的完成周期和复用发生冲突时，负责程序员往往会选择牺牲掉代码可用。

　　重用代码底层好写，上层难

　　“长恨人心不如水，等闲平地起波澜。”对于代码而言，越是底层越容易规范，越是上层代码，复杂度越高。为什么呢?因为底层代码抽象的是机器，服务的是程序员，具体需求比较单一固定，例如，数据读写、数据操作等等。而上层代码抽象的是需求，服务的是用户，用户的需求千差万别，一段可能想要数十种需求的重用代码可能连用户的一个需求都解决不好。

　　所以，底层代码可以自顶向下的进行设计，而上层代码则要以解决用户需求为重，然后才能考虑在类似的问题出现的多的时候使用代码重用。

　　过早优化是“万恶之源”

　　每个程序员在最初的时候都有一个“完美代码的梦想”，要考虑周全，为可能会出现的需求而编写“预备代码”。但是在经历了多个项目之后，往往会发现90%的预想需求是不会出现的，即使是出现的预想需求也和之前大相径庭。

　　所以一开始追求复用性并没有多大的意义，相反在设计的时候考虑复用性反而是更合适的阶段：

　　不做设计(新手阶段，能实现就好)

　　2. 过度设计(了解的东西多了，总想追求完美)

　　3. 简化设计(认知逐渐深入，学会取舍)

　　4. 最优设计(熟练掌握，知道概念适配场景)