Innhold

• Prosjektledelse på Facebook - Why Scrum> Waterfall
• Å finne balanse
• Versjonskontroll og sjonglering
• Fanger feil i tide
• Kraftige verktøy for automatisering og tvinge multiplikasjon
• Lukkende tanker

Nylig besøkte jeg Facebook-hovedkvarteret i London for å lære om prosessen med å utvikle og vedlikeholde sin mobile Facebook-app. Mye mer skjer her enn du antagelig er klar over: noen av Facebooks apper blir håndtert her i sin helhet, for eksempel WhatsApp for desktop og den forretningsorienterte Workplace-appen.

Kontorene er akkurat det du forventer av Facebooks bilde, men kanskje ikke helt til sosiale nivåer av overflødig. Dette er et sted hvor seriøst arbeid blir gjort, men det er en trendy, finurlig og avslappet atmosfære likevel. Ansatte kan ta med bærbare datamaskiner for å jobbe uansett hvor de velger, det er et utskriftsrom for å lage plakater (bare fordi), bestilte kunstverk på flere av veggene og en gigantisk Ninja Turtle - jeg har aldri fått svar på hvorfor.

Oh, og maten er utrolig. Jeg var der i løpet av kinesisk nyttår og det hadde jeg flere svinekjøtt. Gode ​​tider.

Imidlertid var jeg ikke der for å glede meg over innredningen og kjøkkenet, jeg var der for å lære om Facebook på mobil. Mer spesifikt: hvordan i all verden går du til og med å opprettholde et prosjekt så stort og ambisiøst? Facebook-backenden betjener over to milliarder mennesker, og Android-appen ser alene en ny versjon utgitt hver uke.

Hvordan administrerer du en app med et så ambisiøst antall funksjoner

Jeg snakket med Tal Kellner via Facebooks eget telepresenssystem. Tal er en teknisk programleder, med ansvar for Release Engineering Team basert på Tel Avivs ingeniørkontor. Hun var mer enn glad for å dele de pusete detaljene.

Tal og teamet hennes lastet opp Lite-versjonen av Facebook til iOS for første gang

Det jeg lærte var ganske fascinerende både fra utviklerperspektiv og som bruker. Dette er hva jeg fant ut.

Prosjektledelse på Facebook - Why Scrum> Waterfall

Når du ser på et stort prosjekt, må du ta hensyn til prosjektledelsesmetoden din. Et slikt eksempel kalles "fossefall" prosjektledelse. Dette er en sekvensiell og lineær tilnærming der du jobber med en spesifikk fase etter tur, som å gå fra forestillinger til implementering til testing til utgivelse.

selskaper som Facebook velger i stedet for en mer moderne tilnærming til prosjektledelse kalt "scrum"

Avgjørende, i denne tilnærmingen begynner du ikke neste fase før den forrige fasen er fullført. Systemet stammer fra produksjonen, der visse stadier ofte er avhengige av forrige trinn: du må kilde murstein før du kan bygge en vegg!

Når det gjelder programvare, er denne tilnærmingen begrensende. I verste fall kan en oppdatering ta så lang tid å rulle ut, den er foreldet når den kommer. Duke Nukem For alltid noen?

Dermed velger noen programvareselskaper i stedet for en mer moderne tilnærming kalt "scrum", som er en smidig metodikk. Denne metoden prioriterer arbeidet som betyr mest og deler det opp i modulære biter. Det er avhengig av kommunikasjon mellom interne avdelinger og til og med enkeltagenter som jobber alene på sine egne hjørner av kode.

I teorien er resultatet at alle kan jobbe med det som er mest presserende for dem hele tiden, og at alle andre deler av virksomheten vet hva de gjør. Det er et høyt eierskapsnivå for hver ingeniør, og alle er til syvende og sist ansvarlige for sitt eget arbeid. Ikke bare gjør dette selskapet mer smidig, men det forhåpentligvis også økt arbeidsglede. Ingen er bare en tannhjul i maskinen.

alle fra hvor som helst i organisasjonen kan foreslå en idé til en ny funksjon

Jeg var veldig imponert over å høre at alle fra hvor som helst i organisasjonen kunne foreslå en ide for en ny funksjon, og så komme til å jobbe med det hvis det gis klarsignal. Noen ganger kan dette til og med utvikle seg til sin egen separate app! Facebook er mye mer et samarbeidsprosjekt enn den nedenfra håndhevede visjonen til noen få personer (eller en person) det ofte blir fremstilt som.

Dette gjør at Facebook kan implementere en overordentlig rask utviklingssyklus, som muliggjør en ny mobiloppdatering hver uke, og tusenvis av forpliktelser (foreslåtte kodeendringer) mellom da. Hvis du synes det er imponerende, oppdateres nettversjonen (bakenden som også tjener mobilappen) en gang annenhver til tredje time!

Facebook er generelt veldig støttende for nye ideer og oppstart. Den har til og med et initiativ kalt LDN LAB viet til å støtte nye ideer og bedrifter.

Å finne balanse

Hentet fra Tals egne lysbilder

Selvfølgelig vil det fremdeles alltid være en grense når det gjelder hva et selskap kan håndtere. Med så mye kode er det alltid rom for forbedringer, men det må komme en tid hvor versjonen blir ansett som "god nok."

Det er her den "gyldne trekanten" spiller inn. Denne trekantens tre punkter representerer funksjoner, kvalitet og tid. Hvert selskap har et valg å gjøre her: prioriterer du nye funksjoner når det kommer til crunch-tid på bekostning av å ta litt lengre tid? Tillater du en mindre eksisterende feil å gli gjennom nettet hvis det betyr at du kan legge til flere funksjoner? Når du ikke kan gjøre alt, blir du tvunget til å prioritere.

Hos Facebook er prioriteringene kvalitet og tid. Hvis en oppdatering faller bak det tildelte vinduet, vil en funksjon sannsynligvis bli dyttet tilbake; i stedet for at et hjørne blir kuttet eller oppdateringen blir forsinket.

Versjonskontroll og sjonglering

For å håndtere disse oppdateringene og endringene i koden bruker Facebook sin egen modifiserte versjon av Mercurial. Det er i stedet for den veldig brukte Git, som tilsynelatende ikke skalerte så godt for selskapets formål. Phabricator tilsvarer GitHub, og bruker mye plugins for å effektivisere arbeidsflyten og noen ganger bare for å gjøre ting litt morsommere (Facebook liker at memene tilsynelatende har det).

For ikke-programmererne der ute, er Mercurial, i likhet med Git, et versjonskontrollsystem. Det lar et stort antall mennesker jobbe med et enkelt stykke programvare, og gjøre endringer og fikser uten å sette hovedprogramversjonen, som kalles "hovedgrenen", i fare. Disse verktøyene hjelper til med å forhindre kodekonflikter og gir mulighet for eksperimentering. Først når en endring er godkjent på en testgren, blir den forpliktet til masteren.

Se for deg om noen stakkars programmerer laget en skrivefeil som knuste hele koden, og det bare var en versjon! Det ville være en dårlig dag for alle.

Verktøy som Mercurial gjør det mulig å implementere skrumtilnærmingen på en relativt enkel måte, og lar alle jobbe med spesifikke funksjoner og feil samtidig før de slås sammen i en stor pott.

En gang i uken vil en utgivelseskandidat bli kuttet fra masteren, og denne vil deretter gå gjennom testfasen. Kodere som har brukt hele uken på å jobbe med feilrettinger eller nye funksjoner, vil på dette tidspunktet krysse fingrene i håp om at arbeidet deres gjør det til den nye oppdateringen.

Eventuelle fikser eller endringer som gjøres av teammedlemmer i siste øyeblikk, krever at de blir "kirsebærplukket" for inkludering i den nye grenen av de ansvarlige. Det har vært kjent at de har brukt bestikkelser i form av sjokolade og alkohol som er begavet til beslutningstakerne.

For å kompilere bruker Facebook et annet verktøy som heter Buck. Dette enkeltbyggingsverktøyet kan bygge hva som helst når det kommer til pakking av appen. Det er ikke behov for separate alternativer som Gradle eller maur når du målretter deg mot forskjellige plattformer.

Fanger feil i tide

Når alle jobber med forskjellige ting, og så mange oppdateringer som regelmessig går ut, er det veldig viktig at selskaper sørger for at programvaren deres fungerer og ikke har noen alvorlige feil. For det meste har Facebook en ganske god oversikt over å holde ting i gang.

For det formål deler teamet programvaretesting i nivåer, referert til som C1, C2 og C3.

C1 er intern testing og alle ansatte vil kjøre den versjonen. Under C2 går versjonen gjennom 2 prosent av allmennheten, og C3 er produksjon. Skulle noe virkelig alvorlig bli funnet, vil hver ansatt kunne få tilgang til en nødstoppknapp for å stoppe produksjonen.

De frivillige som presenterer seg for å holde trinnene fremgang, går under navnet "tree huggers" (fordi grener), og gjør dette på toppen av vanlige jobber.

På mobil kalles lignende lag alfa, beta og prod. Alpha betyr en intern test, som alle ansatte vil kjøre. Prosessen med ethvert selskap som bruker egne produkter på denne måten kalles "dogfooding" - fra "å spise din egen hundemat."

Testere har også noen unike og interessante verktøy for å raskt rapportere feil. Den ene er “Rageshake”, der det å riste enheten i frustrasjon muliggjør en feilrapport, som med Google Maps.

Testere har også noen unike og interessante verktøy for å raskt rapportere feil

Under alfa - som effektivt refererer til eventuell intern testing - bruker Facebook også automatisk testing for å kjøre appen. For eksempel fungerer en nylig skaffet programvare som heter “Sapienz” i det vesentlige ved å klikke på hver knapp og bruke hver funksjon i et tilfeldig angrep til det utløser et brak. Deretter logger du stapelsporen, registrerer handlingen og rapporterer tilbake.

Beta-appen (versjonen testet av allmennheten) går gjennom et lite underavsnitt (~ 2 prosent) av allmennheten. Dette lille utdraget vil motta oppdateringen på forhånd, og gi Facebook tilbakemeldinger fra virkeligheten. Hvis alt virker bra, går oppdateringen ut til hele befolkningen, og prosessen begynner på nytt.

Kraftige verktøy for automatisering og tvinge multiplikasjon

For å holde hele prosessen så rask og så smidig som mulig, bruker Facebook et stort antall forskjellige verktøy. Vi har allerede sett hvordan selskapet bruker Phabricator og Sapienz, men det har andre verktøy og plugins for andre stadier.

Et verktøy som heter Picknic samler alle trekkforespørslene (endringer som ansatte har gjort) på ett sted for rask og enkel gjennomgang.

Når testing kaster opp en feil, informerer en bot som heter Nagbot de ansvarlige og gir dem forsiktig til å få arbeidet gjort. Å bruke en rudimentær AI for å håndtere denne prosessen sikrer ikke bare arbeidet blir gjort, men lar også lederen unngå å være den "dårlige fyren" ved å hele tiden pirre!

Når testing kaster opp en feil for noen å fikse, informerer en bot som heter Nagbot de ansvarlige og gir dem forsiktig til å få gjort arbeidet

Crashbot er en annen bot ansvarlig for å rapportere disse feilene når de skjer, og er å foretrekke fremfor beregninger fra Google Console, i og med at den rapporterer i sanntid. Crashbot vil flagge opp et problem når problemene overskrider en "akseptabel krasjgrense." Dette kan skyldes antall personer som opplever feilen, eller antallet ganger en enkelt bruker har fått den samme feilen. Uansett vil Facebook også ha en beregning som viser antall triste brukere.

For intern kommunikasjon bruker Facebook noe som heter Workplace. Dette er effektivt en versjon av Facebook beregnet på bedrifter, som gir en nyttig måte å få informasjon om medlemmene av teamet på, og raskt kommunisere med de som sitter på den andre siden av det spredte kontoret. Facebook selger også denne programvaren til tredjepart.

Selvfølgelig kommer ikke Facebook til å kaste bort tid på å laste opp hver nye versjon av appene sine til Play Store, App Store, Amazon og alt det andre. Det er også en app for det som heter Mobile Push Train.

Lukkende tanker

Å holde en app som Facebook oppdatert er et enormt tilsagn, og selskapet trenger fortsatt å overbevise brukerne om å faktisk installere disse oppdateringene. Dette er spesielt vanskelig i land der tilkobling ikke er garantert. I Canada kjører bare en prosent av brukerne fremdeles en versjon av Facebook over et år gammel. I Etiopia er tallet nærmere 50 prosent!

Teamet på Facebook jobber tydeligvis veldig hardt og bruker massevis av verktøy og prosesser for å holde alt så strømlinjeformet som mulig. På slutten av dagen har utviklingsgruppen som mål å overholde fem regjerende prinsipper:

• Hold mesteren ren.
• Har ett team med kompetanse innen utgivelsesteknikk.
• Slipp på tid ofte.
• Hundematprodukter.
• Vær snill mot brukere.

Det høres enkelt ut, men som du kan se innebærer det mye spinnplater. Selv vedlikehold av alle verktøyene som brukes i prosessen er et prosjekt i seg selv!

På sin side opprettholder Facebook en vennlig og hjertelig atmosfære på kontoret i London. Teamet utveksler GIF-er og memes gjennom plugins, de navngir rom basert på “ting britene hater” og Shakespearean-ordspill, og de setter stor stolthet i arbeidet sitt. Hos Facebook jobber de hardt og spiller hardt, og det ser ut til at for det meste fungerer systemet.

Neste gang en ny oppdatering ruller ut for en av de større appene dine, kan du skaffe deg en tanke for alt arbeidet og organisasjonen det tok for å få den dit.