日常的前端开发业务代码中,我们经常都需要调试数据,所以要经常更改某些参数的初始化数据,或者更改过程中的数据。

我们在生活工作中时常遇到这样的情况,明明是很熟练上手的事情,结果就偏偏是在这些事上出了疏忽差错,如何避免这些低级错误再发生在我身上呢?

无论你是初级工程师,中级工程师,高级工程师,甚至是全栈工程师、架构师,都是从零开使一步一步走出来的,想必都会犯过一些低级错误。

我们到底是谁?首先我们是人,那应该是高级动物,但你信吗?我们每天都在犯低级错误。比如说想健康长寿的人很多,每天早晨都会看到晨练的老人。在我们小区里边啊!他在晨练之后,总是横穿马路。不走人行道,边上一个老爷子翻栏杆过马路。在他走几步的地方就是天桥,大家想想我们每天锻炼身体是为了多活年,然后随时穿马路就准备接受考验,看看扛不扛撞是吧。

       
今天数学考试了,我拿了卷子一看我很伤心,因为错了一道口算题,这是个低级错误,16-8=?我没仔细看,写成了等于7,丢了这一分,所以说以后我要加强口算练习,这样在数学考试的时候就不会口算算错了。

但是很多时候,改了数据调试完之后就忘记改回去了,某个调试的场景是依赖一个参数的修改还好,但是需要依赖几个参数的修改,就很容易漏改回去了。

再熟悉在得心应手的事情,也可能因为一时大意或者临时仓促、情绪紧张而出现失误,就像曾有航天器的坠毁悲剧的起因仅仅是因为那次有一颗螺丝没有拧上。

那些错误都是怎么发生的,如何避免发生错误呢,看看我们各位资深的程序员以自身为例,告诫我们敬畏每一段代码

请问我们开车出去带安全带吗?安全带不是带给警察叔叔的,是给自己的生命上保险的。上车的第一个习惯应该是系安全带,尤其是带孩子出门儿啊!要发自内心的系,这不是系给别人的,这对自己和家人负责任,所以高级动物,不要老犯低级错误。

       
到家妈妈看了看我的卷子,她笑了我几声,我就马上掉下了眼泪,因为我感觉我好丢脸啊!唉!要是当时好好看题,也不会出现这么低级的错误了。

举两个例子:

金沙国际官网 1

开发权限管理很重要,谨慎对待手中的权限

一、我们有一个按钮来触发弹窗的打开,而控制弹窗显隐为变量showDialog,初始化值为false,但是产品说弹窗里面的样式有点问题,所以我们设置了showDialog的值为true然后修改内容,最后修改完再将showDialog设置回false。

开列清单固定做事流程可以提高效率,防止错误,减轻内心焦虑。

云栖社区开发者海阔天空yy:曾经经我做过SQL SERVER数据库存储过程程序员。

//伪代码var showDialog = false; //控制窗口显隐,调试需要依赖其变量值btn.onclick = () = { showDialog = true; }

金沙国际官网 ,反复进行的项目,无论是动手还是动脑的,你都依次详细列出这项目的步骤,参照执行。任何时候对项目进行流程有疑惑就立即再次查看,把心中的焦虑干掉,把心安住,也就让心更专注于当下执行的事情。

当时我们每个人本地都有一套测试环境,所以测试的时候都是在本地测试。由于测试数据比较乱,比较多,为了更清楚的看清结果,我会经常TRUNCATE
TABLE,写到这里大家可能基本猜出来了。没错!在线上出问题时,由于SQL
SERVER
查询分析器可以同时开多个数据库连接窗口,我把线上数据库的窗口和线下数据库的窗口弄混了…所以,线上数据库的一张主要表,被我TRUNCATE
TABLE了。。。当时刚执行完,过了1分钟我反映过来了,头脑一片空白。。。没办法,只能反映给了主管,主管听到后难得得没说我什么,马上找相关人员去处理。。。经过了大约1个小时后,原来的数据总算恢复了,但也导致了这个业务1个小时不能用。。。我都不知道我那1个小时是怎么过来的,坐在那里,动也不敢动,搞程序也搞不下去,就在网上搜如何恢复数据,话说当时我都准备好公司把我开了的准备了。

二、我们有个抽奖的活动,逻辑是请求接口之后拿到抽奖的prize_id之后,对比prize_id的内容,然后决定在视图中显示出来,但是我们需要调试某个抽奖结果的内容,当然不会叫接口改返回的prize_id了,所以我们可能会改传入显示模块的值。

举个例子:一大清早,你在写公众号文章,刚写完还没推送,发现上班时间快到了,必须赶紧出门,于是加紧排版发文,结果就疏忽了没有点击原创声明,发现的时候已经为时已晚。紧接着手忙脚乱的洗漱换衣服,出门去的时候锁门那一瞬间感觉好像遗忘了什么似得,却想不起来是什么,于是只要赶着上班,结果到了公司才想起房门钥匙锁在屋里了,还有昨天准备的文件资料也落在屋里了,想回去却没钥匙,更没时间了。写文推送和出门上班都是日复一日的事情,执行上完全是没有问题的,可是一旦外在条件仓促起来,内心开始紧张,自己就开始疏忽大意的去犯错,所以需要有一份详细行动清单来把你解放出来,从对不总不那么可靠的习惯本能的依赖中解放出来。现在,我有许多清单在笔记APP里面,随时可以查看核对,比如出门之前需要检查关气、带笔记本、检查邮件、清理垃圾、检查钥匙和手机带好没有等等细节,虽然大多数时候我不会看这一个清单,但是一旦在我处于仓促紧张状态一定会查看清单核对,这个清单法帮助我避免了许多错误。

最后结果是,技术总监批评了我们主管,要求部门整改,线上环境严格控制,必须由他把关。

//伪代码fetch().then(prize_id = { showResult(prize_id) //显示抽奖结果,调试需要依赖其传入值})functionshowResult(prize_id){ //显示抽奖结果的代码}

建议你也把生活中的反复进行的事情给梳理出流程步骤,记录在清单上,比如写文章、电话沟通、操作机器等,让你把心安住,不茫然,不焦虑,不遗误。

之后主管也找我谈了话,当然批评是少不了的,作为事故,还是罚了500块钱主管罚了1000。

问题就在于,很多时候我们最后忘了改回去,就会出现弹窗直接打开了、每次抽奖都抽中某个奖品的结果了,这种低级错误是不应该犯的,但是我也见过某些app真的直接这样上了测试的代码到生产环境。

欢迎在评论留言,分享你的见解、方法、问题。

要知道,当时我工资才3500。当时没被开除就算烧高香了吧。。。

所以在这些业务代码中,我相信也没什么人会做构建前的校验脚本或者单元测试的,所以我们需要一个简单的函数来控制变量的赋值,来避免这种低级错误。

我是五点砍柴,原创干货,专注时间管理、知识管理、效率提升,欢迎关注我的微信公众号:五点砍柴。

事后总结起来,其实这主要还是部门管理方面的问题,我刚入职不久的人就能随便接触生产环境,并且还有很高的权限,这才是最大的隐患。当然个人也有问题,工作再忙也不要急躁,特别是你还在生产环境操作。要慎之又慎。

特意写了一个简单的包:

(此文章为五点砍柴原创,若转载请先告知并备注出处,特此声明!)

一定不能隐瞒或甩锅,以解决问题为前提,之后再去review

用法:

云栖社区开发者yolo_omg:在写RPC框架的时候,写了很多bug,在这里分享一个比较严重的:客户端连接断开清除请求数据时抛了ConcurrentModificationException,导致连接关闭异常,恰巧又碰到集团要做断网演练,接着就是1个星期内推动全网升级,拉了很多丁丁群,发了很多红包,还好没有触发线上故障。导致后面写if
else都要double
check了,比如1+1是否等于2,都要写UT进行验证了,然后拉着小伙伴review代码。

//引入包dev-debuggerimport DevDebugger from 'dev-debugger'//初始化dgb实例来控制变量的测试值let dbg = new DevDebugger({ debug: true })//绑定获取替换的方法,也可以直接调用dbg.debugVallet _r = dbg.debugVal.bind(dbg)

发现问题的时候,一定不能隐瞒或者想甩锅,以解决问题为前提,之后再去review!切记!

实例有两个方法:debugVal和debugCaseTag

千万不要在累、疲劳的时候写代码

/* debugVal(pro, dev) @params 传入第一参数为生产值,第二参数为调试值*///也可以绑定方便后面调用let _r = dbg.debugVal.bind(dbg)/* debugCaseTag(pro, tag) @params 传入第一参数为生产值,第二参数为自命名的唯一标签名称*///前提需要配合初始化的传参let dbg = new DevDebugger({ debug: true, caseName: 'testPrize1', //调试的用例 cases: { //用例参数集 'testPrize1': { 'myPrize': 3 //标签名称对应的调试值 }, 'testPrize2': { 'myPrize': 6 //标签名称对应的调试值 } }})//也可以绑定方便后面调用 let _rt = dbg.debugCaseTag.bind(dbg)

云栖社区开发者浮生递归:入职不久就有很高的权限,我觉得这不一定跟管理不善有关系。如果一个公司技术人员偏少的时候,新人也有高权限,是没办法的事情。如果小团队也像大团队一样分工很细,很明确,管理的成本会过高,最终导致破产。

所以上面的例子可以这样写:

有个同事,不小心把线上数据库给删了……还有个同事,没做好安全措施,导致短信被人恶意刷了几十万条,公司直接损失1万多。当然,两位同事都没受到什么处罚。

一、控制showDialog的变量值

我自己有次粗心,一个判断没写完整,直接导致准考证生成的座位号不正确。一堆人拿着准考证去考场找不到自己的位置,哈哈。当然,事后客户也没有责怪我,我也觉得比较奇怪的。做错事不是应该受到相应的处罚吗?

//伪代码var showDialog = _r(false, true); //debug时值为truebtn.onclick = () = { showDialog = true; }

写了十几年的代码,就这么一次事故。让我在日后的代码生涯里心细了很多,代码写完后,重要的部分,总是检查检查再检查。测试后的结果也会一再核对。

二、控制传入显隐函数的值

程序员写代码的时候,状态很重要,千万不要在累、疲劳的时候写代码。这就跟疲劳驾驶差不多,很容易造成事故。有些重要的系统,如果出现问题,是跟疲劳驾驶一样,会直接造成车毁人亡的。比如自动驾驶系统、红绿灯管控系统、航空塔台等。

//伪代码fetch().then(prize_id = { showResult(_r(prize_id, 3)) //debug时为3})functionshowResult(prize_id){ //显示抽奖结果的代码}

工作不易,万事需仔细

当然上面也可以用debugCaseTag方法来将调试的值放在初始化的函数当中。

云栖社区开发者黄一刀:有一回,客户找我说,他有笔收费录错了,要我帮他修改下金额,我一看,小问题,对方又是财务主管,于是二话不说,查询分析器打开,update
。。。set。。。where。。。,选中,一键F5,结果发现where竟然没选中,尼玛啊!赶紧按停止键,死命按鼠标,只怪数据库服务器性能太好,三秒不到就全部执行完毕了,立马吓傻,呆若木鸡,额滴亲娘。由于数据库没有每天都做备份,只能还原到两天前的。第二天,亲自上门找客户,赔礼道歉,还保证下一年免费让他们用一年。还好我是领导,不然绝对得去睡马路。

然而,在我们构建代码的时候,当然不想有任何调试的代码和调试的值的,所以我又写了一个babel插件:

这次之后,我数据库都会每天都做备份,每次按F5键之前,都会反复看好几遍,语句有没有错,语句有没有全部选中,感觉自己现在都好像有点强迫症。

用法:

混饭不易,且混且珍惜,工作不易,万事需仔细。工作上不管什么事都要用心、细心,千万马虎不得,不能拿自己的饭碗开玩笑,要记住,夏天的马路蚊子多,冬天的马路冻成狗。

//修改babel.config.js文件module.exports = { "plugins": process.env.NODE_ENV === "production" ? ["babel-plugin-dev-debugger"] : []}

原先一直认为所谓的流程就是枷锁,现在看来人多力量大,考虑的周全

注意:

云栖社区开发者forest10:我遇到最悲伤的事情莫过于直接在线上操作mongodb了。当时自己刚毕业一年,小公司。也没啥操作流程啥的来约束,公司原先是做类似印象笔记类的。当时因为人和文章的映射关系竟然做在了redis里面。但是好死不死的是服务器被某个开发重启了,更关键的是并没有做redis的持久化。后来决定直接把人员映射做到mongodb里面。。。。关键时刻到了,我把好几个人的映射都做错了,导致好多人隐私都。。。。。好吧,我承认,redis重启也是我干的งว

使用这个babel插件的话,需要在各自文件中import包dev-debugger,而且不要将实例方法赋值出去,可以直接dbg.debugVal或dbg.debugCaseTag使用,也可以bind之后_t或_rt使用,但不要再赋值给其他变量。

通过这次教训,深刻感受到了流程审批的重要性。还有就是不要轻易动线上环境。

原文来自:

我能早一点会git,那么我也就不需要重新写一次代码

云栖社区开发者尼古拉斯雷:写好的程序没备份,是的,之前不会用控制版本。结果有一天,不小心把硬盘搞坏了,你知道那种感觉吗?

就像从几千米高的悬崖低落下来的感觉,心都凉了。

从此之后,开始学习git的使用方法,每次写完一次代码或者要出去的时候都先提交到远程仓库。

说白了,还是因为技术菜,会的技术太少了。流下了没有技术的眼泪…

备份啊,做事之前先做好备份啊。不然硬盘坏了,你能找谁去,如果,我能早一点会git,那么我也就不需要重新写一次代码了。

各位愿不愿意分享一下你在程序员生涯中遇到的悲伤故事呢,点击进入话题:关于代码的那些低级错误,来分享你的代码经历,优秀分享还有奖品送出。

本文作者:不靠谱贝贝

阅读原文

本文为云栖社区原创内容,未经允许不得转载。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图