Перейти к основному содержимому

tracker2elastic

Общее описание проекта​

Проект "tracker2elastic" представляет собой систему для обработки данных из трекеров задач (например, Redmine) и их последующей отправки в Elasticsearch. Это серверное решение, основанное на Django, предназначенное для автоматизации и упрощения обработки проектной информации, изменений статусов задач и времени, затраченного на задачи.

Описание модулей проекта​

  1. activity2elastic: Модуль для обработки активностей из трекеров задач. Включает функции для сбора изменений статусов задач и их отправки в Elasticsearch.

  2. spent2elastic: Модуль для обработки информации о затраченном времени по задачам. Предназначен для сбора данных о времени, затраченном на задачи, и отправки их в Elasticsearch.

  3. common utils: Вспомогательные утилиты, общие для всех модулей, включая функции для работы с Elasticsearch и обработки ответов от трекеров задач.

  4. models и migrations: Определения моделей данных Django и миграции для настройки проекта и его базы данных.

  5. views и templates: Веб-интерфейс для управления процессом обработки и отправки данных, включая формы для задания параметров обработки.

Общая логика работы системы​

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

Интеграции с внешними системами​

  1. Трекеры задач (например, Redmine): Получение данных о задачах, их статусах и времени, затраченном на эти задачи.

  2. Elasticsearch: Отправка обработанных данных для хранения и анализа. Используется для агрегации и визуализации данных в удобном для анализа формате.

Действия в системе​

  1. activity2elastic_processing: Обработка активностей и их отправка в Elasticsearch.
  2. spent2elastic_processing: Обработка информации о затраченном времени и её отправка в Elasticsearch.
  3. process_statuses: Обработка статусов задач.
  4. get_time_spents: Получение информации о затраченном времени.
  5. get_issue_data_for_time_spents: Получение данных о задачах на основе информации о затраченном времени.
  6. collect_status_changes: Сбор изменений статусов задач.
  7. calculate_durations: Расчёт длительности статусов задач.
  8. send_data_to_elastic: Отправка данных в Elasticsearch.

Сценарий использования​

Рассмотрим реальный сценарий использования системы в IT-компании. Предположим, что компания использует систему управления задачами (например, Redmine) для отслеживания прогресса своих проектов. Сотрудники регулярно обновляют статусы задач и записывают время, затраченное на каждую задачу.

Система "tracker2elastic" будет использоваться для автоматической обработки этой информации. Например, каждый день система может автоматически собирать данные о статусах задач (действие "activity2elastic_processing") и информацию о затраченном времени (действие "spent2elastic_processing"). Затем эти данные отправляются в Elasticsearch, где они агрегируются и анализируются. Это позволяет руководителям проектов эффективно отслеживать прогресс работы, а также анализировать производительность команды и отдельных сотрудников.

Таким образом, "tracker2elastic" обеспечивает автоматизацию сбора и анализа рабочих данных, упрощая управление проектами и повышая их прозрачность.

Модель данных​

  1. Activity (Активность):

    • id: Уникальный идентификатор активности.
    • issue_id: Идентификатор задачи, с которой связана активность.
    • user_id: Идентификатор пользователя, выполняющего активность.
    • activity_type: Тип активности (например, обновление статуса).
    • created_at: Дата и время создания активности.
    • updated_at: Дата и время последнего обновления активности.

  2. TimeSpent (Затраченное время):

    • id: Уникальный идентификатор записи о затраченном времени.
    • issue_id: Идентификатор задачи, на которую затрачено время.
    • user_id: Идентификатор пользователя, затратившего время.
    • hours: Количество часов, затраченных на задачу.
    • date: Дата, на которую приходится затраченное время.

  3. Issue (Задача):

    • id: Уникальный идентификатор задачи.
    • project_id: Идентификатор проекта, к которому относится задача.
    • status: Текущий статус задачи.
    • created_at: Дата и время создания задачи.
    • updated_at: Дата и время последнего обновления задачи.

  4. User (Пользователь):

    • id: Уникальный идентификатор пользователя.
    • username: Имя пользователя.
    • email: Электронная почта пользователя.
    • created_at: Дата и время создания пользователя.
    • updated_at: Дата и время последнего обновления пользователя.

Диаграмма состояний​

  1. activity2elastic_processing: Обработка активностей для Elastic.
  2. activity2elastic_processing_internal: Внутренняя обработка активностей для Elastic.
  3. activity2elastic_impl: Реализация обработки активностей для Elastic.
  4. process_statuses: Обработка статусов.
  5. get_activities: Получение активностей.

Эта диаграмма состояний иллюстрирует последовательность действий в системе начиная от начала обработки активностей до получения активностей и завершения обработки.

Анализ кода проекта​

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

  1. Стиль и структура кода:

    • В некоторых местах кода присутствует избыточная вложенность, что затрудняет чтение и понимание кода. Например, в функции activity2elastic_processing_internal используются многоуровневые циклы и условные операторы, что делает код сложным для понимания.

      def activity2elastic_processing_internal(...):
          for activity in activities:
              if condition:
                  for item in items:
                      # дальнейшая логика

    • Рекомендация: Рефакторинг для уменьшения вложенности, возможно, с использованием отдельных функций для обработки каждого уровня.

  2. Именование переменных и функций:

    • В некоторых случаях имена переменных и функций могут быть более описательными. Например, get_data или check_response не полностью отражают их предназначение и контекст использования.

      def get_data(...):
          # логика функции

    • Рекомендация: Использовать более специфичные имена, которые отражают назначение функции или переменной.

  3. Обработка ошибок:

    • В некоторых частях кода отсутствует достаточно детализированная обработка исключений. Например, использование общего except Exception без конкретизации типа исключения.

      try:
          # код
      except Exception as e:
          # обработка исключения

    • Рекомендация: Использовать более конкретные классы исключений для точной обработки ожидаемых ошибок.

  4. Использование внешних библиотек:

    • В коде используются библиотеки, такие как requests, без явного управления сессиями, что может привести к неэффективному использованию ресурсов при многократных запросах.

    • Рекомендация: Использовать сессии requests.Session() для оптимизации сетевых запросов.

  5. Модульность и расширяемость:

    • Код мог бы быть более модульным, что облегчило бы добавление новых функций и интеграций в будущем.
    • Рекомендация: Разделение кода на более мелкие, независимые модули или классы.

Оценка времени и оценка кода​

  • Оценка времени: Для опытной команды разработчиков написание такого проекта могло бы занять около 60-100 часов. Это включает в себя время на планирование, разработку, тестирование и рефакторинг.
  • Оценка кода: По 10-балльной шкале я бы оценил данный код на 6/10. Основные причины - недостаточная модульность и потенциальные улучшения в стиле кода и обработке исключений.