干掉代码中的不等于

前言

“干掉代码中的不等于”听上去有点武断，“干掉代码中的不等于，同时也要干掉代码中的等于”就更极端了。但恰恰是这样一个极端而武断的观点在管理应用开发中极其有用。
卖了一个关子，其实今天给大家分享是关于程序扩展性的话题。

正文

一、使用等于会带来扩展性问题

下面分享一个具体的例子
1，原始需求：深圳地区的订单，验收进入云仓库，这个需求实现起来非常简单

if (AreaName == "深圳"){
	//验收到云仓库
	//.......
}

2，过了一个月，客户提交了新需求：云仓库的的需求单需要通知预约领用，在实现这个需求上，分歧就产生了：
单纯满足功能的程序员会这样写

if (AreaName == "深圳"){
	//通知预约领用
	//.......
}

有一定前瞻性的程序员会这样写

if (StorageType == "云仓库"){
	//通知预约领用
	//.......
}

3，又过了几个月，深圳的云仓库运行的非常不错，业务部门策划着上海也要使用云仓库，这时候单纯满足功能的程序员就既要修改上面的验收到云仓库的规则，又要修改通知预约领用的规则，具有一定前瞻性的程序员还是需要修改一处代码

if (AreaName == "深圳" || AreaName == "上海"){
	//验收到云仓库
	//.......
}

4，时光如梭，又过了几个月，业务部门觉得云仓库模式非常不错，应该进一步推广到北京与成都，这时候代码又要修改了

if (AreaName == "深圳" || AreaName == "上海" || AreaName == "北京" || AreaName == "成都" ){
	//验收到云仓库
	//.......
}

现在，大家应该发现了问题所在，从一开始我们就不应该使用坑爹的等于号，应该采取集合运算

if (areaList.Contain(AreaName)){
	//验收到云仓库
	//.......
}

钻牛角尖的同学肯定会说，这不是掩耳偷铃么，你不过是把等于号封装到Contain函数中，怎么可以说干掉等于号呢！其实，在等于号的问题上想给大家分享的是，当你使用等于号的时候，你有没有思考过他会带来扩展性的问题。

二、使用不等号会带来逻辑性漏洞

我们将上面的例子稍做改造，比如现在我们只有上海与深圳两个地区，在上文提到的将深圳地区的订单验收入云仓库的例子中，会有一部分同学选择

if (AreaName != "上海"){
	//验收到云仓库
	//.......
}

后来新增北京地区，一个隐藏的Bug便产生了，现在北京地区的也验收到了云仓库，针对于这个例子修复Bug的方式自然就成了

if (AreaName != "上海" || AreaName != "北京" ){
	//验收到云仓库
	//.......
}

特别是在项目组人员变动的情况下，新人不敢改旧代码，这类Bug通常都是后知后觉，很难预知。现在大家可以清楚的发现，使用不等于不仅仅面临着扩展性的问题，还隐含着逻辑性的漏洞。所以，在不等于的问题上想分享给大家的是，不等于是不是应该转换为等于。

每写一个等于，你都应该思考是否会带来扩展性问题；每写一个不等于，你都应该提防是否会引发逻辑性漏洞。