8 enkle triks for å øke kodingseffektiviteten

Hvis du abonnerer på en tjeneste fra en lenke på denne siden, kan Reeves and Sons Limited tjene en provisjon. Se vår etisk uttalelse.

Det er et merkelig fenomen som har oppstått blant programvareutgivere. Det ser ut til å være en tendens til at folk snur på forståelsen av hva som gjør et kvalitetsprodukt bedre, eller i det minste er dette sant når det gjelder de som driver med markedsføringen. Det går noe i retning av: "Produktet deres har én million linjer med kode, men vårt har to millioner, så derfor må produktet vårt være bedre."

Ingen vet hvor denne "mer er mer"-tanken kom fra, da alle på den tiden jobbet så hardt for å skape en "mindre er mer"-filosofi. Sannsynligvis startet det med forbrukerjournalistikk, fordi mange forfattere prøver å imponere publikum ved å sitere store tall. For det meste fungerer dette – denne lille flash-stasjonen rommer 200 terabyte med data, den prosessoren 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 tette algoritmer. Det handler også om å kunne redusere avfallet. Dette betyr sløsing i form av hvor mye tid du bruker på å fikse problemer, sløsing i form av å forbruke for mange dataressurser, og til og med sløsing i form av hvor mange pizzaesker teamet ditt har stablet rundt på kontoret innen slutten av uken. Ideelt sett vil du kutte ned på alle disse tingene.

Så det vi skal se 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, for du er allerede herre over ditt eget arbeidsmiljø. Selvfølgelig kommer det til å endre seg når du besøker en klient og må jobbe på stedet, men det er fortsatt en fin posisjon å være i hvis du kan gjøre det til 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 bruke hver side av hjernen i like stor grad til enhver oppgave. Vitenskapen har lenge erkjent at kreative mennesker gjør sitt beste om natten, og det er noe vi alle har erfart. Så hvorfor insisterer de fleste ledere på en tradisjonell 9 til 5 rutine?

Faktisk vet vi allerede svaret på det. Det handler delvis om kontroll, og det handler delvis om å gjøre ting mer praktisk fra et forretningssynspunkt (eller i det minste et ledelsessynspunkt). Men at insistering på rutine og plassering skader effektiviteten og produktiviteten til teamet.

Det du må innse er at koderne dine sannsynligvis var oppe hele natten og prøvde det siste spillet, eller kanskje de var på fest, eller rett og slett måtte sosialisere med familien. Det betyr at når de møter på jobb mandag morgen, får du dem ikke bare på sitt høyeste produktivitetsnivå, men de er allerede tappet for energi og hundetrøtte.

Å gi arbeiderne et valg om når de jobber – og ideelt sett også hvor – er en utmerket måte å forbedre produktiviteten og moralen på. Så lenge de får jobben gjort og gir utmerkede kvalitetsresultater, 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 gjør de fleste programmerere det bedre når de får gjøre ting på sin egen måte, og behovet for tett samarbeid er sjeldent. Muligheten for å komme inn på kontoret bør fortsatt være der, men det er ingen realistisk grunn til at det bør være nødvendig med mindre du jobber med topphemmelige militære prosjekter.

Som frilanser kan du også se at hovedpoenget her er at hvis du gjør mesteparten av det faktiske kodearbeidet 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 sprø filmstereotypiene der en supergrungy überhacker tar på seg hodetelefonene og jammer med til death-metal mens de uanstrengt churrer ut skjermfulle koder uten engang å stoppe for å puste. Og alle vi som virkelig koder i den virkelige verden vet hvor latterlig det bildet er.

Men hvis du lytter til musikk mens du jobber, vær forsiktig. Det er ganske lett å tenke på musikken i stedet for arbeidet ditt, og noen typer musikk kan ha en soporisk effekt. Når du trener på treningsstudioet, kan den rette typen musikk inspirere deg til å presse ut de ekstra få repetisjonene. Men ingen har noen gang klart å lage musikk som vil inspirere deg til å finne streken med det manglende semikolonet, eller til å ta det riktige valget mellom å bruke en for loop eller en while 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 ville ha 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 alt dette ryddingen, ikke gå over bord. Det er mye god vitenskap som tyder på at litt kaos i miljøet faktisk kan bidra til kreativitet. En av de oftest siterte undersøkelsene på dette er en journaloppføring 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 etterlater dette deg? Skal 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 vurderer. Mange av historiens beste admiraler og generaler var kjent for den lange tiden de brukte på å gå rundt på dekk 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 riktige øyeblikket og nærme deg det på riktig måte, ellers kan det slå tilbake ved å gjøre 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, i 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 forretningsledelse og programmeringsprosedyrer som høres mye mer fornuftige ut i teorien enn de viser seg å være i praksis. Hvorvidt 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 gjorde det også lettere å oppdage feil og gi forslag om å stramme opp en algoritme. Samtidig skapte imidlertid de samme fordelene også problemer, fordi noen ganger var justeringer og justeringer egentlig ikke 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. Du kan oppleve personlighetssammenstøt som 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 at dette er fordi de nyter den sosiale interaksjonen den gir, men dette bidrar ikke til effektiviteten av produksjonen, bortsett fra kanskje som en moralsk booster.

Så det du trenger å etablere er hva som faktisk fungerer for utviklerne og hva som ikke gjør det. For de tingene som ikke fungerer, er det bedre å forkaste dem, selv om de er en populær praksis. Det som hjelper teamet til å gjøre fremgang raskt, er en god ting. Men hvis de blir tynget av en metodikk som ikke passer stilen deres, 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 tilfellet), er det overflødig å legge til mer beskrivelse. Det samme gjelder variabelnavn og returverdier. Det skal fremgå av navnet hva de gjør, og i de tilfellene det ikke er mulig, bør du inkludere en beskrivelse av dem i kommentarfeltet.

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 å ved et uhell (eller med vilje) sabotere koden din ved å overskrive den med noe som ikke behager deg.

Ved å ta disse åtte nøkkelforslagene i betraktning, vil du være i stand til å utvikle din egen strategi for å få ut mest mulig effektivitet for deg og eventuelle teammedlemmer du jobber med. Du trenger ikke nødvendigvis å bruke dem alle, og sikkert noen er kanskje ikke engang praktiske for deg, men enhver kombinasjon av dem vil sannsynligvis føre til at du får arbeidet gjort med mindre problemer. En mer produktiv arbeidsflyt vil betale seg tilbake over tid, selv om det bare er i form av stressreduksjon og gir deg mer tid for deg selv. Det er et mål det er verdt å jobbe mot.

Bogdan Rancea

Bogdan er et grunnleggende medlem av Inspired Mag, etter å ha opparbeidet seg nesten 6 års erfaring i løpet av denne perioden. På fritiden liker han å studere klassisk musikk og utforske billedkunst. Han er ganske besatt av fixies også. Han eier 5 allerede.

Kommentar 0 Responses

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket *

Vurdering *

Dette nettstedet bruker Akismet for å redusere spam. Lær hvordan kommentaren din behandles.