现代软件工程里的困惑

在众多软件相关的知识中，软件工程绝对是很特别的一个。

很多人很鄙视软件工程，说：我一看到软件工程的书就直接略过；与之相对应，很多人很推崇软件工程，会花很大的心思去研究敏捷、CMMI等。

刚入职场的程序员大致上是讨厌软件工程的，因为这东西离自己的实践有点远，并且主要是添加束缚。

但既然更加复杂纷繁的历史都可以总结出规律，软件开发没道理就总结不出可以遵循的规律。

也许真的事实是：并不是软件工程没有用，而实在是很多软件工程的书籍理论飘的太高，落地上有困难。

软件工程一个很大的困境在于，它总是试图以软件整体为研究对象，但软件的内部分野过多，不同种类的软件间所适用的方法又充满矛盾。

这最终就导致很多软件工程理论往那里落都有点困难。

而程序员或者项目经理这些现场的人往往是非常务实的，面对这种无法接地气的东西，自然会犹豫和抵触。

还是以前的那个观点。

当一个人一个组织提倡一种方法时，不单要阐明方法自身，还要阐明方法自身的边界。

CMMI，敏捷等等都不应该规避自己的有限性。

确实有无限适用于软件的方法，但这种方法论必须基于软件的根本特质。

对此我们可以讲：

从特质上来看，既然软件是固化的思维，那就必然同时具备思维以及思维所承载之物之特质。

• l思维的特质是指：思维的澄清通常是渐进的，思维自身是不可度量的，思维的主体一定是人，思维通常由概念和逻辑组成，思维的无边界化（灵活易变）这样的特质。这部分特质是共通部分，同时属于所有软件。

• l思维承载之物之特质是指：当思维的对象是数学的时候，思维本身也就具备了数学的特质；当思维的对象是商业逻辑的时候，思维自身也就具备了商业逻辑的特质。

既然思维自身的特质是复合的，那么作为固化思维的软件，其特质必然也是复合的：

既有属于所有软件的共同特质，也有特属于某类软件，甚至同其他类软件完全相反的独有特质。

这是两条完全不同的处理软件工程的方法，都有前途。

要么你基于思维的特质去演绎软件工程，要么你基于具体的场景去演绎，但要阐明限度。

最怕两者都不靠，那就导致内部矛盾，成为一种软件工程自身的困惑。

那软件工程自身究竟有没有一种有效的边界？

如果把所有影响软件的因素都涵盖于软件工程之内，那么这事儿就变成无边界的了，财务、公司运营、市场营销全对软件有影响，如果把他们都包含到软件工程的概念内，

软件工程就变成了四不像，什么都是可也什么都不是。

这点上可以向经济学家取经，经济学家研究经济学的方法是：先假设某些因素不发生变动，进而观察几个特定因素的变化和关系。

我们可以先抽去商务因素、市场因素对软件的影响，寻找本质规律，再把商务因素、市场因素的权变加回来，看看如何弯曲本质规律以适应现实。

好比我们画圆的时候画出的圆总是不理想的，但只要我们知道了圆的理想方程，我们就总可以画出尽可能完美的圆。

从学习软件工程的角度看，也许从《代码大全》这书开始是个不错的主意，这书里即讲软件全体，又讲软件开发的细节，只要是写过程序的人，大致都可以从中吸取养分。

个人感觉软件工程在国内的一个困境是名词始终在不停的变换，但实际起作用的却不多，最终导致刚对一个绝望，就开始对新的一个报以希望这样周而复始的状况。

这种状况也许有其更深层次的原因，比如短期内市场、生存压力等维度上的力量过于强大导致工程力量的长远价值被漠视，进而使方法论并不为解决现实问题而存在，而是为了证书而存在。

本质来看却一定不是软件工程毫无价值。

--------------------------------------------------------------------------------------------------------------

厚颜无耻发个小广告：《完美软件开发：方法与逻辑》出了，修炼内功的书，较抽象，从程序员往管理岗位过度的适合瞄瞄，没事爱思考的人适合瞄瞄。左上角有样章链接。