如何估计一个项目的工时长度：评论代码[关闭]

Question

有人对如何估计评论和重组整个项目的代码需要多长时间有什么建议吗？

我刚开始与另一位程序员一起为一家公司做合同工作：他正在修复错误，而我正在重新组织代码。我想估计一下我需要多长时间才能逐行浏览代码并评论和/或重新组织代码。这是一个非常大的解决方案：它有两个项目，每个项目都有多个文件。

有人建议我计算每个文件中的所有代码行数，把它们加起来，然后加倍你的时间来给你填充。还建议我在估计之前对代码的大小进行平方。但我不知道需要多长时间才能评论，比如 100 行代码。

欢迎提出任何建议。如果有影响，项目是使用 Visual Studio 2012 在 Windows 窗体中创建的。

谢谢！

Answer 1

我建议你随机选择一个小样本（20 行）并尝试重新组织它。 这会让你知道它需要多长时间（如果你乘法），并且不会被低估，因为样本的随机性实际上会使工作稍微复杂一些。 也可以做两三次，看看方差是否小。 任何其他不基于您的方法可能会在时间上更便宜，但不会产生适合您的结果。 在我看来，这种方法是一项不错的投资。

Answer 2

首先，这是一个估计 - 估计不是精确的数字，它们是近似值和范围。一旦你开始进入它，你一开始的估计可能会大大偏离，并且需要改进估计。估价时考虑code of uncertainty。

存在许多完善的软件估计模型。 COCOMO II 就是其中之一。我相信这种特殊方法为其技术增加了价值，因为它可以在已知数量的基础上发挥作用。

COCOMO II 的网络工具可以在usc 找到。数一数你现在拥有的代码行数。估算一下您需要多少行新的 cmets，有多少可以重复使用，有多少需要修改。插入这些数字。COCOMO II 工作原理的定义和所有术语都可以在usc ftp site

中找到

假设您有一个 10k SLOC 现有代码，其中 75% 可以重用，25% 需要修改（75% 设计修改，100% 代码修改......），另外 10% 用于注释。有支持和反对调整各种成本驱动因素的论据（改变“名义”或保持原样）。

插入此插件，您将获得相当于 2825 SLOC 的大小，然后转换为 9.2 个人月的工作量（请记住，这不仅仅是逐行浏览代码 - 还要确保重新设计正确且测试它）。九个月大约是 1500 个工作小时。

考虑获取Software Estimation: Demystifying the Black Art，它涉及估算的更多方面以及进行估算的其他技术（这是通过代理进行的估算，只是众多技术中的一种）。

请记住保存有关花费多长时间和您的估计的数据 - 随着时间的推移，历史数据可以帮助改进估计。

进一步阅读维基百科Cost estimation in software engineering

Answer 3

您也许可以通过使用某种code analysis 来发现令人讨厌的位，该code analysis 向您展示了类的复杂性。

检查不是covered by unit test 的代码也将帮助您找到更难重构的代码。

Answer 4

就注释代码而言，大概意味着阅读每一行并描述每个方法/有趣的部分？忽略所有关于这个的通常辩论，首先，你有我的同情，其次，我建议选择一些课程，做这项工作，并测量需要多长时间：你应该能够从那里推断（并加上 30 % 之后）

至于重组，除非您已经知道需要进行某些特定的大规模重构，否则我通常对“需要多长时间”的回答是“您希望它变得更好多少？” - 最终的答案始终是一个您和老板/客户都同意的有时间限制的金额。提出 x 天的建议，并在这段时间内尽你所能做好。另外，有人提到集成测试：如果这是一个可行的选择，那么它肯定有助于控制时间