Важные вещи, которые следует иметь в виду, перед проверкой кода в Java - PullRequest
2 голосов
/ 31 июля 2010

Я только что создал веб-приложение среднего размера, используя Java, пользовательский MVC-фреймворк, javascript. Мой код будет проверен, прежде чем он будет помещен на серверы производства (для внутреннего использования).

Основная цель создания этого приложения состояла в том, чтобы решить небольшую проблему для внутреннего использования и понять пользовательскую среду MVC, используемую моим работодателем. Итак, мое приложение прошло МНОГО итераций, изменений функций и дополнений.

Итак, суть в том, что код очень грязный, и это мое первое Java-приложение "уровня продукта".

Каковы ваши предложения, какие основные проверки / рефракторы я должен сделать перед проверкой кода?

Я думаю о:

  1. Лучшие практики Java (соглашения)

  2. Сделайте код простым для понимания разработчиком, который будет его поддерживать. (не буду я)

  3. Я заметил, что создал несколько ненужных объектов и использовал hashmaps / arraylists, где мог бы легко использовать какую-то другую структуру данных и достичь решения. Так стоит ли это менять?

Обновление

Ваш код отстой, а я вас ненавижу: социальная динамика обзоров кода

Ответы [ 4 ]

2 голосов
/ 31 июля 2010

Если вы этого еще не сделали (при условии, что вы используете IDE, например, eclipse)

  • получить плагины checkstyle и findbugs
  • просмотрите их конфигурацию и настройтесь на свой стиль
  • запустите их на вашем коде
  • решить все обнаруженные проблемы

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

Посмотрите на структуру кода:

  • получить плагин jdepend
  • исследовать структуру вашего пакета

Код против интерфейсов (Map, List, Set) вместо классов реализации (HashMap, ArrayList, TreeSet)

Заполните свой Javadoc и проверьте его актуальность после всех рефакторингов.

Добавить тесты JUnit; если у вас нет времени для тестирования всего приложения, по крайней мере, создайте тест для каждой ошибки, которую вы найдете и решите с этого момента. Это помогает «наращивать» набор тестов по ходу работы.

В следующий раз спроектируйте и создайте ваше приложение с конечной целью. Всегда предполагайте, что следующий парень, который будет поддерживать ваш код, будет знать, как вас найти: -)

2 голосов
/ 31 июля 2010

Юнит-тесты, и они должны быть автоматизированы как часть вашей сборки. У вас уже должно быть это, но если нет, сделайте это сейчас. Это определенно облегчит рефакторинг, а также улучшит ваше общее доверие к коду (и парню, который будет его поддерживать).

1 голос
/ 31 июля 2010

Прокомментируйте свой код, объясните, почему он делает то, что делает, и какие предположения были сделаны.

Попробуйте уменьшить количество мутирующих состояний.

Попробуйте удалить любые синглеты, которые у вас могут быть.

1 голос
/ 31 июля 2010

Logging.

Одной из наиболее важных вещей является важность ведения журнала. Вы должны иметь приличную методологию ведения журнала. Несмотря на то, что это внутреннее приложение, убедитесь, что основные журналы могут помочь обычным пользователям найти проблемы и предоставить более подробное ведение журнала, чтобы вы (разработчик) знали, куда идти.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...