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 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.
Hvordan forbedre kodingseffektiviteten i 8 enkle trinn
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 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?
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 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 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 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 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 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 ø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 med base i New York City, antyder at det er fordi rot er å foretrekke fremfor et "sterilt" miljø, og sammenligner kaoset av rot med en bekreftelse på 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. Rydd opp er noe av det vanskeligste å gjøre for folk flest, og det er ikke bare våre fysiske stasjonære datamaskiner som trenger rydde opp, men ofte også stasjonære datamaskiner.
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 (ikke å forveksle med PEAR-programmering).
Mens noen mennesker virkelig beundrer denne arbeidsmetodikken og berømmer dens plass i det smidige utviklingsparadigmet, fant vi ut at det var fryktelig 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/startflyten 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.
konklusjonen
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.
Kommentar 0 Responses