问行业平均维护时间

EN

一位经理最近宣布，他们花了太多的时间来修复错误。

上面听起来很无知。建议阅读类似这样的案例:罗伯特·L·格拉斯的“软件工程的事实与谬误”，特别是“事实43。维护是一个解决方案，而不是一个问题。”

维基百科文章提到了在软件维护上花费了80%的精力。

我的经理让迪尔伯特的PHB看起来像个天才

在上面给出的Hm中，我还会努力分析您所做的所有请求是否确实都是bug。

根据我的经验，对于增强或新特性的请求常常会以bug的形式提交。优秀的管理人员会让他们的程序员发现这一点--糟糕的经理们，好吧，只是不停地抱怨修复错误的时间太长了。

首先要问的问题是，您的"bug修复“实际上是修复代码错误还是其他问题。在大多数情况下，只要您有良好的代码基础，实际代码错误的修复应该是相对较小的。如果您使用的代码基础很差，那么大规模的错误修复是不可避免的。

但是，在将程序投入生产的过程中，您会发现没有文档化的需求、意外的用户活动、数据异常、硬件不兼容、安装问题和其他并非严格的代码错误的问题。通常，经理和用户会认为这些生产支持/维护问题是错误，因为它们通常需要代码更改。

我还遇到过一些经理，他们会将本应被称为小增强请求的内容分组为bug。通常情况下，这些输入到bug跟踪或问题报告系统中，这会使您的"bug“状态比实际情况更高。

这取决于你有多少代码，它已经存在了多长时间，等等。

修复软件错误的时间应该预先加载到发布的前6-12个月，但是随着时间的临近，用于维护的时间与用于初始开发的时间将超过100% --这正是事情的工作方式。

虽然我没有任何可靠的统计数据( Complete确实如此，但我无法确切地告诉您哪个页面/部分)，但在我的经验中，大约40%的开发(有时高达60%)用于维护。很明显，您发布的代码越多，维护时间就越长。Bug并不总是功能性的，它既是程序缺陷，也是不确定性的结果。