Kode raskere: 53 tips fra proffene

Vil du vite hvordan du programmerer raskere slik at du kan levere programvare raskere? Ja, hvem gjør ikke det? Internett er fullt av tips for utviklere-hundrevis, tusenvis, kanskje til og med millioner av dem. Problemet er, det er langt mer der ute enn noen har tid til å lese, så jeg har kokt dem ned for deg.

her er 53 tips som representerer det aller beste rådet jeg har funnet der ute. Men før jeg forteller deg hva jeg fant, må jeg forklare hva jeg mener med «programmering raskere» og » tips.»

problemet med «raskere»

for å kode raskere må man være effektiv; det vil si ingen bortkastet innsats eller bevegelse. Dette kan bety alt fra å skrive til verktøy for å tenke. Men det meste av vårt arbeid som programmerere er ikke å skrive—eller kompilere-det er å tenke. For å tenke raskere må du lære mer mønstre og relasjoner. Dette er kunnskap og visdom som erfaring bygger. Hva du trenger å gå raskere vil endre seg over tid.

problemet med»tips»

de fleste tipsene jeg leser, gjelder bare på visse punkter langs reisen min, og gjelder ikke nødvendigvis for alle. Mange av disse faller inn i kategoriene «personlig reise» eller «hva fungerte for meg». Men min vei er sannsynligvis ikke din vei. Mens noen av de mekaniske tingene som fungerer for meg, vil trolig fungere for deg, kan mange av domene-og mønstervalgene jeg har laget, ikke være til nytte.

de mekaniske tingene er ganske enkle å optimalisere; alternativene er begrensede. Men læring ting har ingen grenser. Ingen vil noen gang vite alt. Du må ta strategiske og taktiske valg, og være forberedt på å dra nytte av muligheter når de oppstår.

nytten av tips faller av som en funksjon av spesifisitet. De mer spesifikke tipsene gjelder ikke for alle, men generelle tips er også, vel, generelle. De er mye vanskeligere å slå til handling. Så hva vil du egentlig når du sier at du vil » gå raskere?»Jeg skal fortelle deg.

det du vil ha er flow

hva hver programmerer ønsker, spesielt I devops-tiden, er flow. Flow state maksimerer gjennomstrømning og øker glede ved å inkorporere akkurat det rette nivået av utfordring; man forblir fullt engasjert i øyeblikket og i arbeidet(dette må ikke forveksles med Ballmer Peak). Opprettholde flyt tilstand krever et egnet miljø og friksjonsfri prosess.

Strømningstilstand når paring er som om hver av dere har en ekstra hjerne. Dessverre er mange utviklermiljøer, for eksempel åpne kontorer, uvennlige å flyte.

alternativene kan være begrenset

når du finner noe sub-optimal om prosessen, eller deg selv, valg av hvordan å løse slike begrensninger er begrenset:

• Ignorer det. Kanskje det blir bedre av seg selv.
• Unngå det. Er det virkelig nødvendig?
• Automatiser det. Få maskinen til å gjøre det.
• Deleger det. Sjelden mulig, dette passerer pengene. Men det er et legitimt alternativ når det er tilgjengelig.
• Slip det ned. Vi må alle gjøre dette fra tid til annen (daglig). Noen jobber er større enn andre.

hvis skrivingen din er tregere enn du vil, ta litt tid og nivå opp. Hvis ditt integrerte utviklingsmiljø er forvirrende og unhelpful (eller kanskje for nyttig), prøv noe annerledes eller enklere. Hvis du ikke kan komme vekk fra det, lær mer om det; du kan finne en annen måte, eller i det minste lære grensene.

det er mange måter å lære på. Google er din venn, som er bøker, videoer, blogginnlegg, Stack Overflow spørsmål, og selvfølgelig andre mennesker. Noen ting du vil lære kan være skjult; andre kan være større enn de ser ut. Balanse fordel med innsats og vær tålmodig med deg selv. Feire hver prestasjon og fortsett å bevege deg.

Topp tips for programmering raskere

en måte å gruppere og se på tipsene nedenfor er ved å bruke noen høyt nivå kategorier som en måte å trekke interessante generaliseringer fra samlingen:

• Reflektere. Hva vil du, hva gjør du egentlig; inkluderer måling og optimalisering.
• Flyt. Ingen friksjon fra verktøy, prosesser, miljø eller kunnskap; søk kontinuerlig utfordring, men ikke for mye.
• Lær. Grunnleggende: språk, verktøy, mønstre, praksis, etc., fra alle (spesielt de som er villige til å undervise); lær hvordan du lærer, og lær kontinuerlig.
• Undervise. Lær andre. Å måtte forklare ting styrker forenkling, og transformasjonen fra tanker til verbale eller visuelle uttrykk gir innsikt.
• Uttrykk og utforsk. Se utenfor dine vanlige plikter; tegne, skrive, blogg, gå til meetups, delta og gi presentasjoner, snakke Med Wilson volleyball om nødvendig.

tipsene nedenfor er bare datapunkter, ting å tenke på—ikke et jukseblad for livet eller en oppgaveliste for din karriere som programmerer. Jeg startet med en liste med 183 tips, grupperte dem i kategorier, tildelt en prioritet basert på repetisjon og personlig bias, og tok de øverste få fra hver.

det er riktig, bias. Jeg vet hva som gjør en utvikler god eller rask programmerer, så alt jeg leser jeg filtrert gjennom min bias. Spesielt er jeg partisk mot:

• Agile metoder.
• Domenedrevet design.
• Automatisert testing.
• Kontinuerlig forbedring.
• Minimale løsninger.
• Friksjonsfritt verktøy.
• Arbeide i flyt tilstand så mye som mulig.

Og jeg er helt enig Med Robert C. «Onkel Bob» Martins uttalelse om «heftig middelmådighet»:

«den eneste måten å gå fort er å gå bra. Hver gang du gir etter for fristelsen til å handle kvalitet for fart, senker du farten. Hver gang.»

Ta følgende tips (og alt annet du leser på internett) med et saltkorn. Behold og tilpass det som fungerer; forkast det som er ubrukelig.

og her er mitt tips for programmering raskere: Fokus på kvalitet, og hastighet vil følge.

Refleksjon er nøkkelen

Refleksjon er nøkkelen til selvforbedring:

• Kontinuerlig forbedre beslutningsprosessen; lære av dine feil uten bebreidelse.
• Eliminer blinde flekker i din forståelse av hele omfanget av søknaden din og dens utførelsesmiljø.
• ikke jage halen; identifisere og eliminere tid synker.

mål objektivt

noen ganger vet du hva din største begrensning er, og noen ganger må du måle den.

• Vurder å gjøre en detaljert revisjon av deg selv mens du jobber i et par dager.
• det er akkurat som å optimalisere ethvert stykke kode. Logg alt, identifisere hotspots og forbedre dem.
• Hvor går tiden din? Mange programmerere bruker langt mer tid på å lese kode enn å skrive kode; hvordan lærer du å lese kode raskere?

Praksis, praksis, praksis

Det er ingen å komme seg rundt noe nivå av praksis, på en rekke utfordringer.

• Skriv mye programvare.
• Skriv større programmer.
• Skriv omtale-klar kode fra get-go.
• det er mange steder å øve, inkludert topcoder.com, prosjekt Euler, hackerrank.com. Velger en og komme i gang.

Design for suksess

Læring design teknikker bør være en gitt, en del av mestring av din tenkning verktøy. I tillegg:

• Forstå brukeren; forstå deres problem, det virkelige problemet; og deretter løse det. Kunnskap om domenet hjelper enormt.
• Snakk med kolleger og domeneeksperter om problemet, løsningen og designen.
• Reduser kognitiv belastning ved å tegne eller skrive mens du tenker og koder.
• når du utformer for lang levetid og vedlikehold, husk at data overlever kode.
• Vet når du skal gjenoppfinne hjulet, og når du ikke skal (vanligvis ikke).
• Navngi ting målrettet; dette er den eneste lenken fra koden tilbake til domenet.

Spikre prosessen

vi bruker mye tid i prosesser av vår egen konstruksjon; ikke vær redd for å endre dem.

• Gjør feil umulig ved design. Mislykkes raskt, bruk unntak i stedet for nullkontroller, bruk typesystemet til å forhindre datafeil og bruk automatisert testing.
• hvis du har et tap på hvor du skal begynne, start med den delen du forstår best.
• Skriv koden som faktisk ville lage et produkt først, uansett hvor dumt eller lite produktet er.
• ikke ignorere feil; hver feil betyr noe.
• Følg en smidig tilnærming til utvikling.
• Trekk ut abstraksjoner bare hvis de gir mening og faktisk vil bli gjenbrukt.
• Stå på skuldrene til giganter; bruk open source-biblioteker, tredjepartsløsninger og så videre.
• Optimaliser for enkelhet; den beste koden er koden du ikke trenger å skrive.
• Automatiser testing og praksis testdrevet utvikling (tdd)
• Bruk smarte verktøy som IDEs, kodegenereringsverktøy, etc., men vær ikke redd for å skifte ned hvis de kommer i veien.
• Vær ekstremt kjent med ditt språk og standardbibliotek. Jo mindre tid du bruker på å krype rundt i dokumentasjonen, desto bedre.
• Bruk kildekontroll – selv på egen hånd.
• Bruk en profiler. Optimaliser bare det som er nødvendig
• Lær å berøre-type. Programmerere skriver mye, og ikke bare kode; dette reduserer den kognitive belastningen ved å skrive til null, og forbedrer hastigheten og nøyaktigheten

Skaper det rette arbeidsmiljøet

Konstante avbrudd, ubehagelige omstendigheter og endeløse møter motvirker flyt.

• Sørg for at du er i et miljø som ikke vil distrahere deg; gjør det umulig for distraksjoner å forstyrre deg.
• Kjenn deg selv, og arbeid i din topptid — ikke noen andres.

Utforsk utenfor jobben

Ikke alt du kanskje vil vite er på kontoret eller På Internett.

• Utsett deg selv for nye verktøy og teknikker. Hold det som fungerer.
• Arbeid på sideprosjekter og åpen kildekode-prosjekter.

Hold det sunt

Døde mennesker skriver ingen kode. Syke mennesker skriver dårlig kode. Ta vare på deg selv.

• Kjenn verdien av å gå bort fra koden din.
• Få mer søvn, spis bedre og arbeid færre timer.
• Meditere.

Utvikle gode læringsvaner

Læring er en livslang prosess for programmerere, men vi advarte: internett er fullt av skinnende ting.

• Mestre grunnleggende: programmering paradigmer og praksis SOM TØRR (ikke gjenta deg selv) OG OG SOLID (enkelt ansvar, åpen-lukket, Liskov substitusjon, grensesnitt segregering og avhengighet inversjon)FOR OOP), mønstre og anti-mønstre, algoritmer, datateori, grafteori, etc.
• Lær ved å gjøre. Spill alltid med koden mens du lærer.
• Finn en mentor.
• Utforsk forskjellige måter å lære på for å se hva som fungerer for deg.

Kvalitet er ikke konstant

Kvalitet dekker mye bakken, fra lesbarheten av koden til sin modulære struktur og kompleksitet, til hvor godt det uttrykker sine domene intensjoner.

• Fokus på kvalitet, ikke hastighet.
• Godta at koden «kvalitet» til enhver tid er » det beste du kan gjøre med det du har og vet.»
• gjør alltid ditt beste; det er god praksis.
• bare i ekstrem (dvs. prototyping/utforske / kaste bort kode) og midlertidige omstendigheter bør du la kvaliteten på koden din falle under nivået av «det beste du kan gjøre «(og du bør føle deg litt skamfull over å gjøre det.)

Soft skills matter

jeg fant ikke mange tips om folks ferdigheter, men folk er ganske uunngåelig; de jeg fant var ganske hjelpsomme.

• Å Vite hvordan du samhandler med mennesker, vil la deg lære av og lære de rundt deg med mindre friksjon og mer glede.
• Lære å skrive og snakke tydelig vil hjelpe deg å få dine ideer over raskere.

Gå videre og kode

så det er det, min oppsummering av de beste rådene der ute for programmering raskere. Følg disse tipsene, og du vil være godt på vei til å forbedre dine programmeringsferdigheter-og koding raskere.