[转载]企业定制软件开发的两个核心问题 - TAOWEN的一些个人记录 - 博客园

[转载]企业定制软件开发的两个核心问题 – TAOWEN的一些个人记录 – 博客园.

企业定制软件开发不是计算机科学,需要解决的不是编译原理也不是组合数学。那么,企业定制软件开发的核心问题是什么?

越来越感觉到,从事一个领域不需要有特别深刻的理解,但起码要知道做这个领域的事情,需要解决的核心问题是什么。比如说,开发C/S结构软件,状态 同步(C/S状态同步以及窗口之间的状态同步)就是核心问题之一,而开发B/S结构的软件,状态同步就不是那么核心的问题。如果事先知道需要有这些核心问 题需要考虑,在日常应对接踵而来的具体的事务的时候,就能够把解决问题的层次抬到更宏观的层面。

目前而言,个人感觉企业定制软件开发的核心问题有两个:

1、如何保证所有参与者(包括客户在内的开发团队,以及最终用户)的沟通强度,使其能够满足完成开发目标的需要

2、如何管理企业定制带来的软件自身内在的高复杂度,使得复杂度不会超过团队的维护能力范围

在前面一篇介绍组 织的Blog中,谈到了核心问题中的第一个,沟通强度问题。团队而言,刨去个人能力,最重要的就是人与人之间的沟通。没有好的沟通,即便团队的个 体能力都超级强,也无法形成合力。但只要有好的沟通,至少可以做到人尽其用。假设一个标准人的生产力是1/day。某些特别强的人可以达到3/day。但 是如果需要达到10/day的生产力才能在市场允许的时间下完成项目,那么就无法用一个人来完成之间事情,所以才会有团队存在的必要。但是有两个标准人, 并不会达到1+1=2/day的生产力。可能只有1.5。有三个标准人,更加不会达到1+1+1=3/day的生产力,很有可能有1.8。那么是什么制约 了团队的整体生产力,那就是沟通。当两个相关联的任务A和B是一个人做的时候,关于任务A的知识存在于左脑,关于任务B的知识存在于右脑。那么结合两个任 务的知识把其组装起来的沟通效率就是大脑内部的电信号的速度。但是如何任务A是由Dev甲完成的,任务B是由Dev乙完成的,那么整合两个任务的效率就受 到人嘴皮的震动频率的约束,受到表达能力的约束,受到理解能力的约束。有人研究过,两个人即便是面对面,传输的比特率也要低于最早的拨号式Modem。更 不用说,有的时候开发团队是分布式的。在无法看到表情,肢体语言,无法共享白板,只能在越洋电话里听到声音,而且其中还有一方是非工作时间,在这种情况 下,1+1几乎很难达到1/day的生产力。什么是高效的团队,就是能够让1+1的值尽可能大的团队。如何变得高效,让沟通变得更加高效。怎么样让沟通变 得高效高强度?这就是我们要处理的核心问题。

第一个问题可以应用于所有的人的团队行为之中。人只要聚集成群,就会有沟通问题。所谓,有人的地方就有江湖。第二个问题则特定于企业定制软件开发。 对于互联应用开发,也许复杂度的管理是其次的,最需要关注的是大用户量下的可扩展性。但是对于企业定制软件开发,由于业务自身的复杂度,导致了定制软件的 复杂度。特别是业务的组合,导致的组合复杂性。假设在理想情况下,一个系统可以分解为模块A,B,C,其复杂度都是2。在复杂度管理良好的情况下 ,这些模块是被明确划分的,要理解A,只需要关注A,以及B与C少量与A交互的部分,也许理解的复杂度只是2 + 0.5.。但是在复杂度没有管理的情况下,所有的“逻辑”(也就是复杂度)都是随意地放置的。那么也就是没法办法保证,读A的逻辑只需要关注A,甚至这个 A都是不存在的,你看到的知识一个系统,包含了A,B,C的功能,是完整的一块。这个时候要真正了解这个系统行为,可能就需要2 * 2 * 2 = 8这么高的代价了。随着模块(变量,方法,类,包,模块,Bundle)的增加,我们需要同时理解的东西也在不断增加。不去可以地管理复杂度,很有可能, 我们需要了解一块功能,就需要把所有的代码都去阅读一遍。或者说,改动了一个方法,使得整个项目都需要重新被测试,因为没有地方是可以被信任的。如何管理 复杂度?这就是我们要处理的核心问题。

有意思的事情是,这两个核心问题是重叠的。把人,角色等同于类,接口,都抽象地看成点。把沟通理解为人与人之间的联系问题。把复杂度也理解为类与类 的依赖问题。那么沟通问题和复杂度的管理问题都是如何把这些点联上线,组成一个高效的图的问题。这个图,就是一张关于“依赖”的图。人与人之间的依赖,类 与类之间的依赖,包与包之间的依赖。依赖的另外的一个名字就是Coupling。而我们追求的就是Cohesion。Coupling(耦合)/ Cohesion(内聚)这两个词的妙处在于,明白的人根据自己的经验,一看就点头。不明白的人,由于没有对应的经验,无论怎么解释,都是摸不着头脑。正 是因为其“妙不可言”性,所以我可以说这两个词就是所有问题的答案(你也无法反驳)。但至少我们可以知道企业定制软件开发的核心问题其实就是一个:就是管 理好人与人之间的Dependency,包与包之间的Dependency,使得信息可以在高度依赖的人与人之间快速传递(强调Coupling带来的消 息传递的效率),而理解又可以局限在高度内聚的模块内部(强调Cohesion带来的维护便利),但同时又不能让某人过度被依赖倒置工作过劳死了,被依赖 得越多要求其体能越好,对于包的内聚也一样,高内聚做到极致就是最小的编译单元(类?),又会导致包的粒度过小,使得包的数量变得巨大,失去了维护的便利 性。我们需要做的,就是在To Depend or Not To Depend中,根据场景作出取舍。

那么抽象而言,无论是解决沟通问题还是复杂度问题都可以归纳为:

1、设置目标指标

2、度量现有的指标,观测现有的依赖图

3、做出依赖图的调整计划,并执行

4、观察指标的变化

5、重复步骤3,4,直到目标达到

但是问题是:

1、如何度量指标?沟通的效率?代码的质量?都很能度量。

2、如何观测现有的依赖图?包的依赖还可以观测,但是团队的协作是比较难观测的。

3、如何对依赖图做调整?重构?Change Agent?人不比代码那么容易改变。

4、如果指标不是简单数字,怎么比较?怎么知道指标是朝着目标发生变化?

这四个问题,几乎没有硬的科学问题。管理复杂系统的复杂度,可能是一门硬的科学。但是夹杂了人的因素的企业定制软件开发,一定不是一门硬的科学。那 么,数学公式不是这些问题的答案。那么该朝哪个方向努力?

TO BE CONTINUED

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏