Understrukna ord finns i lektionsordlistan. Tryck på ett ord för att se alla översättningar. Lägg till eller redigera ord i messages/glossary.json (alla språknycklar du lägger till visas i rutan).
Coding, debugging, and design
Design and planning of features
Låt oss börja med att spåna fram några möjliga tekniska lösningar på det här problemet.
Vi bör absolut bygga en enkel MVP (Minimum Viable Product) först innan vi lägger till mer.
Hur ska vi strukturera datamodellen i databasen för att det här ska fungera optimalt?
Jag tycker vi ska väga fördelarna och nackdelarna med båda alternativen innan vi bestämmer oss.
Ett av de största problemen med din lösning är att den nog inte skalar särskilt bra i framtiden.
En klar fördel med att använda det här molnbaserade verktyget är att vi sparar väldigt mycket tid.
Hur ska vi smidigast hantera extrema undantagsfall (edge cases) i den här komplexa funktionen?
Ska vi rita upp ett snabbt flödesschema på tavlan för att visualisera hur användaren rör sig?
Det är väldigt viktigt att vi tar höjd för säkerhetsaspekterna redan från dag ett i designen.
Vilken typ av API är egentligen bäst lämpat för det här, REST, GraphQL eller gRPC?
Vi måste planera hur vi ska klara av en framtida migrering av all den befintliga datan.
Låt oss tänka igenom hur gränssnittet ska fungera för användare med nedsatt syn (tillgänglighet).
Jag föreslår att vi delar upp den stora funktionen i tre mindre, mer hanterbara iterationer.
Ska vi bygga detta från grunden, eller finns det ett bra färdigt bibliotek (open source) vi kan använda?
Hur snabbt förväntar vi oss egentligen att den här funktionen ska svara för slutanvändaren?
Det finns en stor risk att det här kommer påverka hela systemets prestanda negativt.
Vi måste säkerställa att lösningen vi väljer följer företagets strikta riktlinjer och kodstandard.
Skulle vi kunna sätta upp ett snabbt 'proof of concept' (PoC) nästa vecka för att bevisa att idén håller?
Vi behöver nog fundera mer på hur vi hanterar användare som tappar sin nätverksuppkoppling.
Kan vi skapa en detaljerad skiss (wireframe) över hur den nya dashboarden ska se ut?
Det är viktigt att hela arkitekturen är extremt feltolerant och hanterar bortfall av servrar.
Vi bör designa funktionen på ett sätt så att den enkelt kan stängas av med en feature flag.
Hur ska vi lagra lösenorden? Vi måste självklart salta och hasha dem korrekt.
Jag gillar verkligen den minimalistiska och rena designen som UX-teamet har tagit fram här.
Hur gör vi applikationen offline-first så att den fungerar i alla lägen för användaren?
Jag tycker att vi borde fokusera på 'mobile first' eftersom majoriteten av våra användare surfar från mobilen.
Finns det ett sätt att cacha den här tunga datan så att vi inte belastar databasen så extremt mycket?
Vi måste planera in hur den automatiska utrullningen (deployment) av funktionen ska fungera.
Jag tror tyvärr vi underskattar hur svårt det faktiskt är att integrera med det där urgamla systemet.
En stor nackdel med det där spåret är att vi binder upp oss helt och hållet till en specifik leverantör.
Ska vi använda relationsdatabaser eller en dokumentdatabas för just den här ostrukturerade datan?
Vi måste komma överens om exakt vilket format API:et ska returnera datan i, gärna i förväg.
Detta kommer tyvärr att kräva förändringar i både frontend, backend och i själva databasen.
Låt oss ta ett djupt andetag och försöka hålla det så otroligt enkelt som möjligt (KISS-principen).
Vi måste definiera extremt tydliga acceptanskriterier innan vi ens rör vid tangentbordet.
Designen ser otroligt snygg ut, men hur interaktiv och animerad ska funktionen faktiskt vara?
Vi bör nog planera in en extra buffert i tidsschemat för de oförutsedda tekniska problemen.
Kan vi förutspå några allvarliga flaskhalsar i den föreslagna arkitekturen redan nu?
Vi måste definitivt lägga mycket tid på hur felmeddelanden ska presenteras snyggt för slutanvändaren.
Ska vi använda synkron eller asynkron kommunikation mellan de här två mikrotjänsterna?
Jag känner att vi svävar iväg lite (scope creep), låt oss fokusera på kärnproblemet först.
Vilka specifika mätvärden (metrics) behöver vi spåra för att veta om funktionen blev en succé?
Designmönstret vi diskuterar nu passar helt perfekt för de krav vi nyss gick igenom.
Bör vi inte planera in en ordentlig QA-period för manuell testning innan vi lanserar skarpt?
Det är en extremt smart arkitektur, men är den verkligen motiverad för vår lilla kundbas?
Vi måste säkerställa att plattformen är byggd för att klara de enorma trafiktopparna under julhandeln.
Kan vi bryta ut denna specifika del i en serverless-funktion för att spara pengar och resurser?
Vad händer rent logiskt i systemet om användaren inte godkänner våra allmänna villkor?
Jag tror faktiskt att den här designen kommer att bli oerhört intuitiv och smidig för kunderna.
Tack för en grym brainstorming-session, jag sätter ihop ett tekniskt förslag baserat på detta direkt.
