vill du veta hur du programmerar snabbare så att du kan leverera programvara snabbare? Visst, vem gör det inte? Internet är fullt av tips för utvecklare—hundratals, tusentals, kanske till och med miljoner av dem. Problemet är att det finns mycket mer där ute än någon har tid att läsa, så jag har kokat ner dem för dig.
här är 53 tips som representerar de allra bästa råd jag har hittat där ute. Men, innan jag berätta vad jag hittade, jag måste förklara vad jag menar med ” programmering snabbare, ”och” tips.”
- problemet med ”snabbare”
- problemet med ”tips”
- vad du vill ha är flöde
- dina alternativ kan vara begränsade
- Topptips för att programmera snabbare
- reflektion är nyckeln
- mät objektivt
- öva, öva, öva
- Design för framgång
- spika processen
- skapa rätt arbetsmiljö
- utforska utanför arbetet
- håll det friskt
- utveckla goda inlärningsvanor
- kvalitet är inte konstant
- Soft skills matter
- gå vidare och koda
problemet med ”snabbare”
för att koda snabbare måste man vara effektiv; det vill säga ingen bortkastad ansträngning eller rörelse. Detta kan betyda allt från att skriva till verktyg för att tänka. Men det mesta av vårt arbete som programmerare skriver inte eller sammanställer—det tänker. För att tänka snabbare måste du lära dig mer mönster och relationer. Detta är den kunskap och visdom som erfarenheten bygger. Vad du behöver gå snabbare kommer att förändras över tiden.
problemet med ”tips”
de flesta tips jag läser gäller bara vid vissa punkter längs min resa och gäller inte nödvändigtvis för alla. Många av dessa faller i kategorierna ”personlig resa” eller ”vad som fungerade för mig”. Men min väg är förmodligen inte din väg. Medan några av de mekaniska saker som fungerar för mig förmodligen kommer att fungera för dig, kan många av de domän-och mönsterval jag gjorde inte vara till nytta.
de mekaniska grejerna är ganska lätta att optimera; alternativen är begränsade. Men lärandet har inga gränser. Ingen kommer någonsin att veta allt. Du måste göra strategiska och taktiska val och vara beredd att utnyttja möjligheterna när de uppstår.
användningen av tips faller av som en funktion av specificitet. De mer specifika tipsen gäller inte alla, men allmänna tips är också, ja, allmänt. De är mycket svårare att förvandlas till handling. Så vad vill du verkligen när du säger att du vill ” gå snabbare?”Jag ska berätta.
vad du vill ha är flöde
vad varje programmerare vill ha, särskilt i DevOps era, är flöde. Flow state maximerar genomströmningen och ökar njutningen genom att integrera precis rätt nivå av utmaning; man förblir helt engagerad i ögonblicket och i arbetet (detta ska inte förväxlas med Ballmer Peak). Att upprätthålla flödestillstånd kräver en lämplig miljö och friktionsfri process.
Flödestillstånd när parning är som att var och en av er har en extra hjärna. Tyvärr är många utvecklarmiljöer, som öppna kontor, ovänliga att flyta.
dina alternativ kan vara begränsade
när du hittar något suboptimalt om din process, eller dig själv, är valet av hur du hanterar sådana begränsningar begränsade:
- ignorera det. Kanske blir det bättre på egen hand.
- undvik det. Är det verkligen nödvändigt?
- automatisera det. Låt maskinen göra det.
- delegera det. Sällan möjligt, detta passerar pengarna. Men det är ett legitimt alternativ när det är tillgängligt.
- slipa ner det. Vi måste alla göra det då och då (dagligen). Vissa jobb är större än andra.
om din typning är långsammare än du vill, ta lite tid och nivå upp. Om din integrerade utvecklingsmiljö är förvirrande och ohjälpsam (eller kanske för hjälpsam), prova något annat eller enklare. Om du inte kan komma ifrån det, lära dig mer om det; du kan hitta ett annat sätt, eller åtminstone lära dig gränserna.
det finns många sätt att lära sig. Google är din vän, liksom böcker, videor, blogginlägg, Stack Overflow-frågor och naturligtvis andra människor. Vissa saker du vill lära dig kan vara dolda; andra kan vara större än de verkar. Balansera nytta med ansträngning och ha tålamod med dig själv. Fira varje prestation och fortsätt flytta.
Topptips för att programmera snabbare
ett sätt att gruppera och titta på tipsen nedan är att använda några högnivåkategorier som ett sätt att dra intressanta generaliseringar från samlingen:
- reflektera. Vad vill du, vad gör du faktiskt; inkluderar mätning och optimering.
- flöde. Ingen friktion från verktyg, processer, miljö eller kunskap; söka ständig utmaning men inte för mycket.
- lär dig. Grundläggande: språk, verktyg,mönster, praxis etc., från alla (särskilt de som är villiga att undervisa); lär dig hur du lär dig och lär dig kontinuerligt.
- undervisa. Lär andra. Att behöva förklara saker tvingar förenkling, och omvandlingen från tankar till verbala eller visuella uttryck ger insikter.
- Express och utforska. Titta utanför dina normala arbetsuppgifter; rita, skriva, blogg, gå till meetups, delta och ge presentationer, prata med Wilson volleyboll om det behövs.
tipsen nedan är helt enkelt datapunkter, saker att fundera över—inte ett fuskblad för livet eller en att göra-lista för din karriär som programmerare. Jag började med en lista med 183 tips, grupperade dem i kategorier, tilldelade en Prioritet baserad på repetition och personlig bias och tog de bästa få från var och en.
det är rätt, bias. Jag vet vad som gör en utvecklare bra eller snabb programmerare, så allt jag läste filtrerade jag genom min bias. Specifikt, Jag är partisk mot:
- agila metoder.
- Domändriven design.
- automatiserad testning.
- kontinuerlig förbättring.
- minimala lösningar.
- friktionsfria verktyg.
- arbeta i flödestillstånd så mycket som möjligt.
och jag håller starkt med Robert C. ”Uncle Bob” Martins uttalande om ”häftig medelmåttighet”:
”det enda sättet att gå fort är att gå bra. Varje gång du ger efter för frestelsen att handla kvalitet för hastighet, saktar du ner. Varje gång.”
ta följande tips (och allt annat du läser på internet) med ett saltkorn. Håll och anpassa det som fungerar; kassera det som är värdelöst.
och här är mitt tips för programmering snabbare: fokus på kvalitet, och hastigheten kommer att följa.
reflektion är nyckeln
reflektion är nyckeln till självförbättring:
- ständigt förbättra din beslutsprocess; lära av dina misstag utan förebråelse.
- eliminera blinda fläckar i din förståelse av hela tillämpningsområdet för din ansökan och dess exekveringsmiljö.
- jaga inte din svans; identifiera och eliminera tids sänkor.
mät objektivt
ibland vet du vad din största begränsning är, och ibland måste du mäta den.
- överväg att göra en detaljerad granskning av dig själv när du arbetar i ett par dagar.
- det är precis som att optimera vilken kod som helst. Logga allt, identifiera hotspots och förbättra dem.
- Vart tar din tid vägen? Många programmerare spenderar mycket mer tid på att läsa kod än att skriva kod; Hur lär du dig att läsa kod snabbare?
öva, öva, öva
Det går inte att komma runt någon nivå av övning, på olika utmaningar.
- skriv massor av programvara.
- skriv större program.
- Skriv recension-klar kod från get-go.
- det finns gott om platser att träna, inklusive topcoder.com, projekt Euler, hackerrank.com. väljer en och går.
Design för framgång
lärande designtekniker bör vara en given, en del av behärskningen av dina tänkande verktyg. Dessutom:
- förstå användaren; förstå deras problem, det verkliga problemet; och sedan lösa det. Kunskap om domänen hjälper oerhört.
- prata med kollegor och domänexperter om problemet, lösningen och designen.
- minska kognitiv belastning genom att rita eller skriva medan du tänker och kodar.
- när du utformar för livslängd och underhåll, kom ihåg att data överlever kod.
- vet när du ska återuppfinna hjulet, och när du inte ska (vanligtvis inte).
- namn saker målmedvetet; detta är den enda länken från koden tillbaka till domänen.
spika processen
vi spenderar mycket tid i processer av vår egen konstruktion; var inte rädd för att ändra dem.
- gör buggar omöjliga genom design. Misslyckas snabbt, använd undantag istället för null-kontroller, Använd typsystemet för att förhindra datafel och använd automatiserad testning.
- om du är på en förlust på var du ska börja, börja med den del som du förstår bäst.
- skriv koden som faktiskt skulle göra en produkt först, oavsett hur dum eller liten den produkten är.
- ignorera inte fel; varje fel betyder något.
- Följ en smidig inställning till utveckling.
- dra ut abstraktioner endast om de är vettiga och faktiskt skulle återanvändas.
- stå på jättarnas axlar; använd open source-bibliotek, tredjepartslösningar och så vidare.
- Optimera för enkelhet; den bästa koden är koden du inte behöver skriva.
- automatisera testning och öva testdriven utveckling (TDD)
- Använd smarta verktyg som IDEs, kodgenereringsverktyg etc., men var inte rädd för att flytta ner om de kommer i vägen.
- var mycket bekant med ditt språk och standardbibliotek. Ju mindre tid du spenderar krypa runt i dokumentationen, desto bättre.
- använd källkontroll — även på egen hand.
- använd en profiler. Optimera bara vad som är nödvändigt
- lär dig att röra-typ. Programmerare skriver mycket, och inte bara kod; detta minskar den kognitiva belastningen att skriva till noll och förbättrar hastighet och noggrannhet
skapa rätt arbetsmiljö
konstanta avbrott, obekväma omständigheter och oändliga möten avskräcker flöde.
- se till att du befinner dig i en miljö som inte kommer att distrahera dig; gör det omöjligt för distraktioner att avbryta dig.
- Känn dig själv och arbeta under din topptid-inte någon annans.
utforska utanför arbetet
inte allt du kanske vill veta är på ditt kontor eller på Internet.
- exponera dig själv för nya verktyg och tekniker. Behåll det som fungerar.
- arbeta med sidoprojekt och open source-projekt.
håll det friskt
döda människor skriver ingen kod. Sjuka människor skriver dålig kod. Ta hand om dig själv.
- vet värdet av att gå bort från din kod.
- få mer sömn, äta bättre och arbeta färre timmar.
- meditera.
utveckla goda inlärningsvanor
lärande är en livslång process för programmerare, men vi varnade: internet är fullt av glänsande saker.
- behärska grunderna: programmeringsparadigmer och praxis som torr (upprepa inte dig själv) och och SOLID (enskilt ansvar, öppet stängt, Liskov-substitution, gränssnittssegregering och beroendeinversion)för OOP), mönster och antimönster, algoritmer, datateori, grafteori etc.
- lär dig genom att göra. Spela alltid med koden medan du lär dig.
- hitta en mentor.
- utforska olika sätt att lära sig för att se vad som fungerar för dig.
kvalitet är inte konstant
kvalitet täcker mycket mark, från kodens läsbarhet Till dess modulära struktur och komplexitet, till hur väl den uttrycker sina domänintentioner.
- fokusera på kvalitet, inte hastighet.
- acceptera att koden ” kvalitet ”vid varje givet ögonblick är” det bästa du kan göra med vad du har och vet.”
- gör alltid ditt bästa; det är bra praxis.
- endast i extrema (dvs. prototyping/exploring / throw-away code) och tillfälliga omständigheter ska du låta kvaliteten på din kod sjunka under nivån ”det bästa du kan göra” (och du borde känna dig lite skämd över att göra det.)
Soft skills matter
jag hittade inte många tips om människors färdigheter, men människor är ganska oundvikliga; de jag hittade var ganska hjälpsamma.
- att veta hur man interagerar med människor låter dig lära av och lära dem omkring dig med mindre friktion och mer glädje.
- att lära sig att skriva och tala tydligt hjälper dig att få dina tankar snabbare.
gå vidare och koda
så det är det, min sammanfattning av de bästa råd där ute för programmering snabbare. Följ dessa tips och du kommer att vara på god väg att förbättra dina programmeringsförmåga—och kodning snabbare.