`
MyEyeOfJava
  • 浏览: 1121158 次
  • 性别: Icon_minigender_1
  • 来自: 北京
博客专栏
7af2d6ca-4fe1-3e9a-be85-3f65f7120bd0
测试开发
浏览量:70050
533896eb-dd7b-3cde-b4d3-cc1ce02c1c14
晨记
浏览量:0
社区版块
存档分类
最新评论

程序员那些悲催的事儿

 
阅读更多
文章转与陈皓作者,非本人原创,注明尊重作者版权。

在StakeOverflow上有这样一个贴子叫“Confessions of your worst WTF moment”(WTF就是 What the fuck的缩写),挺有意思的,我摘几个小故事过来,希望大家在笑过之后能从中学到什么------所有的经验都是 从错误中来的(我在其中加了一些点评)

我们公司的软件是给警察局用的,那是一个对用来处理被逮捕的人的系统,此系统还需要收集脸部特征和指 纹信息,并且,
这个系统和会向FBI的系统提交这些信息。当我们在测试这个系统的时候,我们一般都是用我们自己的指纹,当然,数据库
联着的是我们的测试数据库。不过,有一次,在我们测试完后,我们忘了把系统切换回生产库,于是我们的测试数据库
就联上了生 产环境,于是我们的指纹信息和照片就散布到了其它系统中……清除我们警察局这边的还好办,但是,你需要
波士顿警察局警司去法院签字才能从FBI的数据库中清除我们的信息。
点评:测试环境和生产环境的数据不要混在一起。

有一次,我需要向新系统中导入一堆数据,因为数据量太大,需要5个小时,只能在夜里来干,在系统需要正式使用前2个小时,
数据导完了,此时是凌晨4点。随后,我需要删除一些数据,于是我在SQL命令地上输入了“DELETE from  important_table; where id=4”。
是的,我没有看到哪里还有个分号,天啊。
点评:这就是加班工作的恶果。另,在 delete之前最好先做一次select。

我把我的管理员口令提交到了一个开源软件的源码里。
点评:
1)版本管理器里的东西是删不掉的。
2)一 些用户和口令要hard code在代码里,所以,不要混用代码使用的权限和管理员的权限,小心管理程序的运行权限,为其注册专门的 用户。

我为一个很大的银行开发软件,在我的代码里,我为一段理论上根本不可能执行到的代码加了一个报错信息。
有一天,不可思异的事发生了,这条报错信息显示在了该银行的1800个分行的超过10000个终端上------
“如果你看到这个信息,说明整 个系统被Fuck了,回家吧,祝你过得愉快!”
点评:“假设是恶魔”,Assume意为Ass – u – me,意为---- 搞砸你和我。对于一些关键东西,永远不要做假设。小心你言语中的 ----“可能、应该、觉得、不应该”等词语,程 序可不认这些东西。

我远程登录到服务器上加几个防火墙规则。第一件我想干的事是在不允许任何人的任何连接,第二件是,为某个端口打开访问权限。
不过,我在做完第一件事后就把配置保存了,结果其生效了……
点评:这样的事经常发生,做远程网络管理 的人多少会有那么几次发生这样的错误。在你将你的网络配置生效前,你得想一想,断线了你是否还能登得上去。改配置不要太冲动,生效前 检查几次。

我们的代码中有一个模块完美地工作了很多年了,只是代码太乱了。我说服了我的老板,我可以重写这个模块,于是我花了三个星期来重写这个模块。
今天 ,我还记得,我的老板站在我的后面看着我,而我在在流着斗大的法汗珠去fix被我重写的“超级漂亮”的 那个模块中一个接一个的bug。
从那以后,我再也不重写代码了,除非有重大的利益。
点评:这就所谓的屠宰式编程。这个案例告诉我们两个道理,1)维护代码要用最最最保守的方法来进行。2)重 构代码前要像一个商人一样学会计算利益。当然,ThoughtWorks 的咨询师一定会告诉你TDD,结对,极限等等方法告诉你如果实践重构。但我想告诉你,一个程序在生产环境里运行好几个年能没 有问题是一件很不容易的事,那怕其中的代码再烂,你再看不过去,你都要有一个清醒的头脑明白这几点,1)软 件的运行质量是远远大于代码质量的,2)你的测试案例是远远小于生产环境的,3)软件的完美的质量,是靠长时间的运行、测试和错误堆 出来的,而不是某种方法论。

------------------------------------------------

相信大家做程序员这一生中也有很多发生在自己身上的悲催的事儿,欢迎分享。我先分享几个我亲身经历过的事。

一个发生在我的领导身上。

我98年刚参加工作的时候,在某单位网络部门,一次,我们整个部门去给下属单位培训Cisco路由器,结果我们发现带去
培训地点的设备少带了集线器HUB,设备连不起来。于是领导很不高兴,质问我们为什么没有带集线器?那几个对领导平时
就不满的老员工说办公室里没有集线器了,都借给别的部门了。领导想了想,问我:“陈皓,我记得上次我给过你个集线器”,
我说,“好像 没有吧,我记不起来了,什么牌的?几口的?”,领导说:“什么牌子想不起来了,不过我记得那个集线器是一个口的”。
“一个口的?!”,我心里嘀咕着,“真敢说啊”。但我不敢接话了。那几个老员工来劲了------“哪有一个口的HUB啊,
一个口 的怎么联两台电脑啊?”,领导说:“用两个一个口的不就行了”。领导这话一出,全场一片寂静,无言以对……
后来:我们所有的组员都离开了我们的这个领导,我 们的这个领导今天还在那里工作。我想告诉大家,很多时候该走的是领导(包括外企,我上一东家正在裁人,不 过我觉得该被裁掉的应该是那些经理)。我们的领导经常出这样或那样的笑话,这让我随时随地地警醒自己------“不要当一 个被人笑话的经理”,于是,今天我还在努力地学习技术。

另一个发生在我身上。

刚刚接触Linux的时候,还不是很懂,那时的PC还只有奔3,编译公司的程序好慢啊,有时候为了调查一个问题,
需要不断地打log,来来回回地编译,很不爽。直到有一天,硬盘不够了,df一下,发现/dev/shm还有空间。
于是,把全部程序copy了过去,发现编译起程序超快无比,爽得不行。于是就把工作环境放在/dev/shm下了,
连开发都放在这里了。这一天,开发一个功能,改了十来个文件,加班很晚,觉得基本搞定,大喜,回家睡觉。
第二天一来,发现/dev/shm下空了,一个文件都 没有了,问同事,同事不知,同事还安慰我说,上次他的文件
也不知道被谁删了,于是我大怒,告老板!老板也怒,发邮件到整个公司质问 大家谁删了陈皓的程序,无人应答。
IT部门答,“昨晚唯一的操作就是重启了linux服务器,什么也没干,不过我们天天备份服务器, 可以恢复”,
IT部门问我丢的文件在哪个目录下?于是,我reply to all -- “在/dev/shm下……”,哎,人丢大发了……
后来:我很感谢我以前犯的这个错,从那天以后,我 开始立志学好Linux,这个错误让我努力,让我发奋。所以,我想告诉大家------尤其是刚出道的程序员,你们要多多犯错,要 犯错那种丢死人的错,这样你才会知耻而勇。

再来一个发生在我同事身上的。

01年,我们开发银行系统,在AIX上开发,RICS6000很贵,只能在客户那里开发,开发进度很紧张,慢慢地硬盘
就不够用了,系统中有大量的垃圾文件,于是需要清除一些文件,于是有一个同事写了一个脚本,可以自动清除的
各种不重要的文 件,里面有一条命令大致是这个样子“ rm \-rf ${app_log_dir}/*”,意为除程序运行的日志。
为了使用这个脚 本,需要在root用户下运行,一开始还不错。直到有一天,某人一运行,整个根就没了。搞得整个
团队只能用一周前的备份重写已写好的 代码。后来,才发现原因是${app_log_dir}变量为空,于是成了“rm \-rf /*”……
后来:这个事后,我的那个同事,把rm命令改了名,并 自己写了一个rm命令,把删除的文件先放到一个临时目录下。而我也因为这个事情,到今天,每次当我在root目录下使用rm时,敲击 回车的手都是抖的。(另,rm时永远使用绝对路径)这里,我想告诉大家------犯错不可怕,可怕的是不会从中总结教训, 同一个错犯两次。

欢迎分享发生在你身上那些悲催的事。

顶,不错~ 这里面最重要的一个观点:当你要做一件事时,想清楚你要做什么,

你在做什么。如果再进一步解读,就是仔细去思 考你的操作会影响多大范围,影响多少人,重要程度有多高,自然就会以对应的态度来对待。
再好的系统配置也会留下人可以钻 漏洞的地方,而人对行为本身的控制才是最终的解决方案。
对待开发过程中的软件质量也是如此,越多的思考,越多 细节的cover,会带来更高的质量,仅将勉强能工作的代码扔给QA,是不会带来任何根本性的提高的,效率也极其低下。
分享到:
评论
1 楼 haohao-xuexi02 2013-03-28  
我亲自遇见运营部门删除数据的数据,没有where。。直接回车。。之后悔青肠子。。还好有备份数据。。

相关推荐

Global site tag (gtag.js) - Google Analytics