大家好，今天跟大家分享一个自己在开发中遇到的问题，以及最终的解决方式。

做个简单的介绍，我是做Unity游戏客户端开发的，目前还是个苦逼学生。大三。

当然也是从c++入行，搞过一段时间Win32下的游戏编程。

那么开始吧。

首先我就从我熟悉的领域来做一个假设。

假设，先在某种类型的游戏很火，我们也要开发一个类似的游戏去迎合市场。现在策划和美术都准备周全，我们接到资源和要求开始项目。
大家第一想到的肯定就是看看这类游戏有什么共性和它的一些功能点，然后就是计划如何把这个功能实现。接着我们打开编译器噼噼啪啪的敲了起来，各种类各种文件搞了一通，X天之后，完成了，高高兴兴的交差去了。
谁知策划说这个界面不行，我们的界面不能和XX公司的一样，现在美术以及爆肝做好了一批新的资源，你去给我把界面改改。
傻眼了！我可是敲了XXXX行的代码，拖了XXXX天的控件才实现这么一个界面，你说改就改，就算项目来得及估计我的生命都来不及了！

看到这里，大家是否感觉到我们就身处在这样一个需求会随时改变而我们的代码却无法以不变应对的改变的漩涡之中？
我们辛辛苦苦做的东西，别人一句否定我们就得全盘推翻重来，这是多么痛苦啊!如果我今后的十年都要这样度过，那我可是准备退出IT行业了哈哈哈。

这里就引申出一个非常有意义的概念，要针对抽象编程而不要针对实现编程。
不知Gof设计模式大家看过没有，以及大面向对象7大设计原则（单一职责原则，开闭原则，里氏替换原则，依赖倒转原则，接口隔离原则，合成复用原则，迪米特法则）这里面主要就是讲如何避免我上面提到的这种现象的发生，让我们写的代码具有较高的复用性。

那是不是看了设计模式就掌握了抽象、架构呢？
实话说，我半年之前就看完了设计模式这本书，也对其中的知识点和一些使用频率较高的模式进行了大量的练习，我以为到这里我就掌握设计模式了，但是现实告诉我，我还停留在那个只能实现功能而不能应对需求的菜鸟阶段。

那什么是抽象？什么是架构？由于本人水平较低就只谈个人理解。编程是具体实现，而抽象是基于具体实现的。我们站在一个制高点来看待我们的编码，把具有共性的提取成基层，对具有变化性的再加以扩展这就是架构。具体点就是把变化的部分和不变的部分分离，不变的我们做封装，关联，变化的使用可配置方式来处理，如配置文件，菜单甚至名称都可以配置，这样就可以固化形成结构。

谈到扩展又要插一嘴。一定要搞清楚，扩展和变化是两个不同的概念。有人说我在抽象工厂模式里加入了新的具体工厂改变了代码结构这不也是改变吗?我的回答是这是扩展而不是改变。举个不恰当的例子，我们有一个凳子，它提供一个可以让我们休息的功能，现在考虑到安全性我们要对它进行防水防火的升级处理。这时我们有两个选择，一个是以扩展的方式来做，一个是以变化的方式来做。扩展的方式就比如说我在这个凳子外面加上一层防护罩，刷上防水漆什么的。而变化的方式就是把这个凳子肢解了，然后对它的构造材料进行更改，比如在木材里加入些合金什么的。这就是扩展和变化的区别，大家认为哪中方式更好呢？

继续。

接着，我们了解很多设计模式后却不应该把自己陷入在已有模式中。一开项目就思前想后的，我该用哪个模式啊，不用设计模式我的程序太low了，如果你还是这样，那说明你根本没有理解“要针对抽象编程而不要针对实现编程”这句话。模式不需要所有的模型都完全懂，要根据自己的需要来逐个深入理解运用。说句与前面有些矛盾话，完美解决问题就行了，管他什么设计模式，我们要驾驭设计模式，而不是被设计模式驾驭。当别人的需求改变了而你仍能从容面对的时候，那么就恭喜自己吧，发现了新大陆。

我是衷心的希望大家在编码的时候能把抽象思维贯彻到底，“以不变应万变”。我们不可以把对自己的要求放的太低，不可以只追求实现功能就好。我们要学会的不是如何解决问题，而是如何优雅的解决问题。这样才跳出漩涡，发现新大陆。程序，是可以写成花的。

现在的这个社会是需求会按秒改变的社会，我们不可能每分每秒都修改自己做好的东西，那样跟没做不是一样的吗！好了，今天就分享到这里，有表达不清楚或者概念逻辑混杂的地方欢迎大家指正，也希望那些和我一样困惑的人看了这篇“杂文”能得到点点启发。 最后希望大家早日的提高自己，跳出漩涡，推动我天朝的软件产业！