Практическо ръководство · R, Shiny и индивидуален софтуер
Поемане на съществуващо R или Shiny приложение
Поемането на R или Shiny приложение започва с възпроизводима база и разбиране на аналитичната му цел. Опишете системата, възпроизведете представителни резултати, изследвайте разликите и договорете поддръжката преди промените. Пренаписването е възможно решение, а не начална предпоставка.
Leap Dynamics GmbHАктуализирано:
1. Опишете приложението и отговорностите
Съберете разрешен достъп до кода, пакетни зависимости, R версии, интерфейси към данни, периодични задачи, удостоверяване, конфигурация за разполагане и документация. Определете хората, които разбират резултатите, и отговорниците за инфраструктурата.
Отделяйте известните дефекти от желаните подобрения. Недокументирано поведение може да е умишлено, остаряло или грешно; текущият изход сам не решава това.
2. Възпроизведете представителна база
Изпълнете одобрени примери в изолирана среда и запазете таблиците, файловете и значимото поведение. Запишете липсващи зависимости или външни услуги, които пречат на възпроизвеждането.
Инструменти като renv описват зависимостите на R пакетите. Файлът за фиксиране на версии е полезен, но сам не възпроизвежда бази данни, системни библиотеки, тайни или поведение на операционната система. Документирайте и тези зависимости.
3. Тествайте същественото поведение
Използвайте фокусирани автоматични тестове, например testthat, заедно с преглед от специалисти. При промяна на резултат изследвайте причината и документирайте дали това е предвидена корекция или регресия.
| Слой | Полезни проверки |
|---|---|
| Аналитична логика | Известни примери, гранични условия, липсващи стойности и договорени числови сравнения. |
| Интерфейси към данни | Промени в схемата, празни резултати, откази и очаквани трансформации. |
| Shiny взаимодействие | Важни потребителски пътища, реактивни зависимости и изтегляне на отчети. |
| Разполагане | Повторяем старт, конфигурация, възстановяване и работещо връщане към предишна версия. |
4. Изберете поддръжка, модернизация или нова реализация
Насочени поправки и документация могат да решат непосредствената нужда. Рефакториране, обновяване на зависимости и подобрения в производителността постепенно улесняват поддръжката. Миграция или пренаписване изискват техническа и бизнес обосновка, включително усилието за повторно потвърждаване на резултатите.
Приоритизирайте задачите със собственика на приложението. Определете поддържани компоненти, условия за реакция, одобряване на промени и отговорности за версии. Софтуерната поддръжка и постоянната експлоатация на инфраструктура са различни отговорности и се договарят изрично.
5. Предайте приложим запис на поемането
Leap Dynamics може да ограничи тази оценка като самостоятелна задача и да използва резултата за договаряне на конкретна поддръжка или разработка.
- Инвентар на код и зависимости с документирана база.
- Известни проблеми, тестови резултати и сравнения на изходите.
- Приоритети, отговорности и обхват на поддръжката.
- Инструкции за разполагане, възстановяване и предаване.