Рекомендации / идеи для облегчения поддержки приложений - PullRequest
3 голосов
/ 11 июня 2011

Написание программного обеспечения хорошего качества должно быть первым шагом. На данный момент это своего рода движущаяся цель. (У нас есть нечто вроде https://stackoverflow.com/questions/3716203/automatic-code-quality-and-architecture-quality-static-code-analysis.. У нас также есть набор регрессионных тестов и среда тестирования, аналогичная некоторым избранным клиентам.) Что бы мы ни делали, бывают случаи, когда только клиент видит и получает сбой / ошибку. Иногда у них просто проблемы с производительностью. Иногда происходит сбой, иногда ошибка объектной модели приложения.

Как я могу уменьшить боль? Как я могу получить большинство (данные) из такой ситуации? Какие шаги кодирования / архитектуры могут помочь получить больше информации, когда проблема возникает в первый раз и во второй раз?

Вот отправные точки:

Хорошее ведение журнала: log4j является отправной точкой. Пользователь должен иметь возможность легко изменить файл. Предоставление небольшого графического интерфейса для редактирования такого файла будет еще лучше. (наша конфигурация регистрации находилась в области c: / Program Files / в Windows 7; редактирование, которое не является простым для обычных пользователей - требует волшебной опции «запуск от имени администратора».).

Дамп кучи: Дамп кучи при нехватке памяти.

Автоматическое представление отчетов об ошибках: Хороший пример - Firefox, intellij и т. Д. Не уверен, что для этого есть готовая библиотека.

JMX: Для серверных приложений это кажется очень полезным. Я никогда не использовал это.

Инструмент для определения системных требований: Я еще этого не сделал.

Возможность автоматического обновления:

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

Ответы [ 2 ]

1 голос
/ 11 июня 2011

Несколько предложений:

  1. Хорошее обеспечение качества перед развертыванием продуктов для клиентов, включая тестирование производительности и нагрузки.
  2. Достаточное / соответствующее ведение журнала на стороне клиента и сервера для диагностикипроблемы, когда они возникают.
  3. Обучение (бета) клиентов методам написания ошибок.Это может включать сбор информации о выпуске из справки |О, включая точные шаги для воспроизведения проблемы, скриншоты и информацию журнала.Диагностировать проблему намного сложнее, когда отчеты неполные.
  4. Многие проблемы связаны с данными и требуют копирования данных клиента для воспроизведения.Если возможно, поддерживайте тестовые среды, которые включают данные / конфигурацию клиента.
1 голос
/ 11 июня 2011

Для серверных приложений рассмотрите инструмент, подобный Dynatrace (несвободный, но хороший), чтобы получить представление о вашем коде в реальном времени.

Не совсем соответствует вашему вопросу, но в целом попробуйте найти ошибки, прежде чем они попадут в GA, с помощью таких инструментов, как FindBugs и Sonar .

Я не знаю библиотеки автоматической отправки ошибок, но быстрый веб-сервис RESTfull было бы легко создать очень ценный.

Извините, это не слишком полный ответ, но несколько битов, которые я подобрал за эти годы.

...