什么是规避问题呢?首先要说明, 规避问题不是逃避问题。
比如说, 明天有一个比较重要的考试, 今晚我就在考点附近租了一间房子, 结果呢, 快睡觉的时候, 水龙头坏了, 在不断地滴水, 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可能继续出现。 所以,能找到治本的方法, 那自然是好事。 这实际上涉及到一个治标与治本的哲学问题, 作为软件开发人员, 我们需要的是把握好这个度, 权衡利弊, 不可偏废其一