三无的代价

三无的代价

    这是一段真实的经历，讲述了一个软件开发中遇到的种种问题，可以说是软件危机的在实际项目中的真实

体现。为了避免再次重蹈覆辙，特撰写此文以勉励自我。
    2001年夏，我刚毕业，来到一家不算太小的软件公司工作，这家公司是做电信周边业务的公司，效益还不

错。进入公司后，由于一位同事的离职，一个做了一半的项目便落到了我的肩上。这是公司给我的第一个任务

，我很高兴，因为我觉得这是我施展才华的大好机会。这个项目很小，用部门经理的话说就是一两周可以完成

的项目。我将项目接了过来，很快的阅读了留下来的全部代码并完成了整个软件的开发，整个过程仅仅花了1周

的时间。我很高兴，这么快完成了任务。同时，我也得到了领导的器重。很快另一项大项目启动了，我便参与

到了这个项目中，在这个项目中担任一个还算比较重要的角色。这时的我可以用春风得意来形容，但是悲剧在

此已悄然拉开了帷幕。
    我还记得，交付用户使用时的情景，我将该软件刻录到了一张光盘上，来到客户那里，为他安装好，并将

系统运行起来，客户看了之后也非常满意。但是，就是从这里开始，问题便接二连三的出现了，系统不稳定，

有些端口无法接收数据，网络通讯经常出现中断，甚至经常造成死机。每次出现问题我就必须去客户那里解决

一次问题，经常影响到新系统的开发，由于有很多新的任务，也无法抽出时间来做一次大的修改，于是就这样

修修补补的，一晃几个月过去了，但是这个软件仍然不能正常的运行。终于，客户也无法忍受了，他告诉了我

的部门经理，说这个项目已经拖了4个月了。来自于客户的不满，当然的使我受到了严厉的批评。被迫，只能放

下现在的工作重新对系统做一次全新的设计。
    当我重新来看这个系统时，我才发现在我接手这个任务时，这个系统的设计便存在非常严重的缺陷，这个

缺陷是导致错误的根本原因，要解决实际问题只能将系统重新的进行设计，于是我便花了2周时间重新进行系统

的开发，除了一些周边的辅助模块外，其核心代码几乎被全部替换。对系统做了测试然后再交给用户。新的系

统运行的稳定性有了很大的提高。
    了却了一件心病后，再从头看起这个项目的开发过程，让我感触颇深，一个软件的开发一定要规范，对系

统的设计不能随心所欲，应该考虑周详，从各个方面认真的审核设计中可能存在的问题。为了保证系统的正常运行，测试过程绝对不能省略。