在众多软件相关的知识中,软件工程绝对是很特别的一个。
很多人很鄙视软件工程,说:我一看到软件工程的书就直接略过;与之相对应,很多人很推崇软件工程,会花很大的心思去研究敏捷、CMMI等。
刚入职场的程序员大致上是讨厌软件工程的,因为这东西离自己的实践有点远,并且主要是添加束缚。
但既然更加复杂纷繁的历史都可以总结出规律,软件开发没道理就总结不出可以遵循的规律。
也许真的事实是:并不是软件工程没有用,而实在是很多软件工程的书籍理论飘的太高,落地上有困难。
软件工程一个很大的困境在于,它总是试图以软件整体为研究对象,但软件的内部分野过多,不同种类的软件间所适用的方法又充满矛盾。
这最终就导致很多软件工程理论往那里落都有点困难。
而程序员或者项目经理这些现场的人往往是非常务实的,面对这种无法接地气的东西,自然会犹豫和抵触。
还是以前的那个观点。
当一个人一个组织提倡一种方法时,不单要阐明方法自身,还要阐明方法自身的边界。
CMMI,敏捷等等都不应该规避自己的有限性。
确实有无限适用于软件的方法,但这种方法论必须基于软件的根本特质。
对此我们可以讲:
从特质上来看,既然软件是固化的思维,那就必然同时具备思维以及思维所承载之物之特质。
- l思维的特质是指:思维的澄清通常是渐进的,思维自身是不可度量的,思维的主体一定是人,思维通常由概念和逻辑组成,思维的无边界化(灵活易变)这样的特质。这部分特质是共通部分,同时属于所有软件。
- l思维承载之物之特质是指:当思维的对象是数学的时候,思维本身也就具备了数学的特质;当思维的对象是商业逻辑的时候,思维自身也就具备了商业逻辑的特质。
既然思维自身的特质是复合的,那么作为固化思维的软件,其特质必然也是复合的:
既有属于所有软件的共同特质,也有特属于某类软件,甚至同其他类软件完全相反的独有特质。
这是两条完全不同的处理软件工程的方法,都有前途。
要么你基于思维的特质去演绎软件工程,要么你基于具体的场景去演绎,但要阐明限度。
最怕两者都不靠,那就导致内部矛盾,成为一种软件工程自身的困惑。
那软件工程自身究竟有没有一种有效的边界?
如果把所有影响软件的因素都涵盖于软件工程之内,那么这事儿就变成无边界的了,财务、公司运营、市场营销全对软件有影响,如果把他们都包含到软件工程的概念内,
软件工程就变成了四不像,什么都是可也什么都不是。
这点上可以向经济学家取经,经济学家研究经济学的方法是:先假设某些因素不发生变动,进而观察几个特定因素的变化和关系。
我们可以先抽去商务因素、市场因素对软件的影响,寻找本质规律,再把商务因素、市场因素的权变加回来,看看如何弯曲本质规律以适应现实。
好比我们画圆的时候画出的圆总是不理想的,但只要我们知道了圆的理想方程,我们就总可以画出尽可能完美的圆。
从学习软件工程的角度看,也许从《代码大全》这书开始是个不错的主意,这书里即讲软件全体,又讲软件开发的细节,只要是写过程序的人,大致都可以从中吸取养分。
个人感觉软件工程在国内的一个困境是名词始终在不停的变换,但实际起作用的却不多,最终导致刚对一个绝望,就开始对新的一个报以希望这样周而复始的状况。
这种状况也许有其更深层次的原因,比如短期内市场、生存压力等维度上的力量过于强大导致工程力量的长远价值被漠视,进而使方法论并不为解决现实问题而存在,而是为了证书而存在。
本质来看却一定不是软件工程毫无价值。
--------------------------------------------------------------------------------------------------------------
厚颜无耻发个小广告:《完美软件开发:方法与逻辑》出了,修炼内功的书,较抽象,从程序员往管理岗位过度的适合瞄瞄,没事爱思考的人适合瞄瞄。左上角有样章链接。