谈谈规避问题在软件开发中的一席之地

         什么是规避问题呢？首先要说明， 规避问题不是逃避问题。

         比如说， 明天有一个比较重要的考试， 今晚我就在考点附近租了一间房子， 结果呢， 快睡觉的时候， 水龙头坏了， 在不断地滴水， 5s一滴， 而且声音还不小。 怎么办呢？ 已是夜深人静， 酒店服务人员比较稀少了， 即使有， 也没有水电修理工啊。 难道非要打个电话， 让别人过来修好？ 这不是影响明天的考试了吗？ 找酒店服务人员沟通， 说换房间？ 那岂不是要重新搬很多东西？ 再说， 就住这一晚啊。

        在这个时候， 最彻底最根本的办法就是找个修理工， 把水龙头修好， 但是， 这无疑影响休息， 而且还烦心。 在这个特殊的时候， 最好就是用规避法

： 反正这个问题我根除不了， 那行， 我搞条毛巾， 让水沿着毛巾流下， 不就没有声音了吗？ 此情此景， 这应该是最佳的办法， 尽管没有彻底根除漏水这个问题。 但对于我来讲，
这已经足够。 

         下面， 我们来继续看看， 在现实生活中， 规避问题的一些例子， 也欢迎大家举例：

        1.  社会上坏人太多。        问题的根本原因， 你们都明白。        根本解决办法是：搞这些人，放在监狱中教育感化 。      规避方式是： 不与这些人来往。

        2.  夏天虫叫扰人睡觉。    问题的根本原因， 有虫在某地方叫。 根本解决方法是：灭掉这些虫子， 你也消灭不了。         规避方式是： 搞个耳罩。

        

        世间的万事万物， 都有一定的相通性。 在软件开发中， 我们也会经常遇到这种情况， 明天就要发布一个重要的版本呢？ 但今天却发现了一个致命的bug, 大家暂时都定位不到原因 ， 或者定位到了， 也没有好的办法。 这个时候， 就不要太死板了， 要相信， 处理问题的方式有很多， 不只有一个。 下面， 我来大概说一下自己的部分经历， 也欢迎大家分享类似的一些经历。

        1. 某年实习， 在某模块中要用到一个开源的日历， 结果总是发日志格子中少了一个竖线。 当然， 既然是开源的代码， 就肯定能知道为什么会出现这个问题， 定位到具体的原因。但我看了一段时间后， 没有找到地方（不是图片的原因）， 代码也确实偏多。 像这种找不到原因的问题， 可以考虑规避方法： 自己加上一条线不就行了么？ 这么做后， 发现可以。

       2.  伪代码如下：

void test()
{
// while中服务端正在接受客户端发送过来的文件
while(1)
{
...;
}

rebootSystem();
}

        在正常情况下， 执行while后， 会正常重启系统并进行相关操作。 但是， 测试同事发现， 在运行期间， 在服务端人为关闭这个连接， 系统居然也重启了（本来业务要求这种情况下不应该重启， 且我在分析后发现， 走不出while， 不会重启）.  我当时进行了测试， 进行了仔细分析， 在这种异常情况下， 程序根本没法退出while,  但是呢？ 从日志上看， 程序又确实退出了while. 太奇怪了。找了大半天， 也不清楚为什么走出了while.    后来， 需要出版本，
没时间仔细定位了， 我就采取了规避法， 如下：

void test()
{
// 正常执行完while后， 会自动重启系统
while(1)
{
...;
}

if(1 == trigger) // 检测到异常触发（人为关闭服务端）
{
return; // 退出， 不重启
}

rebootSystem();
}

       这样， 就算是搞掉了这个问题。

       类似规避解决方法， 其实还有不少。我们可以发现， 规避问题实际上是一种治标的方法。 在本文中， 我们探讨了规避方法的一席之地。 在某些特殊的情况下， 可以适当地采用规避法， 而不应该对规避方法嗤之以鼻。

       诚然， 我们也应该看到， 规避不是万能的， 有时候， 暂时规避了某一bug, 在别的场景下， 该bug可能继续出现。 所以，能找到治本的方法， 那自然是好事。 这实际上涉及到一个治标与治本的哲学问题， 作为软件开发人员， 我们需要的是把握好这个度， 权衡利弊， 不可偏废其一