<< MocoSpace网站的架构 | 首页 | Diagnosing java.lang.OutOfMemoryError ( 诊断Java内存溢出) >>

程序员那些悲催的事儿

在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)软件的完美的质量,是靠长时间的运行、测试和错误堆出来的,而不是某种方法论

标签 : ,



发表评论 发送引用通报