Det finns ett konstigt fenomen som har uppstått bland mjukvaruutgivare. Det verkar finnas en tendens för människor att invertera sin förståelse för vad som gör en kvalitetsprodukt bättre, eller åtminstone är det sant när det gäller de som gör marknadsföringen. Det går något i stil med: "Deras produkt har en miljon rader kod, men vår har två miljoner, så därför måste vår produkt bli bättre."
Ingen vet var detta "mer är mer" -tänkande kom ifrån när alla på dagen arbetade så hårt för att skapa en "mindre är mer" -filosofi. Förmodligen började det med konsumentkvalitetsjournalistik, för många författare försöker imponera publiken genom att citera stora siffror. För det mesta fungerar detta - den här lilla flashenheten rymmer 200 terabyte data, att CPU kan bearbeta 48 miljarder instruktioner per sekund - och författare är inte alltid tillräckligt tekniskt kunniga för att förstå att detsamma inte gäller källkoden.
Men effektivitet i kodning handlar inte bara om att skapa snäva algoritmer. Det handlar också om att kunna minska avfallet. Detta innebär avfall i termer av hur mycket tid du spenderar på att fixa problem, avfall när det gäller att konsumera för många datoressurser och till och med avfall i termer av hur många pizzaskåp ditt team har samlat på kontoret i slutet av veckan. Helst vill du skära ner alla dessa saker.
Så det vi tittar på i den här artikeln kommer att vara de saker du kan göra för att förbättra effektiviteten och öka produktiviteten.
1. Bygg upp en gynnsam arbetsmiljö
Varje kodare arbetar under unika omständigheter, och våra läsare är ett mycket varierat gäng, så det blir lättare för några av er att implementera dessa förslag än för andra.
Om du är frilansare, grattis, för du är redan befälhavare i din egen arbetsmiljö. Naturligtvis kommer det att förändras när du besöker en klient och måste arbeta på plats, men det är fortfarande en söt position att vara i om du kan lyckas med det.
Om du är chef för ett utvecklingsteam kan dessa förslag också hjälpa dig att få ditt team till maximal effektivitet. Eller om du är en arbetare i ett utvecklingsteam, kanske du vill föreslå några av dessa idéer till din chef eller åtminstone skicka honom eller henne en länk till den här sidan och hoppas på det bästa.
Överväg att låta teammedlemmar telekommunikera
Programmering är delvis en övning i logik, men det är ännu mer en kreativ utmaning. De bästa programmerarna kan anställa vardera sidan av hjärnan lika mycket som alla uppgifter. Vetenskapen har länge erkänt att kreativa människor gör sitt bästa arbete på natten, och det är något vi alla har upplevt. Så varför insisterar de flesta chefer på en traditionell 9 till 5-rutin?
Vi vet faktiskt redan svaret på det. Det handlar delvis om kontroll, och det handlar delvis om att göra saker mer bekvämt ur en affärssynpunkt (eller åtminstone en ledning). Men att insisterande på rutin och plats skadar teamets effektivitet och produktivitet.
Vad du behöver inse är att dina kodare troligen var uppe hela natten och provade det senaste spelet, eller kanske de gick på fest, eller helt enkelt var tvungna att umgås med familjen. Det betyder att när de dyker upp på jobbet på måndagsmorgonen, inte bara får du dem på deras högsta produktivitetsnivå, utan de är redan tömda för energi och hundtrötta.
Det är ett utmärkt sätt att förbättra produktiviteten och moralen att ge arbetarna ett val om när de arbetar - och helst också var. Så länge de får jobbet gjort och förvandlar utmärkta resultat för kvaliteten, bör du inte bry dig om när, var eller hur de uppnår det.
Undantaget är när du behöver nära samarbete, men i själva verket gör de flesta kodare bättre när de lämnas för att göra saker på sitt eget sätt, och behovet av nära samarbete är sällsynt. Alternativet att komma in på kontoret borde fortfarande vara där, men det finns inget realistiskt skäl till varför det borde krävas om du inte arbetar med topphemliga militära projekt.
Som frilansare kan du också se nyckelpunkten här är att om du gör det mesta av ditt verkliga kodningsarbete på natten, kommer du sannolikt att få mer gjort. Det är färre distraktioner sent på kvällen, det är tystare och du känner dig mer kreativ.
Undvik musik
Vi har alla sett de galna filmstereotyper där någon super-grungy überhacker sätter på sina hörlurar och sylt till death-metal, utan att utan problem rensa bort koder utan att ens sluta andas. Och alla vi som verkligen kodar i den verkliga världen vet hur löjlig den bilden är.
Men om du lyssnar på musik medan du arbetar, var försiktig. Det är ganska lätt att hitta dig själv tänka på musiken istället för ditt arbete, och vissa typer av musik kan ha en soporisk effekt. När du går på ett träningspass på gymmet, kan rätt typ av musik inspirera dig att skjuta ut de extra få repetitionerna. Men ingen har någonsin lyckats skapa musik som kommer att inspirera dig att hitta linjen med den saknade halvkolon, eller att göra rätt val mellan att använda en for-loop eller en stund-loop. Det närmaste vi någonsin har hittat är Electric Dreams.
Försök att hålla ryddig
Rutter kan vara konstigt tröstande, men det kan också bromsa dig. Du kan lätt förlora 20 minuter och leta efter något som har gått förlorat i röran och sedan glömma varför du ville ha det i första hand.
Så, trots allt besvär det medför, varför är vi – åtminstone vissa av oss – så beroende av röran? Organisationsexpert och författare, Julie Morgenstern, hävdar att det beror på att det här förbinder oss med vårt förflutna och spelar en roll i att definiera vår identitet. Marcus Geduld, lärare och regissör baserad i New York City, menar att det beror på att röran är att föredra framför en "steril" miljö, och liknar kaoset av röran med en affirmfrihet och kreativitet.
Det råder dock ingen tvekan om att en minskning av röran hjälper dig att undvika distraktion och desorganisering. Som sådan är det ett värdigt mål att uppnå. För all del, ha några heliga föremål runt omkring som får dig att känna dig bättre och mindre stressad, men överdriv inte. Rensa är en av de svåraste sakerna att göra för de flesta, och det är inte bara vår fysiska desktops som behöver decluttering, men ofta vår dator desktops också. Om du verkligen kämpar med det kan du prova att använda en minimalistisk DTE som Fluxbox, som inte riktigt tillåter dig att ha något rörigt.
Men mitt i allt detta städning, gå inte överbord. Det finns gott om bra vetenskap som antyder att lite kaos i miljön faktiskt kan bidra till kreativitet. En av de mest citerade bitarna med forskning om detta är en journalpost i Psychological Science av Vohs, Redden & Rahinel för University of Minnesota med titeln Fysisk ordning producerar hälsosamma val, generositet och konventionellitet, medan störning skapar kreativitet. Förmodligen anledningen till att detta är pappersjournalisterna som håller fast vid är att det tydligt drar slutsatsen att: "... deltagare i ett oroligt rum var mer kreativa än deltagare i ett ordnat rum."
Mycket mindre populära är olika åsikter, som Miljöstörning leder till självreglerande misslyckande (Chaye & Zhu, 2014), publicerad i Journal of Consumer Research. Denna studie fann att personer som arbetar i störande miljöer hade nedsatt förmåga att utföra uppgifter.
Så var lämnar detta dig? Ska du arbeta i kaos eller sterilitet? Svaret verkar vara att hitta en balans där det bara är kaotiskt nog för att hålla dig inspirerad, men inte så mycket att du blir distraherad eller har problem med att hitta saker.
Lämna lite rum bakom dig för att öka dina tankar
Det är en bra idé att ha gott om utrymme för att vandra runt när du överväger. Många av de bästa admiralerna och generalerna i historien var kända för den långa tiden de spenderade runt däcket när de planerade stridsstrategier.
Inte bara stridande män följer denna praxis. Många buddhistmunkar förespråkar också "vandringsmeditation" och tror att det hjälper till att främja sinnets klarhet. När du har ett särskilt knotigt programmeringsproblem att lösa kan det hända att det hjälper att sträcka benen lite med en meditativ promenad runt däck. Uppenbarligen här igen kommer brist på röran att hjälpa dig att göra detta utan att hamna på sjukhuset.
Ta en försiktig inställning till kritik av kreativa insatser
Det finns inget fel med konstruktiv kritik, men du måste välja rätt ögonblick och närma dig det på rätt sätt, eller så kan det slå tillbaka genom att göra din personal mindre produktiv i framtiden. Istället för att inspirera dem och ge insikt kan du faktiskt göra dem rädda för att ta risker, vilket är ett bra sätt att döda kreativiteten. Marieke Roskes, i Begränsningar som hjälper eller hindrar kreativ prestanda: en motiverande strategi, ger en ram för hur man ska hantera motivation hos kreativa arbetare, och specifikt också hur man kan undvika oavsiktligt demotivering av dem (Creativity & Innovation Management, Vol 24, Iss 2, 2015).
2. Upprätta en bra SOP
Det finns många iögonfallande trender inom affärsledning och programmeringsprocedurer som låter mycket teoretiskt mer än de visar sig vara i praktiken. Huruvida en viss metod fungerar för dig eller inte beror på ditt mål och vad du personligen anser vara ett framgångsrikt resultat.
Ett exempel på en metod som ett företag jag arbetade för försökte - och lika snabbt tappade - är programmering av par (inte att förväxla med PEAR-programmering). Medan vissa människor verkligen beundrar denna arbetsmetodik och berömmer sin plats i det smidiga utvecklingsparadigmet, fann vi att det var oerhört ineffektivt. Till att börja med krävde det två programmerare för varje arbetsstation, så du betalade dubbelt så mycket för mindre faktiskt utvecklingsarbete. Vi fann också att det var mycket långsammare att arbeta på detta sätt på grund av det ofta stopp / startflödet och tendensen till onödig dialog.
Fördelarna med parprogrammering var att det resulterade i mer naturlig dokumentation och striktare dokumentation. Det gjorde det också lättare att upptäcka buggar och att förslag skulle kunna göras för att skärpa upp en algoritm. Samtidigt skapade emellertid samma fördelar också problem eftersom ibland justeringarna inte var nödvändiga.
En annan risk med detta tillvägagångssätt är att du kan få effekten identifierad av Roskes, där programmerare kan vara tveksamma att prova saker eftersom de inte vill korrigeras. Det kan hända att personlighetskonflikter blossar där en utvecklare är väldigt pedantisk och traditionell, men den andra är mer kreativ och spontan.
Programmerare uppger ofta att de föredrar parprogrammering. Det är möjligt att det beror på att de tycker om den sociala interaktion som det ger, men detta bidrar ingenting till produktionen, utom kanske som en moralisk booster.
Så vad du behöver för att fastställa är vad som verkligen fungerar för dina utvecklare och vad som inte gör det. För de saker som inte fungerar är det bättre att kassera dem, även om de är en mycket trendig praxis. Det som hjälper teamet att göra framsteg är bra. Men om de tyngs ned med en metod som inte passar deras stil kommer det så småningom att leda till problem.
3. Uppmuntra ordentlig dokumentation
Det kan tyckas att verbositet skulle öka ineffektiviteten, men den lilla tid det tar att ge mer detaljer och precision i kommentarer kan spara mycket problem när projektet rullar längs eller genomgår revisioner.
4. Avskräcka onödig dokumentation
Välskriven kod är ofta självdokumenterande. Om det är helt uppenbart vad en funktion gör från det namn du ger det (vilket nästan alltid ska vara fallet), är det överflödigt att lägga till mer beskrivning. Detsamma gäller för variabla namngivnings- och returvärden. Det bör framgå av namnet vad de gör, och i de fall där det inte är möjligt att göra det borde du ta med en beskrivning av dem i kommentarer.
5. Vitt utrymme är din vän
Att använda vitt utrymme på lämpligt sätt i din kod är värdefullt för att underlätta koden att läsa, granska och förstå. Det går hand i hand med god dokumentation och skrivande av självdokumenterande kod. Det borde vara möjligt för alla erfarna programmerare - eller kanske till och med en icke-programmerare - att hämta en kopia av din källkod och omedelbart förstå vad syftet med varje funktion är och hur den fungerar. Helst bör någon kunna lära sig att programmera från ingenting annat än att studera din välskrivna kod.
6. Föredrar enkelhet framför komplexitet
Ju mer komplex du gör din kod, desto svårare kan det vara att lossa den. Ironiskt nog gäller detta för programmering av genvägar, som att använda korthårskonditioner i stället för att skriva ut dem i sin helhet. Det sparar tid i skrivandet, men en mindre erfaren programmerare som kommer in för att granska din kod senare kanske inte förstår dina avsikter.
7. Testa uttömmande
Koden bör testas stegvis och ofta. Innan du distribuerar någonting bör du göra så mycket interna tester som möjligt, även om din första utgåva kommer att betecknas Alpha.
8. Använd versionskontroll
Du måste vara galen för att inte använda versionskontroll på ett större projekt. Utan det är du inte skyddad från dina egna mindre misstag, och det är också riktigt enkelt för en annan gruppmedlem att oavsiktligt (eller avsiktligt) sabotera din kod genom att skriva över den med något som inte behagar dig.
Genom att ta hänsyn till dessa åtta nyckelförslag kommer du att kunna utveckla din egen strategi för att få ut mest effektivitet för dig och alla teammedlemmar du arbetar med. Du behöver inte nödvändigtvis tillämpa dem alla, och vissa kanske inte ens är praktiska för dig, men alla kombinationer av dem kommer sannolikt att leda till att du får ditt arbete med mindre krångel. Ett mer produktivt arbetsflöde kommer att betala för sig själv över tid, även om det bara handlar om stressminskning och ger dig mer tid för dig själv. Det är ett mål som är värt att arbeta mot.
Kommentarer 0 Responses