写代码不免出点bug,没有人可以保证自己写的代码不出问题,而那些没有被挖掘出来的bug,便成了后来者哭笑不得的坑...
高陵网站建设公司成都创新互联公司,高陵网站设计制作,有大型网站制作公司丰富经验。已为高陵上1000+提供企业网站建设服务。企业网站搭建\成都外贸网站建设公司要多少钱,请找那个售后服务好的高陵做网站的公司定做!
这段时间公司全面 https 改造,涉及到域名的迁移,域名的迁移不是 nginx 做个映射就完事儿了,还有各种代码的去 schema,各种组件的搬迁,算是一个大手术!我看最近百度主站也升级到了 https,期间应该出过一次问题吧,貌似回滚了一次,他们遇到的坑应该还不算多,只是 www 域升级,而不是全网。公司最近出了不少的问题,大小问题都有,表面看是前人挖的坑,实际是整体架构思考的有欠缺。
当我们放下一个项目转投下一个时,手头的东西就要转交给他人处理,或者..不再有人处理,可代码还在那里,搞不好你就引用了别人的东西,保不准哪天别人的代码里就爆出了个大 bug,当然这里的“别人”也可能是 你!我们既不希望自己是受害者,更不希望自己是施害者。
挖坑可不是一件简单的事情,你写出来的插件、组件、代码,很可能被很多人用到了,各种业务场景下狂奔你的代码,一堆测试人员检测你的bug,所以在项目中埋坑可不是一件容易的事情。
那么如何埋坑呢?可以参考以下方案:
如果这些方案还不够你挖坑,我想你团队同学的技术水平也真真是太高了。
很多时候,我们都是不经意间留下了隐患。当自己写的东西被其他人使用后,程序需要兼顾的场景就会增多,出现的问题也会变多,这个时候我们不得不完善自己的代码逻辑。结果就是,逻辑耦合度高了不少,代码层次深了不少,出错的概率也就增加了不少。
所以在设计一个功能或者组件的时候,该考虑什么,不该考虑什么,一定要理清楚。并不是所有东西都适合往代码里加,我们不是在做 ExtJS 这个整体方案,也不是编织一个底层的操作库,只是用少量的逻辑整合离散化、个性化的业务,这些逻辑越少越好,与核心逻辑无关的内容就必须抽离出来!
如果说挖坑是一件很有难度的活儿,那踩坑就更难了。其实可以说难的不是踩坑,而是发现自己踩坑了。
在一堆巨量的文件中找出「因把等于号写成恒等号」造成的 bug,这不是轻松的事情,可能你在 debugger 的时候进入了别人的代码领域,对着别人巨长而又没什么注释的代码,估计当场就晕了,更晕的是,自己却还在怀疑这到底是不是这堆代码里头的问题。团队合作中,我们心里默认相信队友,队友产出的代码是没有问题可以直接拿过来使用的,所以一旦出现问题,我们怀疑更多的是自己,质疑别人需要很大的勇气,尤其是质疑那些成熟的框架,用了很多年的代码。
那么如何踩坑呢?我们可不喜欢踩坑,有的坑踩进去就跳不出来了,***只能选择其他方案处理。很少有前端同学写程序的测试用例,可能还有一部分同学根本就没听说过什么测试用例。而在后端中(比如nodejs)没有测试用例的代码就是一堆废代码,除了自己可以拿着用用,别人根本就不敢用的。那么测试用例会考虑做那些事情呢?简单点说:
测试用例要覆盖到程序中所有的逻辑判断,比如 if elseif else 等判断的逻辑都要覆盖进去。当我们的测试代码覆盖了100%的逻辑,那坑位就展露无遗了。
埋坑人的致命弱点就是很少对程序作出异常情况判断,只要找出程序中的异常点,试图以另类的方式触发这个异常,你就顺利踩坑了!
首先,填坑是一种责任。
发现问题是最难的,解决问题只是时间的问题。当我们确认了一个坑之后,***件事情就是告诉别人这里有坑,你不要踩了。但是***再多补一句话:你先别踩,等我填好了坑你再来。我这觉得这句话真的很暖人心,程序猿之间的关怀就应该这么赤裸裸的。尽管,有的时候,这个坑不是你挖的..
当我们挖好坑,踩完坑,再埋好坑之后,回头想想自己在团队中扮演什么样的角色,挖坑者还是埋坑者?这必然是有益于成长的。
分享题目:前人挖坑,后人填坑—如何把那些bug挖掘出来
新闻来源:http://www.shufengxianlan.com/qtweb/news44/153844.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联