Software-udviklings-workflows

Software-udviklere bruger flowcharts til at designe systemer, dokumentere API'er, planlægge deployment-pipelines og kommunikere teknisk arkitektur. Denne vejledning lærer udvikler-specifikke flowcharting-mønstre med praktiske eksempler, du kan bruge med det samme.

Hvad du lærer

• Oprettelse af API request/response flowcharts
• Dokumentering af autentificerings- og autorisationsflows
• Kortlægning af deployment-pipelines og CI/CD-workflows
• Repræsentation af asynkrone operationer
• Fejlhåndtering og retry-logic mønstre
• Microservices-kommunikationsdiagrammer
• Database-transaktionsflows
• Kode-til-flowchart-kortlægning-teknikker

Forudsætninger

• Software-udviklingserfaring
• Grundlæggende flowchart-viden
• Forståelse af Bedste praksis
• 30-40 minutter

Eksempel 1: REST API Request Flow

Lad os oprette et omfattende flowchart for et REST API-endpoint, der håndterer brugerprofil-opdateringer.

Scenarie

Endpoint: PUT /api/users/{userId}/profile

Formål: Opdater brugerprofilinformation med autentificering, validering og database-persistence

Teknisk stack:

• Express.js API
• JWT-autentificering
• PostgreSQL-database
• Redis cache
• S3 til fillagring

Trin 1: Opret API-flow-strukturen

1. Opret et nyt flowchart: "API - Opdater brugerprofil"

2. Tilføj indgangspunktet:

   • Start/Slut: "HTTP PUT /api/users/:id"

3. Tilføj autentificeringslag:

   • Process: "Udtræk JWT-token fra headers"
   • Beslutning: "Token til stede?"
     • Nej → Process: "Return 401 Unauthorized" → Slut
     • Ja → Fortsæt

4. Tilføj token-validering:

   • Process: "Verificer JWT-signatur"
   • Beslutning: "Token gyldigt?"
     • Nej → Process: "Return 401 Invalid Token" → Slut
     • Ja → Fortsæt

5. Tilføj autorisation:

   • Process: "Udtræk bruger-ID fra token"
   • Beslutning: "Token bruger-ID matcher anmodnings-bruger-ID?"
     • Nej → Process: "Return 403 Forbidden" → Slut
     • Ja → Fortsæt

Trin 2: Tilføj request-behandling

6. Input-validering:

   • Process: "Parse request body"
   • Process: "Valider request-skema"
   • Beslutning: "Gyldig anmodning?"
     • Nej → Process: "Return 400 Bad Request med fejl" → Slut
     • Ja → Fortsæt

7. Forretningslogik-validering:

   • Process: "Tjek e-mail-unikhed"
   • Beslutning: "E-mail tilgængelig?"
     • Nej → Process: "Return 409 Conflict - E-mail findes" → Slut
     • Ja → Fortsæt

Trin 3: Tilføj database-operationer

8. Database-transaktion:

   • Process: "Begynd database-transaktion"
   • Database: "Forespørg nuværende brugerpost"
   • Beslutning: "Bruger fundet?"
     • Nej → Process: "Rollback transaktion" → "Return 404 Not Found" → Slut
     • Ja → Fortsæt

9. Opdateringsoperationer:

   • Database: "UPDATE users SET ... WHERE id = ?"
   • Beslutning: "Opdatering succesfuld?"
     • Nej → Process: "Rollback transaktion" → "Return 500 Database fejl" → Slut
     • Ja → Fortsæt

10. Commit og finaliser:

    • Process: "Commit transaktion"
    • Database: "Invalider bruger-cache i Redis"
    • Process: "Return 200 OK med opdateret bruger" → Slut

Komplet API-flow-mønster

Start: HTTP PUT /api/users/:id
  ↓
Udtræk JWT-token (Process)
  ↓
Token til stede? (Beslutning)
  ├→ Nej → Return 401 Unauthorized → Slut
  └→ Ja → Verificer JWT-signatur
              ↓
            Token gyldigt? (Beslutning)
              ├→ Nej → Return 401 Invalid Token → Slut
              └→ Ja → Udtræk bruger-ID fra token
                          ↓
                        Bruger-ID matcher? (Beslutning)
                          ├→ Nej → Return 403 Forbidden → Slut
                          └→ Ja → Parse request body
                                      ↓
                                    Valider skema
                                      ↓
                                    Gyldigt? (Beslutning)
                                      ├→ Nej → Return 400 Bad Request → Slut
                                      └→ Ja → Tjek e-mail-unikhed (Database)
                                                  ↓
                                                E-mail tilgængelig? (Beslutning)
                                                  ├→ Nej → Return 409 Conflict → Slut
                                                  └→ Ja → Begynd transaktion (Database)
                                                              ↓
                                                            Forespørg bruger (Database)
                                                              ↓
                                                            Bruger fundet? (Beslutning)
                                                              ├→ Nej → Rollback → Return 404 → Slut
                                                              └→ Ja → Opdater bruger (Database)
                                                                          ↓
                                                                        Opdatering succesfuld? (Beslutning)
                                                                          ├→ Nej → Rollback → Return 500 → Slut
                                                                          └→ Ja → Commit transaktion
                                                                                      ↓
                                                                                    Invalider cache (Database)
                                                                                      ↓
                                                                                    Return 200 OK → Slut

Eksempel 2: Autentificeringsflow med JWT

Lad os kortlægge et komplet autentificeringssystem med login, token-refresh og logout.

Login-flow

1. Bruger-login-anmodning:

   • Start: "POST /api/auth/login"
   • Data I/O: "Modtag legitimationsoplysninger (e-mail, adgangskode)"
   • Process: "Valider request-skema"
   • Beslutning: "Gyldigt format?"
     • Nej → Return 400 → Slut
     • Ja → Fortsæt

2. Brugerverifikation:

   • Database: "Forespørg bruger efter e-mail"
   • Beslutning: "Bruger fundet?"
     • Nej → Process: "Return 401 Ugyldige legitimationsoplysninger" → Slut
     • Ja → Fortsæt
   • Process: "Sammenlign adgangskode-hash med bcrypt"
   • Beslutning: "Adgangskode matcher?"
     • Nej → Database: "Log mislykket login-forsøg" → Return 401 → Slut
     • Ja → Fortsæt

3. Konto-statustjek:

   • Beslutning: "Konto aktiv?"
     • Nej → Return 403 Konto deaktiveret → Slut
     • Ja → Fortsæt
   • Beslutning: "E-mail verificeret?"
     • Nej → Return 403 Verificer e-mail → Slut
     • Ja → Fortsæt

4. Token-generering:

   • Process: "Generer access-token (JWT, 15min udløb)"
   • Process: "Generer refresh-token (JWT, 7 dage udløb)"
   • Database: "Gem refresh-token-hash i database"
   • Database: "Opdater sidste login-tidsstempel"
   • Process: "Return tokens + brugerdata" → Slut

Token-refresh-flow

1. Refresh-anmodning:

   • Start: "POST /api/auth/refresh"
   • Process: "Udtræk refresh-token fra anmodning"
   • Beslutning: "Token til stede?"
     • Nej → Return 401 → Slut
     • Ja → Fortsæt

2. Token-validering:

   • Process: "Verificer refresh-token-signatur"
   • Beslutning: "Signatur gyldig?"
     • Nej → Return 401 Ugyldigt token → Slut
     • Ja → Fortsæt
   • Beslutning: "Token ikke udløbet?"
     • Nej → Return 401 Token udløbet → Slut
     • Ja → Fortsæt

3. Database-verifikation:

   • Process: "Udtræk bruger-ID fra token"
   • Database: "Forespørg gemt refresh-token"
   • Beslutning: "Token findes i database?"
     • Nej → Return 401 Token tilbagekaldt → Slut
     • Ja → Fortsæt

4. Ny token-generering:

   • Process: "Generer nyt access-token"
   • Process: "Generer nyt refresh-token"
   • Database: "Opdater gemt refresh-token"
   • Process: "Return nye tokens" → Slut

Logout-flow

1. Logout-anmodning:
   • Start: "POST /api/auth/logout"
   • Process: "Udtræk refresh-token"
   • Database: "Slet refresh-token fra database"
   • Database: "Tilføj access-token til blacklist (Redis, TTL = token-udløb)"
   • Process: "Return 200 OK" → Slut

Eksempel 3: CI/CD Deployment Pipeline

Dokumenter din deployment-proces fra kode-commit til produktion.

Pipeline-stadier

1. Trigger:

   • Start: "Git Push til Main Branch"
   • Process: "GitHub Webhook trigger CI"

2. Build-stadie:

   • Process: "Checkout kode"
   • Process: "Installer dependencies (npm ci)"
   • Process: "Kør TypeScript-kompilering"
   • Beslutning: "Build succesfuldt?"
     • Nej → Process: "Notificer team (Slack)" → Slut
     • Ja → Fortsæt

3. Test-stadie:

   • Process: "Kør unit tests (Jest)"
   • Beslutning: "Tests består?"
     • Nej → Notificer team → Slut
     • Ja → Fortsæt
   • Process: "Kør integrationstests"
   • Beslutning: "Tests består?"
     • Nej → Notificer team → Slut
     • Ja → Fortsæt

4. Sikkerhedsscanning:

   • Process: "Kør dependency audit (npm audit)"
   • Beslutning: "Kritiske sårbarheder?"
     • Ja → Notificer team → Slut
     • Nej → Fortsæt
   • Process: "Kør SAST (statisk analyse)"
   • Beslutning: "Sikkerhedsproblemer?"
     • Ja → Notificer team → Slut
     • Nej → Fortsæt

5. Build artifacts:

   • Process: "Build Docker-image"
   • Process: "Tag image med Git commit SHA"
   • Process: "Push til container registry"

6. Staging deployment:

   • Process: "Deploy til staging-miljø"
   • Process: "Kør smoke tests"
   • Beslutning: "Smoke tests består?"
     • Nej → Rollback → Notificer team → Slut
     • Ja → Fortsæt
   • Process: "Kør E2E tests (Playwright)"
   • Beslutning: "E2E tests består?"
     • Nej → Rollback → Notificer team → Slut
     • Ja → Fortsæt

7. Produktionsgodkendelse:

   • Beslutning: "Auto-deploy til produktion?"
     • Nej → Process: "Vent på manuel godkendelse" → Beslutning: "Godkendt?"
       • Nej → Slut
       • Ja → Fortsæt
     • Ja → Fortsæt

8. Produktions-deployment:

   • Process: "Deploy til produktion (Blue-Green)"
   • Process: "Kør helbredstjek"
   • Beslutning: "Helbredstjek består?"
     • Nej → Process: "Automatisk rollback" → Notificer team → Slut
     • Ja → Fortsæt
   • Process: "Skift trafik til ny version"
   • Process: "Monitor metrikker (5 minutter)"
   • Beslutning: "Fejlrate normal?"
     • Nej → Automatisk rollback → Notificer team → Slut
     • Ja → Fortsæt

9. Finaliser:

   • Process: "Notificer team - Deploy succes"
   • Process: "Opret release-noter"
   • Database: "Registrer deployment i revisionslog"
   • Slut: "Deployment fuldført"

Eksempel 4: Asynkron job-behandling

Kortlæg baggrundsjob-behandling med køer og workers.

Baggrundsjob-system

1. Job-oprettelse:

   • Start: "API-anmodning: Behandl stor fil"
   • Process: "Valider fil-upload"
   • Process: "Gem fil til S3"
   • Process: "Opret job-post i database"
   • Process: "Placer job i Redis-kø"
   • Process: "Return job-ID til klient (202 Accepted)" → Slut (API)

2. Parallel worker-proces:

   • Start: "Worker: Poll kø"
   • Beslutning: "Job tilgængelig?"
     • Nej → Process: "Vent 5 sekunder" → Tilbage til Poll
     • Ja → Fortsæt
   • Process: "Dequeue job"
   • Database: "Opdater job-status til 'Behandler'"

3. Job-behandling:

   • Process: "Download fil fra S3"
   • Process: "Behandl fil (chunks)"
   • Beslutning: "Behandling succesfuld?"
     • Nej → Håndter fejl (nedenfor)
     • Ja → Fortsæt

4. Succes-sti:

   • Process: "Upload resultater til S3"
   • Database: "Opdater job-status til 'Fuldført'"
   • Process: "Send webhook-notifikation"
   • Database: "Placer oprydningsjob i kø"
   • Slut: "Job fuldført"

5. Fejlhåndtering:

   • Database: "Increment retry-tæller"
   • Beslutning: "Retry-tæller < 3?"
     • Ja → Process: "Placer i kø igen med eksponentiel backoff" → Slut
     • Nej → Fortsæt
   • Database: "Opdater job-status til 'Mislykket'"
   • Process: "Send fejl-notifikation"
   • Database: "Log fejldetaljer"
   • Slut: "Job mislykket"

Tjek job-status (separat flow)

1. Status-tjek:
   • Start: "GET /api/jobs/"
   • Database: "Forespørg job-post"
   • Beslutning: "Job fundet?"
     • Nej → Return 404 → Slut
     • Ja → Fortsæt
   • Process: "Return job-status (pending/processing/complete/failed)"
   • Slut

Eksempel 5: Microservices-kommunikation

Dokumenter inter-service-kommunikationsmønstre.

Synkront REST-kald-mønster

Service A: Behandl ordre
  ↓
HTTP-kald: GET /api/inventory/check
  ↓
Service B: Lager-service
  ↓
Forespørg database (Database)
  ↓
Return lagerniveau
  ↓
Service A: Modtag svar
  ↓
Lager tilgængeligt? (Beslutning)
  ├→ Nej → Return 409 Ikke på lager → Slut
  └→ Ja → Fortsæt ordrebehandling

Asynkront event-drevet mønster

1. Event-udgiver (Service A):

   • Process: "Ordre oprettet"
   • Process: "Publicer 'OrderCreated'-event til message bus"
   • Slut

2. Event-forbruger (Service B - Lager):

   • Start: "Abonner på 'OrderCreated'-events"
   • Process: "Modtag event"
   • Process: "Reduc er lagerantal"
   • Database: "Opdater lager-database"
   • Process: "Publicer 'InventoryUpdated'-event"
   • Slut

3. Event-forbruger (Service C - Notifikation):

   • Start: "Abonner på 'OrderCreated'-events"
   • Process: "Modtag event"
   • Process: "Send bekræftelses-e-mail"
   • Slut

Saga-mønster (distribueret transaktion)

Dokumenter kompenserende transaktioner til fejl:

Start: Opret ordre-saga
  ↓
Service A: Reserver lager
  ↓
Succes? (Beslutning)
  ├→ Nej → Afslut saga (mislykket)
  └→ Ja → Service B: Behandl betaling
              ↓
            Succes? (Beslutning)
              ├→ Nej → Kompenser: Frigiv lager → Afslut saga (mislykket)
              └→ Ja → Service C: Planlæg forsendelse
                          ↓
                        Succes? (Beslutning)
                          ├→ Nej → Kompenser: Refunder betaling
                          |       ↓
                          |     Kompenser: Frigiv lager
                          |       ↓
                          |     Afslut saga (mislykket)
                          └→ Ja → Commit saga (succes) → Slut

Teknisk shape-brugsguide

Hvornår skal man bruge hver shape

Shape	Software-kontekst	Eksempler
Process	Enhver beregning eller operation	"Hash adgangskode", "Parse JSON", "Beregn total"
Decision	Betinget logik	"Bruger autoriseret?", "Response status 200?", "Retry?"
Data I/O	Eksternt input/output	"Modtag HTTP-anmodning", "Return svar", "Læs fil"
Database	Data-persistence-operationer	"Forespørg brugere", "Gem post", "Opdater cache"
Document	Filoperationer	"Generer PDF", "Skriv logfil", "Eksporter CSV"
Cloud	Eksterne service-kald	"S3 upload", "API-kald", "E-mail-service"
Delay	Timeouts og venten	"Vent 30 sekunder", "Retry efter 5s", "Rate limit"

Kode-til-flowchart-kortlægning

Kode-blok:

async function updateUser(userId: string, data: UpdateUserDTO) {
  // Valider input
  if (!isValid(data)) {
    throw new ValidationError("Ugyldige data");
  }

  // Tjek tilladelser
  if (!hasPermission(userId)) {
    throw new ForbiddenError("Ingen tilladelse");
  }

  // Opdater database
  const user = await db.users.update({
    where: { id: userId },
    data: data
  });

  // Invalider cache
  await cache.delete(`user:${userId}`);

  return user;
}

Flowchart:

Start: updateUser(userId, data)
  ↓
Valider input (Process)
  ↓
Gyldigt? (Beslutning)
  ├→ Nej → Throw ValidationError → Slut
  └→ Ja → Tjek tilladelser
              ↓
            Har tilladelse? (Beslutning)
              ├→ Nej → Throw ForbiddenError → Slut
              └→ Ja → Opdater brugerpost (Database)
                          ↓
                        Slet cache-entry (Database)
                          ↓
                        Return bruger → Slut

Fejlhåndteringsmønstre

Retry med eksponentiel backoff

Start: API-kald
  ↓
Forsøg API-anmodning (Process)
  ↓
Succes? (Beslutning)
  ├→ Ja → Return resultat → Slut
  └→ Nej → Increment retry-tæller
              ↓
            Retry-tæller <= 3? (Beslutning)
              ├→ Nej → Throw fejl → Slut
              └→ Ja → Beregn backoff (2^retry * 1000ms)
                          ↓
                        Vent (Delay)
                          ↓
                        (Tilbage til Forsøg API-anmodning)

Circuit breaker-mønster

Start: Service-kald
  ↓
Tjek circuit-tilstand (Beslutning)
  ├→ Åben → Return cached/standard-svar → Slut
  ├→ Halv-åben → Forsøg anmodning
  |               ↓
  |             Succes? (Beslutning)
  |               ├→ Ja → Luk circuit → Return svar → Slut
  |               └→ Nej → Åbn circuit → Return fejl → Slut
  └→ Lukket → Forsøg anmodning
                  ↓
                Succes? (Beslutning)
                  ├→ Ja → Return svar → Slut
                  └→ Nej → Increment fejltæller
                              ↓
                            Fejl >= tærskel? (Beslutning)
                              ├→ Ja → Åbn circuit → Return fejl → Slut
                              └→ Nej → Return fejl → Slut

Graceful degradation

Start: Feature-anmodning
  ↓
Prøv primær service
  ↓
Succes? (Beslutning)
  ├→ Ja → Return fuld feature → Slut
  └→ Nej → Prøv sekundær service
              ↓
            Succes? (Beslutning)
              ├→ Ja → Return delvis feature → Slut
              └→ Nej → Return cached data
                          ↓
                        Cache tilgængelig? (Beslutning)
                          ├→ Ja → Return forældet data → Slut
                          └→ Nej → Return standard/fejl → Slut

Database-transaktionsmønstre

Optimistisk låsning

Start: Opdater post
  ↓
Læs nuværende post + version (Database)
  ↓
Modificer post lokalt (Process)
  ↓
Opdater WHERE id = X AND version = Y (Database)
  ↓
Rækker påvirket > 0? (Beslutning)
  ├→ Ja → Commit → Slut
  └→ Nej → Post ændret af anden proces
              ↓
            Retry? (Beslutning)
              ├→ Ja → (Tilbage til Læs nuværende post)
              └→ Nej → Throw ConcurrencyError → Slut

Two-phase commit

Start: Distribueret transaktion
  ↓
Fase 1: Forbered
  ↓
Send forbered til alle deltagere
  ↓
Alle deltagere klar? (Beslutning)
  ├→ Nej → Send abort til alle → Rollback → Slut
  └→ Ja → Fase 2: Commit
              ↓
            Send commit til alle deltagere
              ↓
            Alle committed? (Beslutning)
              ├→ Nej → Send rollback til mislykkede → Log fejl → Slut
              └→ Ja → Transaktion fuldført → Slut

Pro-tips til software-workflows

Almindelige anvendelser

1. API-dokumentation

Generer flowcharts for alle offentlige API-endpoints, der viser request-validering, autentificering, forretningslogik og svar.

2. Onboarding af nye udviklere

Opret flowcharts af komplekse systemer for at hjælpe nye teammedlemmer med at forstå arkitektur hurtigere end at læse kode.

3. System-design-interviews

Brug flowcharts til at forklare din tilgang til distribuerede systemer, caching-strategier og skalerbarhedsløsninger.

4. Incident-respons

Dokumenter incident-respons-procedurer med klare flowcharts, der viser eskaleringstier og remediationstrin.

5. Kode-review-diskussioner

Opret flowcharts under design-reviews for at tilpasse teamet, før der skrives kode.

6. Tekniske specifikationer

Inkluder flowcharts i tekniske specifikationer for at supplere skriftlige beskrivelser af systemadfærd.

Næste skridt

1. Dokumenter dine API'er - Opret flowcharts for dine mest brugte API-endpoints
2. Kortlæg din deploy-proces - Dokumenter CI/CD-pipeline til dit team
3. Opret arkitekturdiagrammer - Kortlæg microservices-interaktioner
4. Byg mønsterbibliotek - Opret genanvendelige flowchart-mønstre til almindelige operationer
5. Integrer med kode - Gem flowcharts i dit repository sammen med kode

Relateret dokumentation

• Guide til bedste praksis - Professionelle flowcharting-standarder
• Forretningsproces-vejledning - Ikke-teknisk proces-kortlægning
• Shape-reference - Komplet guide til alle shapes
• Eksportmuligheder - Inkluder flowcharts i teknisk dokumentation
• Skabelonbibliotek - Præbyggede software-workflow-skabeloner

---

Start med at diagrammere din kode i dag! Veldokumenterede systemer er nemmere at vedligeholde, skalere og onboarde nye udviklere. Brug flowcharts til at gøre din tekniske arkitektur klar for alle på dit team.