一次事故说编程的不良习惯

作者:bibodeng 发布于:2016-1-12 20:21 Tuesday 分类:技术交流

今天发布的时候又出了一些状况,我听到之后吃饭都不香了。在开发的过程中,我修改过测试环境数据库结构,但是没有文档化成SQL语句,导致测试环境和正式环境不一样,调试发现测试环境没有问题,但到了正式环境运行起来就有问题了。这是一个行为习惯的问题,是的,我从小到大都是一个比较丢三落四的人,我习惯试错然后正确改正。但是在严格要求要与预期输出结果匹配的条件下,我常常会犯一些低级错误。这种错误非常不应该,却又非常地消耗时间。同事说让我弄一个正式库下来,一个一个跑,然后看有什么问题,结果因为时间赶,我没听。结果应验了墨菲定理,可能出错的地方真的就出错了,险些又搞出大错。我非常恐惧去比对正式环境和测试环境或者开发环境的不同,因为我心里最偷懒的想法是——它们应该都是相同的,对,是应该,结果它往往就是不同。应该是从根本上,我就应当把开发和发布用不同的标准看待,并根除这种编程的习惯。


开发,是可以自己调试修改,可以随意,但是需要将所有的变更都有迹可循,并良好地文档化;
发布,是将自己的成果交给同事去发布,应提供完整的,正确的程序和他们所能理解的材料。

这种不良习惯,大多是来自于大学时代的那种宽松的编程环境,自己折腾个东西,由于不用考虑规范,不用考虑安全性的问题,随手开发完了随手发布到外网去了。而现在工作上要求的,是要提供严格可用的程序,有许多规范和安全性的问题约束,要考虑的细节非常多,当数据库的更改多了之后,一个个脚本,根本不知道可能会少了点什么,尤其是SQL Server这样的可视化和脚本皆可运行的数据库,容易手动改完后就忘记脚本化了,要是MySQL之类的还好,你做什么都得用脚本,没得可视化可以依赖,这反而也是对效率的提升,因为一旦出了问题,还要花好多时间去弥补。在我们做正事时,反复使用方法校验我们所做的事情是不是都正确了,是一个毫不为过的事情。而要做到编写有顺序,修改有理由,整理有条理,还需要在工作中整理一些有效的方法。之前我在设计一个数据库的时候,每个表都有一些必要字段,如CreateTime, CreatorID, Enable之类的,我都是一个个去添加,加完了发现,有的拼写少字母了,有的顺序又不对,结果同事Hyman指了一条明路,原来可以直接拷贝并粘贴,完全不费力气,正确性又有保证。所以我们做的一些工作,能提升正确性的,能提升效率的都可以多尝试一下,一般都能找到比较好的方法,将事情做得又快又好,杜绝了一些犯低级错误的机会。

另外一个不良的习惯是当一个系统接近完成之时,最令人惊奇和有成就感的部分建造完成,往往就没有了兴趣。剩下的是一些收尾和边边角角的事情,做起来可能会没有什么成就感。就像woz一样,当最伟大的工作完成之后,那些没有什么意思的工作,他连搭把手都不愿意。很多计算机从业人员应该都会有这种病,都喜欢做创造性的事情,而对那些小事不屑一顾,提不起兴趣。然而正是这些细节,容易导致一件事情的成败。所以,作为一个工程师,还是要有一点工程的精神,将这些小事也做好。而做这些小事,也正是更好地看到自己所做的系统,并非是完美的,也为我们后续的运营,做一个铺垫,因为往往是那些小地方容易出错,错了还不知道是错在哪里,这也符合二八原理,80%的错误都发生在那20%的事情上。我们近期做的一个项目中,一个大块的代码模块,实现的是支付的逻辑,极少出问题,却是一些边角条件的处理语句上,出现比较多问题。一般来说,这些bug,都是源于我们在脑海里面想得不那么清楚的一些bug,从而遗留到了代码中,而需要测试人员用不同的视角去发现。

从事计算机行业的工作,需要耐心,细心,创新,激情,而更加基础的,是良好的习惯。

by bibodeng 2016-1-12

标签: 习惯 编码

发表评论:

Powered by emlog 京ICP备16017775