软件随想-项目上线后

从开发到上线差不多用了3个月,其实第一个月就把大部分功能实现了,之后两个月都是需求的再次确认和修改BUG,期间穿插的做别的一些事情。总的来说比较顺利,一马平川没有任何卡住的地方,也没有出现“大脑CPU使用率突然飙升的情况”,但瑕疵太多,在此做一下简单的记录。

简单介绍一下我们的作战方式。页面由专门的人切,只制作出部分页面,类似的自己搞定,之后的样式问题自己搞定,一个产品经理,两个程序员,所有的需求都问产品经理,基本上是除了切页面,其他的都由我们程序自己搞定。做的是一个公司内部的项目管理软件(网站)的改版和升级,对于我来说基本上是新开发一个系统,因为以前的实现方式不太好,我换了一个实现方式,大约重写了91.1%的代码。

 

对需求的理解不够全面。了解需求来自两个方面一个是产品经理另一个是现有代码。产品经理先跟我大致的介绍了一下,然后自己看现有的代码,两者结合得到自己的想法,于是开始开发,期间有问题随时问产品经理。刚开始的时候加入太多自己的想法在里面,导致对需求的理解有些偏差,导致后期做了一些不必要的修改,修改就是对原有代码的破坏,本来写得还行的代码,被一点点的修改,因为小的修改我们总是不在意,慢慢的代码就变得不好理解,到后期对部分代码产生陌生的感觉,我怎么会写出这样的代码。尽管开发期间多次确认过需求,但还是有的地方被忽略掉了。用于理解消化需求的时间太少,导致后期一连串的恶化反应。代码被改得不好理解,在改之前是别人对你的否定以及自我否定,因为你理解需求有误,而现在的实现方式又是你对需求理解的结果,毁掉自己的代码是痛苦的,特别是自己认为写得好的代码,还有就是很浪费时间。总之一句话:在需求调研时引入的BUG危害是最大的。

 

出来混迟早是要还的。不要抱侥幸心理,以为这不会发生,用户不可能这样操作,但是要知道,有的测试人员是很“变态”的,用户也是很懒的,测试人员的一些变态操作会深深植入你的脑海,于是你在测试过程中也会做出异常的因为,于是你的程序就崩溃了,好的,你终于意识到这是个问题,于是你又开始了你的代码修改之旅,也许是个快乐的旅程,更可能多的是痛苦的枯燥的没什么意义的自我批评。可能你还是无视测试人员的变态,运气好的话这种问题一直都没出现,直到遇到一个相同变态的用户,地狱之门突然向你打开,你开始承认错了,你该承认错误了,在开发中我认为可能出错的地方大部分都被测试人员发现了,没有被发现的,我也默默的改了,因为我相信出来混迟早是要换的。

 

成也萧何败萧何。程序员成就了自己的软件,也是最了解自己作品鸡肋在哪的人,如果我们像测试人员一样摧残我们的软件,或许我们能发现测试人员发现不了的问题,同样测试人员发现的BUG就越少,你的BUG列表就干净多了,在这次开发过程就是自己测试太少了,前前后后至少改了大大小小150个BUG。也明白别人发现自己那么多错误多没意思,你发现的问题越多跟别人口水的时间久越少,效率一直都是我追求的,也是因为一直追求开发效率导致这么多BUG。

 

要有一点乔布斯精神,追求完美。因为我们是程序员,我们是有思想有主见的人。我们不能别人让我们怎么做我们就怎么做,这样很没劲,被否定久了就必须反击。需求可能不是很合理,咋们可以给个更合理更完美的实现,页面板块的色调搭配不合理,我们就应该大胆的质疑,给出自己的方案,你不觉得否定别人的方案给出自己更好的方案很爽吗,软件是我们程序员的作品,它应该有我们的思想,我们的设计理念,软件对于我们来说不应该仅仅是执行、实现。我们必须打一场漂亮的反击战,反击设计、反击测试、反击产品经理。只有这样更好的提高自己,才可能做出更好的软件。软件使我们的孩子,必须有我们的DNA,我们应该让他出生后比人的孩子更帅更聪明,直到有一天你很淡定的告诉别人:这是我的优良品种。

 

心有多远,思想就有多远,软件随想还在继续......

软件随想--写牛B的代码

软件随想(一)

 

作者:陈太汉

博客:http://www.cnblogs.com/hlxs/

posted @ 2012-09-29 12:10  啊汉  阅读(3413)  评论(3编辑  收藏  举报