• 我对软件工程中的墨菲定律的理解
  • 发布于 2个月前
  • 220 热度
    0 评论
  • Carmelo
  • 0 粉丝 5 篇博客
  •   
最近读墨菲定律,发现其实会对我们的工作和生活有点启发。

墨菲定律是什么?
“墨菲定律”、“帕金森定律”和“彼德原理”并称为二十世纪西方文化三大发现。
“墨菲定律”:事情如果有变坏的可能,不管这种可能性有多小,它总会发生。比如你衣袋里有 两把钥匙,一把是你房间的,一把是汽车的;如果你现在想拿出车钥匙,会发生什么?是的,你往往 是拿出了房间钥匙。
    
其实墨菲定律就是揭示任何事情的不确定性,我们需要提前做好准备。

墨菲是美国爱德华兹空军基地的上尉工程师。1949年,他和他的上司斯塔普少校,在一次火箭􏰀 速超重试验中,因仪器失灵发生了事故。墨菲发现,测􏰁仪表被一个技术人员装反了。由此,他得出 的教训是:如果做某项工作有多种方法,而其中有一种方法将导致事故,那么一定有人会按这种方法 去做。
墨菲定律的适用范围非常广泛,它揭示了一种独特的社会及自然现象。它的极端表述是:如果坏 事有可能发生,不管这种可能性有多小,它总会发生,并造成最大可能的破坏。

根据“墨菲定律”:  
一、任何事都没有表面看起来那么简单;  
二、所有的事都会比你预计的时间长;  
三、会出错的事总会出错;  
四、如果你担心某种情况发生,那么它就更有可能发生。
五,放任不管只会让事情会越来越糟。

个人尝试来解读这些法则,可能不正确,不全面:
1. 我们做任何项目,很多事情我们只能看到冰山一角,很多未知的问题,我们无法预测,所以需要做很多前期调研, 不打无准备之战。
在项目中,我们开各种会议,grooming meeting, plan meeting, demo meeting, stand up meeting.或者是case review, 就是让大家一起来分析,规避各种风险,防患未然。有些会议该开还是得开。

2. 做任何事情,没有那么顺利的,要提前多预估一些时间,留一些buffer, 不然会被自己的计划和进度给逼死。在每个软件研发的迭代中,我们需要考虑最好的情况,也要考虑最坏的结果。充足做好两手准备。
做项目管理时,我们不能光看做事情的时间,还要预留一些解决问题的时间。测试中,我们不能知预估执行测试时间,我们还得看修bug时间,regression时间。当然也不会允许把buffer留得太长。

3. 这个从两方面来解决,从事的方面来说,坑人的地方肯定会有很多坑,如同你从平原进入了湿地,很多地方会容易被陷入进去。
从人的方面来说,那种丢三落四的人,关键时刻掉链子的几率大,重大的事情,还是不要给他做。

4. 如果你担心的事情,说明他就有那种迹象,那种苗头,你已经预感到了。发生的几率就会越大。俗话说的,怕什么,来什么。哪壶不开提哪壶。
在我们测试过程中,有些问题不容易重现,我们看轻重缓急,还是得努力重现出来,如果你预感它要发生,没准那天就在众多用户之一中暴雷了。
如果你觉得不太确认,你又担心的事情,可以知会相关人士,让他们心里又个准备。如果不行,写说明或者提bug, 万一发生了,也不全是你的锅了。

5. 放任不管,只会让大家跟松散,事情不会朝着好的方向,或者你预想的放下继续发展。不知是事情如此,团队也是如此。如果你干预,也许会改变线路,还能挽回一些。如果破罐子破摔,那么只剩下渣了。
有些事情,就及早做决断,及早解决。如果不解决,当达到一定的量时,就得花大力气来收拾烂摊子了。当断不断,必留后患。当机立断,消除隐患。

Bug 越早发现越好,越早修越好,所以得有手段或者方法,提前暴露bug. 这就考验研发人员的功力了。

    比如,一段代码本可以提取为公共方法 /组件,但是这需要轻微地调整结构,以及随之带来的一些调试工作,这是有意义的,但很多人会选择复制粘贴,能跑就行。《程序员修炼之道》中提到的“ don't repeat yourself ”原则,便是如此。
    比如去拥抱函数式编程,虽然这学习和使用起来更有挑战,但是在可读性和简洁性上更胜一筹。
    比如在完成代码后注意立即更新相应的文档,谨防遗忘,更重要的是避免给合作者带来难以溯源的问题以及问题产生之后的沟通成本。
    这些虽然都是小事,要做到真的不容易。

    项目肯定都要阶段性重构的。不要等你的代码变成了难以攻克的庞然大物,才后悔之前没有常行举手之劳。

用户评论