软件工程的本质，一点个人理解

首先声明，本人业余编程爱好者，把编程当作玩，不在IT界谋生，工作和生活圈子中也无人懂编程，好在有互联网，学了点皮毛，胡言几句，请大家拍砖。 版权声明：本博客文章如非特别注明，均为原创，作者保留所有权利！欢迎转载，转载请注明作者左洸和出处http://www.blogjava.net/myqiao 软件工程本质的三句话总结： 第一句：软件工程的终极目标是复用。 第二句：复用永远要面对的问题是变化。 第三句：依赖是导致变化难以控制的主要原因。

 

关于第一句话，不想多做解释，当然，软件工程中还有成本控制、开发周期控制、文档管理等等，这些工作最终都要通过复用来解决。

关于第二句话，学过哲学的都知道绝对运动和相对静止，所以变化是绝对的、是永恒的、是无法避免的、是不可预测的。对于变化，只能想办法控制它，利用它，不要让它造成破坏，但是不要想着能消灭它。

关于第三句，造成变化的原因很多，但是依赖导致的变化是最难以控制的，也是最具破坏性的。这里举个简单的例子来说明：

某个项目的某个源文件中有如下一行代码：

String PATH="D:\AppServ\www\test";

这行代码中，我们用一个字符串把 Test 项目的路径写死在源代码中，以后我们只要用到项目路径，就引用这个字符串。这样，所有引用到这个字符串的地方都对它发生了依赖关系。这里：用一个字符串是为了简化说明问题，实际中，他有可能是个类，有可能是数据库连接配置，有可能是模块等等。

这时候，变化来了，项目被上传到 Linux 服务器上，Windows 的路径格式无法识别了；数据库也从SqlServer 变成了 MySQL，怎么办？因为一切都写死了，唯一的办法就是打开源文件，一处一处查找，一处一处修改。

于是，一些厂家提供了功能强大的应用程序服务器，大家都按照统一约定的协议，像JNDI之类的东西，把所有有可能变化的因素都配置到服务器里，哪怕他是一个简单的数据库连接字符串，或者是一个复杂的对象实例。等需要使用的时候再通过协议中约定好的接口来访问。如果发生了变化，只需要修改配置，而不需要更改源代码，这样就最大限度的削弱了依赖，控制了变化。

这种重型的解决方案对于大型的、稳定的企业级应用是安全可靠的，但是应用服务器配置的修改维护很麻烦，权限也是个问题，如果你是一个虚拟主机上的个人站长，由于需求变动比较频繁，三天两头要更改J2EE容器配置，估计你的主机服务商不会给你这个权限吧。用核武器对付游击队，似乎太过火了。

大牛们对这种情况看不过眼，于是Spring等轻量级解决方案出现了，所有配置都写道XML文件里面，给了你最大的灵活性和权限。当然，依赖并没有消除，但是反过来了，原来我想要什么需要自己去找，如果发生了变化，可能就找不到，或者找回来错误的结果；现在我想要什么，工厂会自动给我送过来，发生什么变化我不管。当然，工厂是按照配置文件的描述来生产产品的，发生变化只需要修改配置文件，最大限度的减少了破坏性和侵入性。而且，权限都在你自己手里，配置起来很方便。

版权声明：本博客文章如非特别注明，均为原创，作者保留所有权利！欢迎转载，转载请注明作者左洸和出处http://www.blogjava.net/myqiao

写这篇文章是因为为了更好的理解思想，昨天用 PHP 写了个简单的实现发到博客里（文章在这里），却被拍砖说是“为了实现而实现”，可能因为我用的是PHP语言，没有Java高贵吧，所以被人瞧不上眼。但是个人觉得，控制反转、依赖注入是一种思想，并没有和那种语言绑定。

Spring 框架对我这样的业余玩家来说依然太重型了，只是大概了解了一下，对于一个玩票性质的 PHP 个人站点来说，自己做一个简单的实现有何不可呢？