软件随想-项目上线后
从开发到上线差不多用了3个月，其实第一个月就把大部分功能实现了，之后两个月都是需求的再次确认和修改BUG，期间穿插的做别的一些事情。总的来说比较顺利，一马平川没有任何卡住的地方，也没有出现“大脑CPU使用率突然飙升的情况”，但瑕疵太多，在此做一下简单的记录。
简单介绍一下我们的作战方式。页面由专门的人切，只制作出部分页面，类似的自己搞定，之后的样式问题自己搞定，一个产品经理，两个程序员，所有的需求都问产品经理，基本上是除了切页面，其他的都由我们程序自己搞定。做的是一个公司内部的项目管理软件(网站)的改版和升级，对于我来说基本上是新开发一个系统，因为以前的实现方式不太好，我换了一个实现方式，大约重写了91.1%的代码。
对需求的理解不够全面。了解需求来自两个方面一个是产品经理另一个是现有代码。产品经理先跟我大致的介绍了一下，然后自己看现有的代码，两者结合得到自己的想法，于是开始开发，期间有问题随时问产品经理。刚开始的时候加入太多自己的想法在里面，导致对需求的理解有些偏差，导致后期做了一些不必要的修改，修改就是对原有代码的破坏，本来写得还行的代码，被一点点的修改，因为小的修改我们总是不在意，慢慢的代码就变得不好理解，到后期对部分代码产生陌生的感觉，我怎么会写出这样的代码。尽管开发期间多次确认过需求，但还是有的地方被忽略掉了。用于理解消化需求的时间太少，导致后期一连串的恶化反应。代码被改得不好理解，在改之前是别人对你的否定以及自我否定，因为你理解需求有误，而现在的实现方式又是你对需求理解的结果，毁掉自己的代码是痛苦的，特别是自己认为写得好的代码，还有就是很浪费时间。总之一句话：在需求调研时引入的BUG危害是最大的。
出来混迟早是要还的。不要抱侥幸心理，以为这不会发生，用户不可能这样操作，但是要知道，有的测试人员是很“变态”的，用户也是很懒的，测试人员的一些变态操作会深深植入你的脑海，于是你在测试过程中也会做出异常的因为，于是你的程序就崩溃了，好的，你终于意识到这是个问题，于是你又开始了你的代码修改之旅，也许是个快乐的旅程，更可能多的是痛苦的枯燥的没什么意义的自我批评。可能你还是无视测试人员的变态，运气好的话这种问题一直都没出现，直到遇到一个相同变态的用户，地狱之门突然向你打开，你开始承认错了，你该承认错误了，在开发中我认为可能出错的地方大部分都被测试人员发现了，没有被发现的，我也默默的改了，因为我相信出来混迟早是要换的。
成也萧何败萧何。程序员成就了自己的软件，也是最了解自己作品鸡肋在哪的人，如果我们像测试人员一样摧残我们的软件，或许我们能发现测试人员发现不了的问题，同样测试人员发现的BUG就越少，你的BUG列表就干净多了，在这次开发过程就是自己测试太少了，前前后后至少改了大大小小150个BUG。也明白别人发现自己那么多错误多没意思，你发现的问题越多跟别人口水的时间久越少，效率一直都是我追求的，也是因为一直追求开发效率导致这么多BUG。
要有一点乔布斯精神，追求完美。因为我们是程序员，我们是有思想有主见的人。我们不能别人让我们怎么做我们就怎么做，这样很没劲，被否定久了就必须反击。需求可能不是很合理，咋们可以给个更合理更完美的实现，页面板块的色调搭配不合理，我们就应该大胆的质疑，给出自己的方案，你不觉得否定别人的方案给出自己更好的方案很爽吗，软件是我们程序员的作品，它应该有我们的思想，我们的设计理念，软件对于我们来说不应该仅仅是执行、实现。我们必须打一场漂亮的反击战，反击设计、反击测试、反击产品经理。只有这样更好的提高自己，才可能做出更好的软件。软件使我们的孩子，必须有我们的DNA，我们应该让他出生后比人的孩子更帅更聪明，直到有一天你很淡定的告诉别人：这是我的优良品种。
心有多远，思想就有多远，软件随想还在继续......
作者：陈太汉
博客：http://www.cnblogs.com/hlxs/
本文转自啊汉博客园博客，原文链接：http://www.cnblogs.com/hlxs/archive/2012/09/29/2708397.html
