最近刚修复了一个存在长达3年多的bug，是这样的
软件从3.0 升级到3.1的时候，某个数据结构不再兼容了，但是一个数据处理的代码需要兼容以前3.0的数据结构。
于是当时的开发人员写下了这么一段代码，伪代码如下：
if isVersion(3.1) then
process Data in 3.1 format
else
process Data in 3.0 format
endif
这样的代码，当时工作很好，测试绝对没有问题，但是当软件版本继续升级到3.2....4.0....5.0....
问题就出来了，当时的判断是is 判断，而不是比较大小，所以3.2以及以后版本都会当作3.0处理，碰巧的是 Process data是另外开发组开发的，他们提供了一定的容错性，可以识别3.0版本的数据格式并处理，但是这样会损失一点性能，大约20％左右，但是当初数据量都不大所以测试中也没人发现。直到了5.1版本，这时候数据量变得很大了，这点性能损失变得比较明显了，因为这系统里数据处理涉及很多加密解码压缩校验以及远程调用等等。。。3年来浪费了如此多资源都来源于当初那个开发人员的一念之差，如果他写成 if versionGreatThan(3.0) 就一切OK。
我了解了一下历史，那时候正是开发很紧张的时候，进度压力很大，这个编码估计也是临时打的补丁，没有深思熟虑。
现实中我们不可避免地要使用些暴力手段写点 hardcode来打补丁，有时候进度压力很大，没办法的，但是我觉得应该有养成良好的习惯，在做这样的事情的时候尽量缩小影响的范围，比如可以写成这样：
if isVersion(3.1) then
process Data in 3.1 format
else if isVersion(3.0)
process Data in 3.0 format
else
ASSERT(FALSE)
endif
这样的话，当系统升级到3.2的时候这个ASSERT会跳出来，提醒你这里有问题，那时候如果时间宽裕可以去找出更优雅的解决方案。