Трудности при разработке сложных распределённых систем на Java. презентация

научить разрабатывать проект «from scratch».
Основная цель выступления - Познакомить аудиторию с реальным опытом разработки большого JAVA приложения.
Познакомить с применяемыми принципами анализа требований
Рассказать подходе к управлению требованиями
Использование системы хранения версий.
Познакомить с реальной жизнью в проектах. Рассказать о своём опыте.

Термины. Определения
«Большая система».
Подсистема.

в целом
Компоненты из которых будет состоять приложение
Функции которые будут выполнять компоненты
Как компоненты будут взаимодействовать между собой

Правильный анализ – залог будущего вашего проекта

приложения – глобальные и локальные переменные, настройки
Deployment strategy (including tools)
Функции которые будут выполнять компоненты
Как компоненты будут взаимодействовать между собой
Доступ к данным – DataBase, в файлах, внешние системы
Схема работы с исключительными ситуациями.
Принципы логирования
Взаимодействие с пользователем, определение общего подхода
Data validation

First application Second application
Не скатываться к - «Целое состоит из частей»


1. Общий код переносится из одной
части системы в другую
2. Группировка сущностей в пакет
3. Выделение общего функционала в отдельные пакеты
Пакет как отдельная подсистема-проект.

Одно принятое решение = один фактор влияния


Technical debt
Business pressure
Lack of process or understanding
Lack of building loosely components
Lack of design/project documentation
Feature parallel development
Delayed refactoring.
Laziness of project staff.

оптимизации
Запросы к DB. Скорость получения результата.
Необходимость изменения структуры DB
Анализ алгоритмов обработки данных
Оптимизация –, есть ли необходимость оптимизировать структуру DB, алгоритмы обработки данных (оптимальная работа алгоритмов)
Масштабирование
Вертикальное – увеличение ресурсов в рамках одного узла.
Горизонтальное – добавление новых узлов.
Закон Амдала
В случае, когда задача разделяется на несколько частей,
суммарное время её выполнения на параллельной системе не
может быть меньше времени выполнения самого длинного фрагмента

по планированию
3. Разделение
одной большой задачи
на группу мелких задач

подсистем, как самостоятельных проектов.

выяснение действительного статуса работ.
Несвоевременное принятие решений по проекту. Потеря времени может оказать негативное влияние на проект в целом.

Способы решения
Формулировка в отчёте по задаче должна отвечать на вопрос - Что сделал? Какой результат?
Детальное описание результата.
Единое время посылки отчётов для всех инженеров.

100 человек.
Исходный код, который содержит несколько миллионов строк.

Почему AccuRev
Необходимость обеспечить сложную разветвлённую структуру версий разрабатываемого продукта
Регламентированные роли доступа – инженеры различных категорий, лидеры групп, QA инженеры, релиз инженеры.
Обеспечение различных уровней доступа к коду для разных категорий специалистов.

Особенности работы
Нет привычных терминов tag, branch, trunk.
Оригинальная терминология. Каждый новый сотрудник должен пройти небольшой вводный курс.

в проекте с помощью Contour

Цели
Добавить новый функционал
Добавить новую возможность
Изменить существующий бизнес процесс.
Внести изменения в

различных бизнес процессов.
Бизнес аналитик со стороны исполнителя проекта
Архитекторы
Представители отдела R&D (Research and Development)

Формулировка требования с точки зрения аналитика.
Пример:
Система должна логировать действия пользователя при изменениях в реестре товаров.

операции изменения реестра должны содержать атрибут «Исполнитель»
Добавить журнал изменений. Просмотр журнала изменений.

Формулировка задачи для разработчиков
Задача 123 – разработать Журнал изменений
Добавить атрибуты ID пользователя (Long userId;) и текст изменения (String changeMessage;)
При внесении изменения в реестр создавать запись в журнале изменений.

Формулировка задачи для тестировщиков. Тестовый сценарий.
Войти в систему под тестовым пользователем, который имеет право на изменение в реестре товаров.
Произвести изменение в реестре.
Убедиться, что изменение отражено в журнале изменений.

Работа началась……..

STOP


Заказчик снова меняет требования после начала работ.
Производить запись в журнал изменения, которые касаются только добавления новых позиций в реестр.

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

Как следствие – потеря времени на установление истины.

документов.
Синхронизация.

Преимущества использование Contour
Все требования и изменения к ним публикуются в Contour.
Уникальные идентификаторы для каждого документа. Поддержка связей между документами.
Всем участникам проекта доступна одинаковые версии документов. Описание требований, тест планы.
Просмотр истории изменений.
Уведомление. Каждый разработчик и тестировщик, которые работают над разработкой конкретной feature получает уведомление о внесённых изменениях.

Функциональное требование

ресурсов для промежуточного и финального тестирования.



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

features.

команд из разных часовых поясов

Нижний Новгород

США

Transfer meeting

Email transfer