Der er et mærkeligt fænomen, der er opstået blandt softwareudgivere. Der ser ud til at være en tendens for folk til at vende om deres forståelse af, hvad der gør et kvalitetsprodukt bedre, eller i det mindste er det sandt, når det kommer til dem, der foretager markedsføringen. Det går noget i retning af: "Deres produkt har en million linjer kode, men vores har to millioner, så derfor skal vores produkt være bedre."
Ingen ved, hvor denne "mere er mere" -tænkning kom fra, da alle på dagen arbejdede så hårdt for at skabe en "mindre er mere" -filosofi. Det startede sandsynligvis med forbrugerkvalitetsjournalistik, fordi mange forfattere prøver at imponere publikum ved at citere store tal. For de fleste ting fungerer dette - dette lille flashdrev indeholder 200 terabyte data, at CPU'en kan behandle 48 milliarder instruktioner pr. Sekund - og forfattere er ikke altid teknologisk kloge nok til at forstå, at det samme ikke gælder for kildekoden.
Men effektivitet i kodning handler ikke kun om at skabe stramme algoritmer. Det handler også om at være i stand til at reducere affald. Dette betyder spild i form af, hvor meget tid du bruger på at løse problemer, spild i form af at forbruge for mange computerressourcer og endda spild i form af hvor mange pizzakasser dit team har stablet op på kontoret i slutningen af ugen. Ideelt set vil du skære ned på alle disse ting.
Så hvad vi vil se på i denne artikel vil være de ting, du kan gøre for at forbedre effektiviteten og øge produktiviteten.
1. Byg et fremmende arbejdsmiljø
Hver koder fungerer under unikke omstændigheder, og vores læsere er en meget forskelligartet bunke, så det vil være lettere for nogle af jer at implementere disse forslag end for andre.
Hvis du er freelancer, tillykke, fordi du allerede er mester i dit eget arbejdsmiljø. Naturligvis ændrer det sig, når du besøger en klient og skal arbejde på stedet, men det er stadig en sød position at være i, hvis du kan få en succes med det.
Hvis du er manager for et udviklingshold, kan disse forslag også hjælpe med at få dit team til maksimal effektivitet. Eller hvis du er en arbejdstager i et udviklingsteam, kan du eventuelt foreslå nogle af disse ideer til din manager eller i det mindste sende ham eller hende et link til denne side og håbe på det bedste.
Overvej at give teammedlemmer mulighed for at kommunikere
Programmering er delvis en øvelse i logik, men det er endnu mere en kreativ udfordring. De bedste programmerere kan anvende hver side af deres hjerne i lige store mål som enhver opgave. Videnskab har længe erkendt, at kreative mennesker gør deres bedste arbejde om natten, og det er noget, vi alle har oplevet. Så hvorfor insisterer de fleste ledere på en traditionel 9 til 5 rutine?
Faktisk ved vi allerede svaret på det. Det handler dels om kontrol, og det handler dels om at gøre tingene mere praktiske ud fra et forretningsmæssigt synspunkt (eller i det mindste et ledelsesmæssigt). Men at insistering på rutine og placering skader teamets effektivitet og produktivitet.
Hvad du har brug for at være klar over, er, at dine kodere sandsynligvis var oppe hele natten med at prøve det nyeste spil, eller måske gik de på fest, eller bare måtte socialisere sig med familien. Det betyder, at når du møder på arbejde mandag morgen, ikke kun får du dem ikke på deres højeste produktivitetsniveau, men de er allerede drænet for energi og hundetræt.
At give arbejdstagere et valg om, hvornår de arbejder - og ideelt også hvor - er en fremragende måde at forbedre produktivitet og moral på. Så længe de får jobbet gjort og indtaster fremragende kvalitetsresultater, skal du ikke være interesseret i hvornår, hvor eller hvordan de opnår det.
Undtagelsen er, når du har brug for et tæt samarbejde, men i sandhed klarer de fleste kodere det bedre, når de overlades til at gøre tingene på deres egen måde, og behovet for tæt samarbejde er sjældent. Muligheden for at komme ind på kontoret skal stadig være der, men der er ingen realistisk grund til, at det skal være påkrævet, medmindre du arbejder på tophemmelige militære projekter.
Som freelancer kan du også se det centrale punkt her, at hvis du udfører det meste af dit faktiske kodningsarbejde om natten, vil du sandsynligvis få mere gjort. Der er færre distraktioner sent om aftenen, det er mere støjsvage, og du vil føle dig mere kreativ.
Undgå musik
Vi har alle set de skøre filmstereotyper, hvor nogle super-grungy überhacker sætter deres hovedtelefoner og syltetøj sammen til death-metal, mens de ubesværet kaster ud screenfuls kode uden selv at stoppe med at trække vejret. Og alle os, der virkelig koder i den virkelige verden ved, hvor latterligt det billede er.
Men hvis du lytter til musik, mens du arbejder, skal du være forsigtig. Det er ganske let at finde dig selv i at tænke på musikken i stedet for dit arbejde, og nogle slags musik kan have en soporisk effekt. Når du går på træning på gymnastiksalen, inspirerer den rigtige musik muligvis dig til at skubbe de ekstra få reps ud. Men ingen har nogensinde formået at skabe musik, der vil inspirere dig til at finde linjen med den manglende halvkolon, eller at tage det rigtige valg mellem at bruge en for-loop eller en stund-loop. Det nærmeste, vi nogensinde har nået, er Electric Dreams.
Forsøg at holde ryddig
Clutter kan være underligt trøstende, men det kan også bremse dig. Du kan nemt miste 20 minutter på at lede efter noget, der er gået tabt i rodet, og så glemme, hvorfor du ville have det i første omgang.
Så på trods af al den ulejlighed, det medfører, hvorfor er vi – i det mindste nogle af os – så afhængige af rod? Organisationsekspert og forfatter, Julie Morgenstern, hævder, at det er, fordi dette stof forbinder os med vores fortid og spiller en rolle i at definere vores identitet. Marcus Geduld, en lærer og instruktør baseret i New York City, antyder, at det er, fordi rod er at foretrække frem for et "sterilt" miljø, og sammenligner kaoset af rod med en affirmfrihed og kreativitet.
Der er dog ingen tvivl om, at reduktion af rod vil hjælpe dig med at undgå distraktion og uorganisering. Som sådan er det et værdigt mål at nå. Hold i hvert fald et par hellige genstande omkring dig, som får dig til at føle dig bedre og mindre stresset, men overdriv det ikke. At rydde op er en af de sværeste ting at gøre for de fleste mennesker, og det er ikke kun vores fysiske desktops, der skal rydde op, men ofte vores computer desktops også. Hvis du virkelig kæmper med det, kan du prøve at bruge en minimalistisk DTE såsom Fluxbox, som ikke rigtig tillader dig at have noget rod.
Men midt i al denne oprydning, må du ikke gå over bord. Der er masser af god videnskab, der antyder, at en smule kaos i miljøet faktisk kan bidrage til kreativitet. Et af de mest citerede bits med forskning i dette er en journalpost i Psychological Science af Vohs, Redden & Rahinel for University of Minnesota med titlen Fysisk orden producerer sunde valg, generøsitet og konventionelitet, hvorimod lidelse producerer kreativitet. Sandsynligvis årsagen til, at dette er papirjournalisterne, der holder fast ved, er, at det klart konkluderer, at: "... deltagere i et uordnet rum var mere kreative end deltagere i et velordnet rum."
Meget mindre populære er uenige synspunkter, som f.eks Miljøforstyrrelse fører til selvregulerende svigt (Chaye & Zhu, 2014), offentliggjort i Journal of Consumer Research. Denne undersøgelse fandt, at mennesker, der arbejdede i uordnede miljøer, var nedsat i deres evne til at udføre opgaver.
Så hvor overlader dette dig? Skal du arbejde i kaos eller sterilitet? Svaret ser ud til at være at finde en balance, hvor det bare er kaotisk nok til at holde dig inspireret, men ikke så meget, at du bliver distraheret eller har problemer med at finde ting.
Efterlad nogle plads bag dig for at stimulere dine tanker
Det er en god ide at have masser af plads til at vandre rundt, når du overvejer. Mange af de bedste admiraler og generaler i historien var berømt for den omfattende tid, de tilbragte tempo omkring bunken under planlægningen af kampstrategier.
Ikke kun kampmænd følger denne praksis. Mange buddhistiske munke går også ind for "vandrende meditation" og mener, det hjælper med at fremme klarhed i sindet. Når du har et særligt knudet programmeringsproblem at løse, kan det være, at det hjælper med at strække dine ben lidt med en meditativ tur rundt på dækket. Åbenlyst her vil mangel på rod hjælpe dig med at gøre dette uden at havne på hospitalet.
Tag som en chef en forsigtig tilgang til kritik af kreative anstrengelser
Der er ikke noget galt med konstruktiv kritik, men du er nødt til at vælge det rigtige øjeblik og nærme det på den rigtige måde, eller det kan slå tilbage ved at gøre dit personale mindre produktivt i fremtiden. I stedet for at inspirere dem og give indsigt, kan du faktisk gøre dem bange for at tage risici, hvilket er en god måde at slå kreativiteten af. Marieke Roskes, i Begrænsninger, der hjælper eller hindrer kreativ ydeevne: En motiverende tilgang, giver en ramme for, hvordan man håndterer motivation hos kreative medarbejdere, og specifikt også, hvordan man undgår utilsigtet demotivering af dem (Creativity & Innovation Management, Vol 24, Iss 2, 2015).
2. Opret en god SOP
Der er en masse iørefaldende tendenser inden for forretningsstyring og programmeringsprocedure, der lyder meget mere fornuftigt i teorien, end de viser sig at være i praksis. Hvorvidt en bestemt tilgang fungerer for dig eller ej, afhænger af dit mål, og hvad du personligt betragter som et vellykket resultat.
Et eksempel på en metode, som et firma, jeg arbejdede for, prøvede - og lige så hurtigt faldt - er parprogrammering (ikke at forveksle med PEAR-programmering). Mens nogle mennesker virkelig beundrer denne arbejdsmetodologi og roser sin plads i det agile udviklingsparadigme, fandt vi, at det var forfærdeligt ineffektivt. Til at starte med krævede det to programmerere til hver arbejdsstation, så du betalte dobbelt så meget for mindre faktisk udviklingsarbejde. Vi fandt også, at det var meget langsommere at arbejde på denne måde på grund af den hyppige stop / start-strøm og tendensen til unødvendig dialog.
Fordelene ved parprogrammering var, at det resulterede i mere naturlig dokumentation og strengere dokumentation. Det gjorde det også muligt at opdage bugs lettere og til at komme med forslag til stramning af en algoritme. På samme tid skabte de samme fordele imidlertid også problemer, fordi undertiden justeringer og justeringer ikke var rigtig nødvendige.
En anden risiko med denne tilgang er, at du kan få den effekt, der er identificeret af Roskes, hvor programmerere måske er tøvende med at prøve ting, fordi de ikke ønsker at blive rettet. Du kan finde personlighedskonflikter, der er fakkelrige, hvor den ene udvikler er meget pedantisk og traditionel, men den anden er mere kreativ og spontan.
Programmerere oplyser ofte, at de foretrækker parprogrammering. Det er muligt, at dette skyldes, at de nyder den sociale interaktion, det giver, men dette bidrager intet til effektiviteten af produktionen, undtagen måske som en moralsk booster.
Så hvad du har brug for at etablere, er, hvad der faktisk fungerer for dine udviklere, og hvad der ikke gør. For de ting, der ikke fungerer, er det bedre at kassere dem, selvom de er en hottend praksis. Uanset hvad der hjælper teamet med at komme hurtigt frem, er det en god ting. Men hvis de vejes ned med en metode, der ikke passer til deres stil, vil det til sidst føre til problemer.
3. Tilskynde til ordentlig dokumentation
Selvom det kan se ud til, at verbositet vil øge ineffektiviteten, kan det lille tidsrum, det tager at give mere detaljering og præcision i kommentarer, spare en masse problemer, når projektet ruller videre eller gennemgår revisioner.
4. Undgå unødvendig dokumentation
Velskrevet kode er ofte selvdokumenterende. Hvis det er helt åbenlyst, hvad en funktion gør fra det navn, du giver det (hvilket næsten altid skal være tilfældet), er det overflødigt at tilføje en mere beskrivelse. Det samme gælder for variabel navngivning og returværdier. Det skal fremgå af navnet, hvad de gør, og i de tilfælde, hvor det ikke er muligt, skal du medtage en beskrivelse af dem i kommentarer.
5. Det hvide rum er din ven
Brug af hvid plads passende i din kode er værdifuld til at hjælpe med at gøre koden lettere at læse, gennemgå og forstå. Det går hånd i hånd med god dokumentation og skrivning af selvdokumenterende kode. Det burde være muligt for enhver erfaren programmør - eller måske endda en ikke-programmerer - at hente en kopi af din kildekode og øjeblikkeligt forstå, hvad formålet med hver funktion er, og hvordan den fungerer. Ideelt set skal nogen være i stand til at lære at programmere fra intet andet end at studere din velskrevne kode.
6. Foretrækk enkelhed frem for kompleksitet
Jo mere kompleks du laver din kode, desto vanskeligere kan det være at fjerne den. Ironisk nok gælder dette for programmering af genveje, som at bruge korthårskonditioner i stedet for at udskrive dem fuldt ud. Det sparer tid i skrivningen, men en mindre erfaren programmør, der kommer til at gennemgå din kode senere, forstår muligvis ikke dine intentioner.
7. Test udtømmende
Kode skal testes trinvist og ofte. Inden du implementerer noget, skal du gennemføre så meget intern test som muligt, selvom din første udgivelse vil blive betegnet Alpha.
8. Brug versionskontrol
Du bliver nødt til at være skør for ikke at bruge versionskontrol til et større projekt. Uden det er du ikke beskyttet mod dine egne mindre fejl, og det er også virkelig nemt for et andet teammedlem at ved et uheld sabotere din kode ved at overskrive den med noget, der ikke behager dig.
Ved at tage disse otte nøgleforslag i betragtning, vil du være i stand til at udvikle din egen strategi for at udtrække mest effektivitet for dig og ethvert teammedlem, du arbejder med. Du behøver ikke nødvendigvis at anvende dem alle, og bestemt er nogle måske ikke engang praktisk for dig, men enhver kombination af dem vil sandsynligvis resultere i, at du får dit arbejde med mindre besvær. En mere produktiv arbejdsgang betaler sig selv over tid, selvom det kun er hvad angår stressreduktion og giver dig mere tid for dig selv. Det er et mål værd at arbejde mod.
Kommentarer 0 Responses