Shell's Home

Oct 13, 2007 - 1 minute read - Comments

关于程序的一点想法

以下内容六牙四皂小姐可以看看,至于看的懂看不懂不负责。

程序届有个说法,只有你想不到的,没有我做不到的。当然,程序是基于数学的。如果违反了数学的基础理论,程序还是无法实现的。可程序又不同于数学。说穿了,程序有一个时间,成本和环境的限制,有的时候还有法律问题。理论上说,任何一个水平足够的人都可以写一个windows出来。但是,首先是一个人写需要多少时间。其次是这些时间,还有其他投资(例如电脑)所造成的成本。然后是这个windows所能运用的环境。当然windows也许没有这个问题,可如果是程序就必须考虑适用系统(Windows,*nix),字长(32bits,64bits)等等限制。最后,一个和windows一样的系统是否会侵犯了微软的版权?

对于程序员来说,可能这些都不是问题。程序员面对的是明确的目标,环境,解决方法和框架。他们要解决的是按照构思来实现功能,并且按照算法来构建代码。例如一个播放器,对程序员来说可能就是一个确定的接口,向里面写入固定格式的数据。或者引用某种算法读取压缩数据,解压为通用数据进行播放。或者是实现解码器的注册和管理。这些都是已经被严格确定了的目标。程序员有一个固定的环境,一个统一的框架。解决方法或者是被说明的,或者是不言而喻的。

可是由一个抽象的需求来获得一个明确的目标,并且确定环境和实现方法由谁来做呢?一般这些人被称为需求分析师和系统构架师。需求分析师的工作在于帮助用户确定需求,分析需求的可能性产出(例如播放器中是否需要一个屏保屏蔽功能),分析系统的目标环境。这些任务更多的是出于用户角度考虑的,主要是我需要做什么(what,

why)。系统构架师则是一个对称的职务。其主要职能在于确定如何使用目标环境中的各种技术实现目标需求,使用这些技术完成目标需要多少时间,多少成本,是否引发法律问题。等等等等。这些问题更倾向于从程序员角度考虑,主要是怎么做(how,

when)。

当然可能没有这种职位,但不可能没有这种职能。有的时候分析和构架是由项目经理兼任的,有的时候是由客户驱动的(尤其是外包的时候)。至于完全没有的时候,就只有将需求分解为零散的问题,对问题求工具了。理论上说这是一种很好的方法,强大的bash语言体系其实就是由一堆解决细节问题的工具组成的。问题是,这种情况下,对于工具的使用者就提出了很高要求。往往会把工具的使用者变成另外门语言的使用者。例如我们看电影,一般用户只是点开就看而已。如果是针对问题求解,可能我们会出现一个播放容器,一个编码分析器,一个视频解码管理系统,一个音频解码管理系统。最后还需要一个注册器来关联适当属性的播放容器和某种文件类型。从软件结构角度,这样的软件有利于构架和编写。可从用户的角度,这是最差劲的播放器。事实上,mplayer就属于这种播放器。我们用起来觉得简单是因为一些高手制作了一些预先设定的包,将所有组件关联起来。

我们回到原本的问题上来。如果用户驱动了系统的构架,那问题自然不大。只需要制作方评估系统规模,然后按照规模给出成本和时间。双方讨论一个可以接受的成本和时间,东西就可以做了。至于客户变更了系统,那自然有相关的人员会重新评价,给出新的成本和时间。问题是如果约定不清晰,可能会造成比较大的麻烦。例如客户认为他们给出的解决中必须实现某个东西,而程序这里认为是最好实现某个东西。那就扯不清楚了。因此一般建议编程人员向客户要求一份详细的制式计划书,然后双方签字确认。根据合同法规定,如果制式合同中出现纠纷,应当被解读为不利于提供方的方式。倒过来显然是不行的,既不能指望编程人员提供计划书,也不能指望客户不会对计划书随便解释。

如果是由非客户的分析和构架人员来做系统构架,那么情况就复杂了。问题实质上其实变成了五方会谈。客户方,代表客户方的需求分析师,制作方,代表制作方的系统构架师,还有程序员。看起来有点重复,但是其中都有利害关系的。客户方希望需求分析师提出尽可能多的需求,因为这样才能产生好用的软件。系统构架师则希望需求分析师提出尽可能少的需求,这个才容易制作和维护软件。制作方希望系统构架师提出尽可能高的成本和时间预算。这样有充裕的时间制作,不会制作失败,还可以多赚钱。但是客户方不会喜欢很高的成本和迟到的软件。程序员希望系统构架师给出的解决方案足够清晰,而且改动少。系统分析师总喜欢在程序员的失败中改进方案,因为简单啊。客户方希望程序员给出完整的文档和后期维护,但是程序员都不喜欢写那东西。

所以需求分析师往往会提出一堆怪怪的功能,即使这东西一般人八辈子用不到。系统构架师往往会提出高的吓人的成本和时间预算。和股指差不多吧,没几个有脑子的相信。真正的成本和时间就会在客户和制作的吵架声中被确定,并且往往成本高出正常值,时间低于正常值。程序员就在一次次的咒骂声中修改系统,并且经常忘记跟着修改文档。客户拿到手的往往是一个延期了再延期的系统。它们十有八九跑的起来,刚好可以完成预定目标。只是往往会有一些Bug,并且只有不同步的文档。系统就会在客户的抱怨声中被退回,而且客户还会追加两个需求,加上句“钱不是问题”。制作方看在孔方兄的面子上,往往也会说“保证完成任务”。系统修改的结果往往是Bug越改越多,文档越改越老,系统越改越奇怪。最后系统分析员往往会找到一个下家而跳槽,客户往往会因为钱是问题而拖帐,制作方往往会保证完不成任务,程序员往往会抱怨天天加班,唯一没问题的需求分析师往往是客户亲戚兼任的。

到底是哪里出的问题?