Question

我正在寻找一种方法来标记可以优化的代码，以便我或在项目之后跟随我的任何人知道在性能成为挑战时可以优化什么以及如何优化。

根据我和许多其他人的经验（例如，检查Joshua Block的“Effective Java Programming”），我现在不进行优化的原因是代码清晰度大多数时候比代码优化更重要。因此，我更喜欢保持代码清晰易懂（这基本上意味着，按照任何人的方式实现事情，在真正需要之前不要尝试任何花哨的东西）。但是，当性能成为问题时，最好确切地知道在哪里查看并以代码清晰度为代价进行优化。我希望能够标记代码可以优化的地方，并提供一些如何提示。

我想这样做的方法是使用如下注释：

public class UserDao {
    @Optimizable (hint="cache returned data; ")
    public List<User> getUsers(int userType) {
        //some code getting user and checking if user is of that type.
    }
}

是否有标准 - 社区广泛使用 - 标记代码的方式？或者你更了解如何做到这一点？

使用注释可以让工具轻松检查可优化的代码并为其生成一些报告。另一种方法可能是使用类似javadoc的标记，但不确定工具能够轻松发现它。

谢谢，燕姿。

增加：

好的，似乎Rick的回答涵盖了评论中所有这些做法。虽然注释怎么样？我发现这有一些优势，因为您可以发现代码问题/优化选项，即使您没有源代码并通过为这些方法/类提供新实现并利用多态来进行优化。你知道是否有这样的标准注释吗？

Answer 1

是：使用// TODO: Some comment

Eclipse，IntelliJ，NetBeans都认识到这一点并为您创建“待办事项”列表。许多代码质量插件和CI服务器，例如Jenkins（以前是哈德森）也认识到这一点，可以创建“技术债务”报告和进度图等。

确保使用完全相同的语法：// TODO:

Answer 2

我知道这是一个旧线程，但仅供将来参考：有一个@Debt注释可用于指示有一些代码需要重构/更新/修复。有关详细信息，请参阅：http://kenai.com/projects/csdutilities/pages/Debt。还有与Maven的集成可用于为您提供更多信息，如果有许多@Debt注释，可能会使构建失败。

Answer 3

我在评论中了解了三个标准标签：

TODO：下一个版本的非关键问题;用于优化
XXX：关键问题，但代码正在运行;需要在下次发布之前查看
FIXME：关键问题，非工作代码;这标志着真正的错误

TODO和FIXME众所周知并在上面讨论过。

XXX通常用于在当前状态下工作但需要删除的部分。这些通常是在短时间内修复错误的丑陋黑客，强耦合代码假定强大的环境条件可能会发生变化，而且代码已知可行，但被认为是不稳定的。

Answer 4

我不知道这样的标签。只要在整个代码中始终如一地使用它，就可以创建一些东西。

我可以看到这样一个标签的价值。通常天真，慢速代码比复杂，快速的代码更可取，因为它编写速度更快，更容易出现错误。当客户抱怨速度时，你想重新审视天真的，慢的位并搜索预先写好的评论使这更容易。

以下是一些想法：

// OPT: Here is a potential optimization; it's ambiguous with "optional".
// OPTIMIZATION: a long tag.
// LHF: Low hanging fruit. Not intuitive, but the acronym is cool.
// FASTER: This is a real word, six letters long.
// BOOST: Another real word, five letters.

我认为我更喜欢第一个// OPT:。

e.g。

// OPT: This report can be re-written with PL/SQL, but 
// you'll need to use JDBC rather than Hibernate.

或

// OPT: Adding a bloom filter in front of this structure will half
// the number of disk accesses.

标记/注释可以优化的代码的标准方法？

增加：

4 个答案: