Det er et merkelig fenomen som har oppstått blant programvareutgivere. Det ser ut til å være en tendens for folk å snu sin forståelse av hva som gjør et kvalitetsprodukt bedre, eller i det minste gjelder dette når det gjelder de som driver med markedsføringen. Det går noe i retning av: "Produktet deres har en million kodelinjer, men vårt har to millioner, så derfor må produktet vårt bli bedre."
Ingen vet hvor denne "mer er mer" -tankegangen kom fra, da alle på dagen jobbet så hardt for å skape en "mindre er mer" -filosofi. Sannsynligvis startet det med forbrukerkvalitetsjournalistikk, fordi mange forfattere prøver å imponere publikum ved å sitere store tall. For det meste fungerer dette - denne lille flash-stasjonen inneholder 200 terabyte data, at CPU kan behandle 48 milliarder instruksjoner per sekund - og forfattere er ikke alltid teknologisk kunnskapsrike nok til å forstå at det samme ikke gjelder kildekoden.
Men effektivitet i koding handler ikke bare om å lage stramme algoritmer. Det handler også om å kunne redusere avfall. Dette betyr avfall når det gjelder hvor mye tid du bruker på å fikse problemer, avfall i form av å konsumere for mange datamaskinressurser, og til og med avfall når det gjelder hvor mange pizzakasser teamet ditt har stablet opp på kontoret i slutten av uken. Helst vil du kutte ned på alle disse tingene.
Så det vi tar en titt på i denne artikkelen vil være tingene du kan gjøre for å forbedre effektiviteten og øke produktiviteten.
1. Bygg et arbeidsmiljø som bidrar
Hver koder jobber under unike omstendigheter, og leserne våre er en veldig mangfoldig gjeng, så det vil være lettere for noen av dere å implementere disse forslagene enn for andre.
Hvis du er frilanser, gratulerer, fordi du allerede er herre over ditt eget arbeidsmiljø. Selvfølgelig vil det endre seg når du besøker en klient og må jobbe på stedet, men det er fremdeles en søt posisjon å være i hvis du kan gjøre en suksess.
Hvis du er leder for et utviklingsteam, kan disse forslagene også bidra til å få teamet ditt til maksimal effektivitet. Eller hvis du er en arbeider i et utviklingsteam, kan det være lurt å foreslå noen av disse ideene til lederen din, eller i det minste sende ham eller henne en lenke til denne siden og håpe på det beste.
Vurder å la teammedlemmer delta i telekommunikasjon
Programmering er delvis en øvelse i logikk, men det er enda mer en kreativ utfordring. De beste programmererne kan ansette hver side av hjernen i like stor grad som enhver oppgave. Vitenskapen har lenge erkjent at kreative mennesker gjør sitt beste arbeid om natten, og det er noe vi alle har opplevd. Så hvorfor insisterer de fleste ledere på en tradisjonell 9 til 5-rutine?
Egentlig vet vi allerede svaret på det. Det handler delvis om kontroll, og det handler delvis om å gjøre ting mer praktisk fra et forretningsmessig synspunkt (eller i det minste en ledelsesmessig). Men at insistering på rutine og beliggenhet skader effektiviteten og produktiviteten til teamet.
Det du trenger å innse er at koderne dine sannsynligvis var oppe hele natten med å prøve ut det siste spillet, eller kanskje de gikk på fest, eller bare måtte sosialisere seg med familien. Det betyr at når de dukker opp på jobb mandag morgen, ikke bare får du dem ikke på topp produktivitetsnivå, men de er allerede tappet for energi og hundetrøtt.
Å gi arbeidstakere et valg om når de jobber - og ideelt sett også der - er en utmerket måte å forbedre produktivitet og moral. Så lenge de får jobben gjort og gir gode resultater, bør du ikke bry deg om når, hvor eller hvordan de oppnår det.
Unntaket er når du trenger tett samarbeid, men i sannhet klarer de fleste kodere bedre når de blir igjen å gjøre ting på sin egen måte, og behovet for nært samarbeid er sjeldent. Alternativet å komme inn på kontoret bør fremdeles være der, men det er ingen realistisk grunn til at det bør kreves med mindre du jobber med topphemmelige militære prosjekter.
Som frilanser kan du også se at hovedpoenget her er at hvis du gjør det meste av det faktiske kodingsarbeidet ditt om natten, vil du sannsynligvis få gjort mer. Det er færre distraksjoner sent på kvelden, det er roligere, og du vil føle deg mer kreativ.
Unngå musikk
Vi har alle sett de vanvittige filmstereotypiene der noen super-grungy überhacker tar på seg hodetelefonene og syltetøyene til death-metal, mens de uanstrengt kaster ut skjermfulle koder uten engang å stoppe å puste. Og alle oss som virkelig koder i den virkelige verden vet hvor latterlig det bildet er.
Men hvis du hører på musikk mens du jobber, må du være forsiktig. Det er ganske enkelt å finne deg selv tenke på musikken i stedet for arbeidet ditt, og noen slags musikk kan ha en soporisk effekt. Når du går på trening på treningsstudioet, kan den riktige typen musikk inspirere deg til å presse ut de ekstra få repsene. Men ingen har noen gang klart å lage musikk som vil inspirere deg til å finne linjen med den manglende halvkolon, eller å ta det riktige valget mellom å bruke en for loop eller en stund loop. Det nærmeste vi noen gang har kommet det er Electric Dreams.
Forsøk å holde ryddig
Rot kan være merkelig trøstende, men det kan også bremse deg. Du kan lett miste 20 minutter på å lete etter noe som har gått tapt i rotet, og så glemme hvorfor du ønsket det i utgangspunktet.
Så, til tross for alle ulempene det medfører, hvorfor er vi – i det minste noen av oss – så avhengige av rot? Organisasjonsekspert og forfatter, Julie Morgenstern, hevder det er fordi disse tingene forbinder oss med fortiden vår og spiller en rolle i å definere identiteten vår. Marcus Geduld, en lærer og sceneregissør basert i New York City, antyder at det er fordi rot er å foretrekke fremfor et "sterilt" miljø, og sammenligner kaoset med rot med en affirmasjon av frihet og kreativitet.
Det er imidlertid ingen tvil om at å redusere rot vil hjelpe deg å unngå distraksjon og uorganisering. Som sådan er det et verdig mål å oppnå. For all del, ha noen hellige gjenstander rundt som gjør at du føler deg bedre og mindre stresset, men ikke overdriv. Å rydde opp er en av de vanskeligste tingene å gjøre for folk flest, og det er ikke bare vårt fysiske desktops som trenger decluttering, men ofte vår datamaskin desktops også. Hvis du virkelig sliter med det, kan du prøve å bruke en minimalistisk DTE som Fluxbox, som egentlig ikke lar deg ha noe rot.
Men midt i all denne ryddingen, ikke gå over bord. Det er nok av god vitenskap som tyder på at litt kaos i miljøet kan være gunstig for kreativitet. En av de mest siterte bitene med forskning på dette er en journalpost i Psychological Science av Vohs, Redden & Rahinel for University of Minnesota med tittelen Fysisk orden produserer sunne valg, generøsitet og konvensjonalitet, mens lidelse produserer kreativitet. Sannsynligvis er årsaken til at dette er papirjournalistene som holder fast ved at det tydelig konkluderer med at: "... deltakere i et uordnet rom var mer kreative enn deltakere i et ordnet rom."
Mye mindre populært er uenige synspunkter, som Miljøforstyrrelse fører til svikt i selvregulering (Chaye & Zhu, 2014), publisert i Journal of Consumer Research. Denne studien fant at personer som arbeider i uordnede miljøer var nedsatt i evnen til å utføre oppgaver.
Så hvor overlater dette deg? Bør du jobbe i kaos eller sterilitet? Svaret ser ut til å være å finne en balanse der det bare er kaotisk nok til å holde deg inspirert, men ikke så mye at du blir distrahert eller har problemer med å finne ting.
Legg igjen litt rom etter deg for å stimulere tankene dine
Det er lurt å ha god plass til å vandre rundt når du overveier. Mange av de beste admiralene og generalene i historien var kjent for den store tiden de brukte pacing rundt dekket mens de planla kampstrategier.
Ikke bare kjemper menn følger denne praksisen. Mange buddhistmunker går også inn for "vandringsmeditasjon", og mener det bidrar til å fremme klarhet i sinnet. Når du har et spesielt knottete programmeringsproblem å løse, kan det hende at det hjelper å strekke beina litt med en meditativ tur rundt dekk. Åpenbart her vil mangel på rot hjelpe deg med å gjøre dette uten å havne på sykehuset.
Ta en forsiktig tilnærming til kritikk av kreativ innsats
Det er ikke noe galt med konstruktiv kritikk, men du må velge det rette øyeblikket og tilnærme det på riktig måte, eller det kan slå tilbake ved å gjøre dine ansatte mindre produktive i fremtiden. I stedet for å inspirere dem og gi innsikt, kan du faktisk gjøre dem redde for å ta risiko, noe som er en god måte å drepe kreativiteten på. Marieke Roskes, inn Begrensninger som hjelper eller hindrer kreativ ytelse: En motiverende tilnærming, gir et rammeverk for hvordan man skal takle motivasjon fra kreative arbeidere, og spesifikt også hvordan man kan unngå å utilsiktet demotivere dem (Creativity & Innovation Management, Vol 24, Iss 2, 2015).
2. Etabler en god SOP
Det er mange fengende trender innen forretningsadministrasjon og programmeringsprosedyrer som høres ut mye mer fornuftig i teorien enn de viser seg å være i praksis. Om en bestemt tilnærming fungerer for deg eller ikke, avhenger av målet ditt, og hva du personlig anser som et vellykket resultat.
Et eksempel på en metodikk som et selskap jeg jobbet for prøvde — og like raskt droppet — er parprogrammering (for ikke å forveksle med PEAR-programmering). Mens noen virkelig beundrer denne arbeidsmetodikken og berømmer sin plass i det smidige utviklingsparadigmet, fant vi ut at det var veldig ineffektivt. Til å begynne med krevde det to programmerere for hver arbeidsstasjon, så du betalte dobbelt så mye for mindre faktisk utviklingsarbeid. Vi fant også ut at det var mye tregere å jobbe på denne måten på grunn av den hyppige stopp / start-strømmen og tendensen til unødvendig dialog.
Fordelene med parprogrammering var at det resulterte i mer naturlig dokumentasjon og strengere dokumentasjon. Det tillot også feil å bli oppdaget feil og at det kunne komme forslag om å stramme inn en algoritme. På samme tid skapte imidlertid de samme fordelene også problemer fordi noen ganger var justeringene og justeringene ikke egentlig nødvendige.
En annen risiko med denne tilnærmingen er at du kan få effekten identifisert av Roskes, der programmerere kan være nølende med å prøve ting fordi de ikke ønsker å bli korrigert. Det kan hende du synes personlighetskonflikter blusser der den ene utvikleren er veldig pedantisk og tradisjonell, men den andre er mer kreativ og spontan.
Programmerere oppgir ofte at de foretrekker parprogrammering. Det er mulig det skyldes at de liker det sosiale samspillet det gir, men dette bidrar ingenting til effektiviteten i produksjonen, bortsett fra kanskje som en moralsk booster.
Så det du trenger å etablere er hva som faktisk fungerer for utviklerne dine og hva som ikke gjør det. For tingene som ikke fungerer, er det bedre å forkaste dem, selv om de er en veldig populær praksis. Det som hjelper teamet med å komme raskt fremover, er en god ting. Men hvis de blir veid ned med en metodikk som ikke passer deres stil, vil det til slutt føre til problemer.
3. Oppfordre til fullstendig dokumentasjon
Selv om det kan se ut som om verbositet vil øke ineffektiviteten, kan den lille tiden det tar å gi mer detaljer og presisjon i kommentarer spare mye problemer når prosjektet ruller sammen eller gjennomgår revisjoner.
4. Motarbeid unødvendig dokumentasjon
Velskrevet kode er ofte selvdokumenterende. Hvis det er helt åpenbart hva en funksjon gjør fra navnet du gir den (som nesten alltid burde være tilfelle), er det overflødig å legge til en beskrivelse. Det samme gjelder for variabel navn og returverdier. Det skal fremgå av navnet hva de gjør, og i de tilfellene hvor det ikke er mulig å gjøre det, bør du ta med en beskrivelse av dem i kommentarer.
5. White space er din venn
Å bruke hvitt mellomrom i koden din er verdifullt for å gjøre koden enklere å lese, gjennomgå og forstå. Det går hånd i hånd med god dokumentasjon og skriving av selvdokumenterende kode. Det bør være mulig for enhver erfaren programmerer - eller kanskje til og med en ikke-programmerer - å hente en kopi av kildekoden din og umiddelbart forstå hva formålet med hver funksjon er og hvordan den fungerer. Ideelt sett skal noen kunne lære å programmere fra ingenting mer enn å studere den velskrevne koden.
6. Foretrekker enkelhet framfor kompleksitet
Jo mer kompleks du lager koden din, desto vanskeligere kan det være å løsne den. Ironisk nok gjelder dette programmering av snarveier, som å bruke korthårskondisjoner i stedet for å skrive dem ut i sin helhet. Det sparer tid i skrivingen, men en mindre erfaren programmerer som kommer inn for å se gjennom koden senere, vil kanskje ikke forstå intensjonene dine.
7. Test uttømmende
Kode skal testes trinnvis og ofte. Før du distribuerer noe, bør du gjennomføre så mye interntesting som mulig, selv om din første utgivelse vil bli kalt Alpha.
8. Bruk versjonskontroll
Du må være gal for ikke å bruke versjonskontroll på et større prosjekt. Uten den er du ikke beskyttet mot dine egne mindre feil, og det er også veldig enkelt for et annet teammedlem å tilfeldigvis (eller med vilje) sabotere koden din ved å overskrive den med noe som ikke behager deg.
Ved å ta hensyn til disse åtte viktige forslagene, vil du kunne utvikle din egen strategi for å hente ut mest effektivitet for deg og alle teammedlemmer du jobber med. Du trenger ikke nødvendigvis å bruke dem alle, og noen kan ikke være praktisk for deg, men noen kombinasjon av dem vil sannsynligvis føre til at du får arbeidet mindre. En mer produktiv arbeidsflyt vil betale for seg selv over tid, selv om det bare er når det gjelder stressreduksjon og gir deg mer tid for deg selv. Det er et mål som er verdt å jobbe mot.
Kommentar 0 Responses