Bästa praxis för storskaliga Kopplingar

Vi definierar en storskalig connector-strategi som en som producerar över 5000 arbetsenheter i Bureau Works per synkroniseringsförfrågan. En arbetsenhet i Bureau Works är en kombination av en fil + arbetsflödessteg + språkpar. Så ett projekt med 5 filer, 2 arbetsflödessteg (översättning + granskning) och 5 språk kommer att resultera i 50 arbetsenheter. Du kan se hur det inte är så svårt att gå över 5000 arbetsenheter när du börjar multiplicera dessa variabler. Det är frestande att vilja centralisera allt i ett enda projekt, men vår erfarenhet visar att med storskaliga kopplingar är det bäst att gruppera projekt efter språkpar. Detta kan verka som en enkel fråga om hur du väljer att definiera ett projekt, men det går mycket djupare än så. I den här artikeln kommer vi att dissekera effekterna av detta beslut i termer av:

1. Meddelandeförmedling
2. Problemlösning
3. Riskminimering
4. Köer/prestanda
5. Automatiseringspotential
6. Enkel hantering
7. Skalbarhet

Meddelandeförmedling1) Meddelandehantering växer exponentiellt med storskaliga kopplingar. Vi har sett kopplingar som skapar över 1 miljon meddelanden per synkroniseringsförfrågan. Detta resulterar i enorm serveraktivitet och prestandaproblem som kan mildras genom att dela upp projekt per lokal. Problemlösning2) Detta är direkt kopplat till riskminimering. Men vid lokalisering ser vi ofta problem som är begränsade till en viss lokal och hur det påverkar tolkningen, segmenteringen och för-/efterbehandlingen av en given uppsättning filer. Genom att dela upp mellan lokaler kan du Skapa lokalspecifika RegularExpressions, bearbetningsregler och segmentering som ger mycket mer flexibilitet när det gäller den övergripande arkitekturen. Snarare än att arbeta begränsat med lösningar som fungerar överallt, kan du iterera baserat på lokal och slutligen nå ett mer moget samt förutsägbart beteendemönster när du arbetar baserat på lokaler. Riskminimering3) Genom att dela upp projekt i ett per lokal kommer du att minska hanteringsrisker eftersom om något går fel i en given lokal betyder det inte att hela pull-request/leveransmekanismen är komprometterad. Du kan isolera och dela upp problem på ett naturligt sätt. Detta kanske inte verkar vara en grej under SOP, men när oväntade problem dyker upp (och det gör de alltid när det gäller lokalisering) kommer du att vara tacksam för att du har byggt ett tegelhus i stället för ett som är gjort av hö. Köer/prestanda4) I stället för att till exempel rada upp 150 000 element för bearbetning kan du rada upp 15 000 element tio gånger. Återigen, detta verkar inte vara en stor skillnad eftersom du i slutändan måste bearbeta samma 150 000 element, men att ha flexibiliteten att bearbeta seriellt vs. parallellt eller opportunistiskt efter önskemål ger dig så mycket mer flexibilitet samt prestandakapacitet. Automatiseringspotential 5) Typiskt sett kommer projektbeslut och arbetsflöden att vara asymmetriska över olika platser. Att separera projekt per lokal ger dig mycket större flexibilitet när det gäller automatiseringspotential på lång sikt. Du kan ha ett scenario där du har helt olika parametrar såväl som datamängder när du separerar per lokal istället för att konsolidera alla element tillsammans.Management6) Denna är också kontraintuitiv. Ur ett ledningsperspektiv är konsolidering vanligtvis den bästa metoden för bättre styrning. Men i storskaliga kopplingar är det motsatta sant. Ett projekt kommer naturligt att filtreras per lokal, vilket gör det möjligt för olika projektledare att äga olika delar av projektet mer enkelt, minska användningen av filter för att generera rapporter och skapa större enkelhet när det gäller att spåra vad som händer per lokal. Skalbarhet7) Med storskaliga kopplingar kommer du att nå en punkt där det helt enkelt blir ohanterligt att skala genom att gruppera alla arbetsenheter tillsammans i ett enda projekt. Genom att separera sätter du ramarna för ett program som är lättare att skala upp långsiktigt. Kom ihåg att saker och ting multipliceras när det gäller arbetsenheter och meddelanden. Genom att separera per plats eliminerar du en av de stora multiplikationsvariablerna, vilket gör att du kan skala upp mycket lättare. Slutsats Det finns en illusion om att konsolidering är bättre. En pull-request per projekt gör allas liv enklare. Även om det stämmer för småskaliga kopplingar, faller det isär i storskaliga. Vårt mål är alltid att leverera de mest eleganta och pålitliga Lösningar till våra klienter och vi har sett om och om igen att med storskaliga situationer är dela och erövra vägen att gå.

Konsolidering i ett enda projektSeparering per lokalHela projektet har en 0 eller 1 statusStatus kan stratifieras per lokalSingulär parsning, filtrering och RegEx-ramverkFlexibelt ramverk per lokalEnkelspårig köhantering per projektFlexibel köhantering och bearbetning som naturligt distribuerar bearbetningFiltrering per lokal inom projektetEtt mindre filtreringsstegAutomatiseringsregler som fungerar överalltLokal specifika automatiseringsparametrar och dataAlla ägg i en korg ur ett riskperspektivRisk distribuerad över lokalerKomplext att isolera och felsökaEn mindre stor variabel som gör det lättare att felsöka