стандартный способ пометить / аннотировать код, который можно оптимизировать?

Question

Я ищу способ как-то пометить код, который можно оптимизировать, чтобы я или любой, кто придет за мной в проект, знал, что и как можно оптимизировать, когда производительность становится проблемой.

Причина, по которой я не оптимизирую в данный момент, заключается в том, что ясность кода в большинстве случаев важнее, чем оптимизация кода, основываясь на моем и многом другом опыте (например, проверьте «Эффективное программирование на Java» Джошуа Блока). Поэтому я предпочитаю, чтобы код был ясным и легким для понимания (что в основном означает, реализуйте вещи так, как это сделал бы любой, не пытайтесь делать какие-то фантастические вещи, пока они действительно не понадобятся). Хотя, когда производительность становится проблемой, полезно точно знать, где искать и выполнять оптимизации за счет потери из-за ясности кода. Я хотел бы иметь возможность пометить места, где код может быть оптимизирован, и дать несколько советов о том, как.

Я думал об этом, используя аннотацию вроде:

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, но не уверен, насколько легко инструмент сможет это обнаружить.

Спасибо, Стеф.

ДОБАВЛЕНО:

Хорошо, похоже, что ответ Рика охватывает все способы сделать это в комментариях. Как насчет аннотаций, хотя? Я считаю, что это имеет некоторые преимущества, поскольку вы можете обнаружить проблемы с кодом / варианты оптимизации, даже если у вас нет исходного кода и вы оптимизируете, предлагая новую реализацию для этих методов / классов и используя преимущества полиморфизма. Знаете ли вы, есть ли какие-либо стандартные аннотации для таких?

Answer 1

Да: используйте // TODO: Some comment

Eclipse, IntelliJ, NetBeans все распознают это и создают список «задач» для вас.Многие плагины качества кода и CI-серверы, например, Jenkins (ранее Hudson) также распознают это и могут создавать отчеты о "технической задолженности", графики прогресса и т. Д.

Убедитесь, что вы используете именно такой синтаксис: // TODO:

Answer 2

Я знаю, что это старый поток, но только для справки в будущем: есть аннотация @Debt, которую можно использовать, чтобы указать, что есть некоторый код, который нуждается в рефакторинге / обновлении / исправлении.Смотрите: http://kenai.com/projects/csdutilities/pages/Debt для получения дополнительной информации.Также доступна интеграция с Maven, чтобы предоставить вам дополнительную информацию и, возможно, сделать сборку неудачной, если имеется много аннотаций @Debt.

Answer 3

Я не знаю такого тега.Вы можете что-то придумать, если вы используете это последовательно во всем коде.

Я вижу значение такого тега.Часто наивный, медленный код предпочтительнее сложного, быстрого кода, так как он быстрее пишется и, скорее всего, не содержит ошибок.Когда клиент жалуется на скорость, вы хотите вернуться к наивным, медленным битам, и поиск предварительно написанных комментариев облегчает это.

Вот несколько идей:

// 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:.

например

// 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.

Answer 4

Я знаю о трех стандартных тегах в комментариях:

• TODO: некритическая проблема для следующего выпуска;используется для оптимизации
• XXX: критическая проблема, но код работает;нужно посмотреть перед следующим выпуском
• FIXME: критическая проблема, нерабочий код;это отмечает реальные ошибки

TODO и FIXME хорошо известны и обсуждены выше.

XXX обычно используется для секций, которые работают в текущем состоянии, но должны быть удалены.Как правило, это уродливые хаки для исправления ошибки за короткий период, сильно связанный код, который предполагает сильные условия среды, которые могут измениться, и код, который, как известно, работает, но предполагается, что он нестабилен.