程序设计中的概念一致性

如果你写的程序是个简单的学生作业或是界定清晰的算法问题,那是值得恭喜的事情,但更多的时候,程序员要面对用户、产品经理、或是领导的模糊的需求,尤其是那些行业相关程序,需要和领域专家合作时,程序员需要从领域专家的脑子里挖掘知识,将其表达为代码,这就会牵涉到专家和程序员的理解是否一致的问题,而在程序员团队合作的时候,同样存在类似的问题。程序中的概念是现实的不同角度的抽象,同样的一个人在购物软件和博客程序中是两个范畴大不一样的概念。

传统的瀑布流软件工程过程,试图通过需求分析,概要设计,详细设计等一系列过程,先将概念厘清,但是如果问题本来有一定模糊性,需要探索时,这种努力几乎是徒劳的,因为写文档的人就不清楚所有的问题,或者他以为自己清楚所有的问题,但实际上概念不清,甚至自相矛盾,很多地方有二义性理解。虽然需求分析的书上都告诫要消除二义性,但是现实是丑陋的,几乎没有人能做到。

真正的问题不在于文档的多少,而在于所有的人,所有的过程中,对一个概念是否具有一致性,如果需求中是一个概念,到了程序中的包或类中这个概念变了样,那么最终的程序很可能是不满足需求的,如果程序员对一个概念的理解不一致,由此造成的bug虽然没有纯技术上的难度,但却可能是最难消除的。

我想对程序员而言,在概念方面,有以下几点需要注意:

  1. 充分重视概念的建立,用合适的词语表达(从这个角度看,程序中的命名问题怎么强调重要性都不为过),仔细思考概念的内涵、外延及其和其他概念的关系,在新建一个类的时候,在给类设计功能的时候,要慎重,不能以大致能表达需求为目标,而且应当能够简洁优雅的表达需求;
  2. 和用户、领域专家、团队成员,保持良好的沟通,时刻求得理解的一致性,必要时充分讨论、反复确认,要建立一个一致的词汇表,尽量让领域专家也理解设计思路;
  3. 如果有文档,时刻保持文档、代码、和头脑中概念的一致性,这一点也提示我们,太多不更新的文档,只会起到负作用,浪费时间造成误解。当然,由于人员的流动性,文档还是有很大的存在价值的