Java >> Java tutorial >  >> Tag >> switch

Omkostningerne ved kontekstskift

Jeg har altid troet, at jeg er god til at multitasking. Det er grunden til, at jeg troede på, at jeg ikke skulle betale den pris, der er forbundet med kontekstskift (eller opgaveskift).

I denne uge indså jeg, at det var forkert. Jeg er ikke særlig god til multitasking, og kontekstskifte er meget dyrere, end jeg troede.

Årsagen til min fejl er enkel:

Jeg var ikke blevet afbrudt nær så ofte, som jeg troede .

Hvorfor er kontekstskift så dyrt?

Virkningerne af kontekstskift er smerteligt velkendte for mig:

  • Hvis jeg arbejder på noget, og jeg skal i gang med at lave noget andet, kan det tage evigheder, før jeg rent faktisk arbejder på den nye opgave.
  • Fordi jeg skal skifte kontekst flere gange om dagen, føler jeg, at jeg ikke kan få noget gjort (ofte er dette ikke kun en følelse).

Joel Spolsky forklarer årsagen til dette:

Tricket her er, at når du administrerer programmører, specifikt tager opgaveskift rigtig, rigtig, rigtig lang tid. Det er fordi programmering er den slags opgave, hvor du skal have mange ting i hovedet på én gang. Jo flere ting du husker på én gang, jo mere produktiv er du til at programmere. En programmør, der koder for fuld gas, holder zillioner af ting i hovedet på én gang:alt fra navne på variabler, datastrukturer, vigtige API'er, navnene på hjælpefunktioner, som de skrev og kalder meget, selv navnet på den undermappe, hvor de gemme deres kildekode. Hvis du sender den programmør til Kreta på tre ugers ferie, vil de glemme det hele. Den menneskelige hjerne ser ud til at flytte den ud af kortvarig RAM og skifter den ud på et backup-bånd, hvor det tager evigheder at hente.

Det interessante er, at prisen på kontekstskift ikke er konstant. Det afhænger af kompleksiteten af ​​den nye opgave.

Hvis den nye opgave er så enkel, at selv en abe kan klare den, er prisen meget lille. Typisk kan jeg bare afslutte den nye opgave og fortsætte med at arbejde på den gamle opgave uden at miste tid. Grunden til dette er, at jeg ikke behøver at rydde min korttidshukommelse, fordi den nye opgave er så enkel.

På den anden side, hvis den nye opgave ikke er triviel, er prisen meget høj. Jeg er nødt til at rense min korttidshukommelse og indlæse de oplysninger, jeg skal bruge for at afslutte en ny opgave. Efter jeg er færdig med den nye opgave, skal jeg rense min korttidshukommelse og indlæse den information, der er relevant for min oprindelige opgave. Jeg skal med andre ord betale prisen to gange!

Hvor stor er prisen på kontekstskifte? Jeg antager, at dette afhænger af personen, men jeg har bemærket, at det kan være alt fra 5 til 30 minutter pr. kontekstskift. Det er sindssygt, for hvis du skal skifte kontekst flere gange om dagen, spilder du en masse tid og forbruger en masse mental energi .

Sådan finder du mellemgrunden

Fordi kontekstskifte har en høj pris, og det er mentalt drænende, bør vi undgå det for enhver pris. Dette er dog lettere sagt end gjort, fordi "rigtigt" teamarbejde (agile metoder) er en væsentlig del af moderne softwareudvikling, og jeg tror, ​​at det har klare fordele, som ikke bør overses.

Med andre ord, vi skal finde mellemvejen mellem samarbejde og tunge løft .

Vi skal respektere vores egen tid og vores teammedlemmers tid, og den nemmeste måde at gøre dette på er at følge disse regler:

  • Gør én ting ad gangen . Hvis du skal afslutte to opgaver, skal du afslutte den vigtigste, før du starter den anden. På denne måde kan du afslutte i det mindste den vigtigste opgave. Hvis du prøver at afslutte begge opgaver, kan du muligvis ikke afslutte nogen af ​​dem.
  • Brug asynkron kommunikation . Næste gang du har et spørgsmål, må du ikke afbryde den person, der kan svare på dit spørgsmål. I stedet bør du bruge asynkrone kommunikationsværktøjer såsom IM, e-mail eller et andet samarbejdsværktøj. På denne måde kan personen svare på dit spørgsmål, når han har tid til at gøre det. Gør det også klart, at dine teammedlemmer skal behandle dig på samme måde. Hvis lortet rammer blæseren, medmindre dit spørgsmål ikke bliver besvaret med det samme, kan du afbryde den person, der kan hjælpe dig, men husk, at denne person betaler en høj pris for at svare på dit spørgsmål .
  • Sørg for, at du ikke bliver afbrudt, hvis du har brug for at få noget gjort . Hvis du arbejder med en vigtig opgave, skal du have mulighed for at afslutte den uden afbrydelser. Skab en måde at signalere til dine kolleger, at du ikke ønsker at blive afbrudt. Hvis dine kolleger ikke respekterer dette, kan du arbejde på dit hjemmekontor, indtil du er færdig med denne opgave. Husk også, at dette er en tovejsvej.
  • Accepter, at du ikke kan gøre alt, og sørg for, at din arbejdsgiver også accepterer dette . Hvis din rolle er at hjælpe andre udviklere på en regelmæssig basis, skal du ikke have det dårligt, fordi du føler, at du ikke kan få noget gjort. Sørg for, at du ikke tager nogen højt prioriterede opgaver, fordi du ikke kan give dem den opmærksomhed, de fortjener.

Nogle af disse råd kan virke anti-agile. Problemet er, at fremkomsten af ​​agile softwareudviklingsmetoder har skabt et mentalt billede, som tilskynder os til at samarbejde hele tiden. Dette mentale billede vil ødelægge vores produktivitet, og vi bør ikke omfavne det .

I stedet bør vi acceptere, at der er tid til samarbejde og tid til at gøre det tunge løft , og vi kan ikke gøre dem begge på samme tid (medmindre vi laver parprogrammering eller mob-programmering).


No
Java tag