不该忘记的忘记

(俗话说”三天不练手生”，快有一年没有写过java程序，今天替别人做个jsp网站作业，竟然发现自己甚至连if的用法都给忘了，不过自己还是有很多东西记得比较牢的，轻易不会忘记，下面的一些东西写给需要的人来看吧)

什么是软件工程？在大学时也有很多朋友和同学有志于软件工程，大致的原因估计也是因为想去当”管理者”吧。在我看来，软件似乎是一件非常麻烦的东 西，就真正的商用级别的软件项目，很多都是最后草草收场的，里面蕴含着无数的bug和不完美的地方。普通的软件项目可能不用太注重，因为这些东西都是”玩 具”，根本谈不上是软件；商用级别的软件之上是要五个人以上的队伍，不停的面临着客户要求的修改和变化。在这样的项目里面，你可能经常发现，才刚刚完成的 代码被别人修改了；几天前自己写的东西自己都不知道到底是什么意思了；一处小小的改变竟然引起了一场地震般的代码修改，你要不停的”查找”"替换”；你看 到同事小王写的代码根本无法跟自己的代码融合，真想骂他是个SB；客户提了一个小小的功能上的要求，被销售的哥们一口保证没问题以后，你发现你们的团队如 果想在原有的一堆千疮百孔的代码上面完成这个修改之后系统莫名出现各种问题和毛病，怎么查都不知道是什么原因。等等等等，你会发现自己好像掉进了一个泥潭 里面无法动弹，总有一种无名的业火想要把显示器砸烂。在这种情况下，我们就需要软件工程了。

传统的或者现在教科书所流行的软件工程是CMM，源自于美国麦卡基.梅隆大学。当时他们做这个标准的原因也很简单，就是因为美国军方在做很多项目是 发现了上面我所说的那些问题，于是就请麦大设法解决这个问题。在我看来，估计当时制定这个标准的麦大的教授肯定不是软件工程师出身，在制定的过程中想当然 的把软件工程认同为普通的”工程”，认为只要把各种问题”标准化”以后就能大量量产软件了，就像福特发明了汽车流水线一样。于是，CMM就规定，每位软件 工程师在完成每条编码时都要写出你写的这些编码的原因和结果，于是CMM里面就有了大量的文档，文档的数量远远超过了代码的数量，在整个过程中你会发现你 是一值的写文档而不是写代码。

麦大的教授想法不错，但是没有考虑到软件其实根其他的工业是很不一样的，因为软件有很强的自由性。建筑上完全可以按照各种文档和图纸来完成工程，因 为其中可供建筑师自由发挥的空间不是很大。比如你建了一间房子的墙肯定是四面都有的；但是在软件上就不一定是这样了，看似一堆堆的代码，其实是充满着漏洞 的，甚至比盖房子更加复杂，因为在代码里面，出现了问题很难解决，尤其是那些大的项目里面。使用其他工业的管理过程来管理软件这个极其特殊的“特殊”的工 业，成功的可能性当然是非常的小。

几千年来，世界上一直延续着这样的工艺：工程师设计工程，手工艺人完成设计。但是世界到了我们这个年代，特别是软件时代，会变化的这么快。软件工程 师既是设计者又是“手工艺人”，他们的工作贯穿于整个软件的过程中。特别的，由于软件的特殊性，软件的项目也就出现了很多的变数。比如在传统的汽车的装配 中，不可能出现自行车的轮子被装到劳斯莱斯的轮子上的事情；但是在软件中，你就可能出现一个基类“轮子”的指针，本应当被用在劳斯莱斯中，最后引用的竟然 是一辆自行车的轮子？！这样的劳斯莱斯能开吗?!当然，暂时可能还可以用，一旦用于大规模的应用，这样的劳斯莱斯肯定要玩完。但是，在软件工程中，这样的 例子非常多。因为，软件不是那么的直观，一班人很难发现数千行的代码中隐藏的自行车轮子。

所以，我们要问，到底怎么才算的上是“软件工程”？是UML图吗？我想不是，因为UML不能告诉我隐藏在代码中的自行车轮子。是CMM？文档告诉我 们什么？它不过是机械的告诉我某某个地方要用劳斯莱斯的轮子，但是天知道在服务器的内存里面运行的到底是自行车轮子还是劳斯莱斯轮子？

所以，真正的“软件工程”不应当是那些不懂编程的人评经验规定的，而是要用真正熟悉这个领域的专家来制定的。很高兴，现在很多“敏捷”领域的专家已 经发现了这个问题。比如TDD（Test Develpment Driven）就是个不错的“软件工程”，他的原理也很简单，就是Test Case.劳斯莱斯是什么？不就是在高速公路上面能够跑到230公里吗？我们就写一个这样的Test case,只要通过这个case的车都是装着劳斯莱斯轮子的车。这样，我们就完成了软件中最为迷人的部分：未知性测试。通过测试的代码都是经的起考验的代 码，既是在以后的重构中也没有问题。