程序设计中的概念一致性
如果你写的程序是个简单的学生作业或是界定清晰的算法问题，那是值得恭喜的事情，但更多的时候，程序员要面对用户、产品经理、或是领导的模糊的需求，尤其是那些行业相关程序，需要和领域专家合作时，程序员需要从领域专家的脑子里挖掘知识，将其表达为代码，这就会牵涉到专家和程序员的理解是否一致的问题，而在程序员团队合作的时候，同样存在类似的问题。程序中的概念是现实的不同角度的抽象，同样的一个人在购物软件和博客程序中是两个范畴大不一样的概念。
传统的瀑布流软件工程过程，试图通过需求分析，概要设计，详细设计等一系列过程，先将概念厘清，但是如果问题本来有一定模糊性，需要探索时，这种努力几乎是徒劳的，因为写文档的人就不清楚所有的问题，或者他以为自己清楚所有的问题，但实际上概念不清，甚至自相矛盾，很多地方有二义性理解。虽然需求分析的书上都告诫要消除二义性，但是现实是丑陋的，几乎没有人能做到。
真正的问题不在于文档的多少，而在于所有的人，所有的过程中，对一个概念是否具有一致性，如果需求中是一个概念，到了程序中的包或类中这个概念变了样，那么最终的程序很可能是不满足需求的，如果程序员对一个概念的理解不一致，由此造成的bug虽然没有纯技术上的难度，但却可能是最难消除的。
我想对程序员而言，在概念方面，有以下几点需要注意：
- 充分重视概念的建立，用合适的词语表达（从这个角度看，程序中的命名问题怎么强调重要性都不为过），仔细思考概念的内涵、外延及其和其他概念的关系，在新建一个类的时候，在给类设计功能的时候，要慎重，不能以大致能表达需求为目标，而且应当能够简洁优雅的表达需求；
- 和用户、领域专家、团队成员，保持良好的沟通，时刻求得理解的一致性，必要时充分讨论、反复确认，要建立一个一致的词汇表，尽量让领域专家也理解设计思路；
- 如果有文档，时刻保持文档、代码、和头脑中概念的一致性，这一点也提示我们，太多不更新的文档，只会起到负作用，浪费时间造成误解。当然，由于人员的流动性，文档还是有很大的存在价值的