Verktøy og metoder for bedre koding

Optimalisering og organisering kan bety mange ting, men hva betyr det for deg? Gjør ting raskere, bedre eller mer effektivt? Betyr det å gjøre ting mer programmatisk, forenklet eller bruke verktøy som er mer egnet til jobben?

Vel, med all sannsynlighet betyr det en liten bit av alle disse. Du er sannsynligvis en person som jobber som utvikler eller designer, og prøver stadig å optimalisere arbeidsflyten din - og vel, disse tingene kan sikkert være det du leter etter (minst, litt).

Men vær oppmerksom på at mange tips og teknikker du omfavner, betyr det faktisk veldig lite med mindre du faktisk gjør jobben din. Så, med det for øye, vil jeg gjerne tilby noen av mine favoritt arbeidsflyter og metoder for organisering og optimalisering.

De fleste antar at de bare trenger å holde seg organisert og effektiv hvis de jobber i et lag, fordi det er tross alt, hvis du bare er en person, hvorfor ikke bruke din egen organisasjonsmetode? Vel, det er ikke noe galt med det i seg selv, men du trenger å bruke noen standardiserte teknikker for å få mest mulig ut av din tid. For eksempel, versjonskontrollsystemer.

Også ting som språkoppsett og forenklet språk syntaks verktøy kan være svært nyttig. La oss dykke inn i noen av disse på en mer spesifikk måte, og vær oppmerksom i slutten av artikkelen, vil jeg gå over noen kodeoppsett og verktøy som fokuserer på bestemte språk som jeg føler at de fleste av oss jobber med. Resten skjønner, vil være ganske bredt scoped.

Verktøy

Verktøy er en fin måte å øke hastigheten som du skriver og implementerer kode på. Noen ganger kan de være en distraksjon, men oftest kan de være svært hjelpsomme. Jeg snakker hovedsakelig om de som jeg har vokst til å elske gjennom årene, men det er mange flere der ute som jeg ikke vil dekke - så føl ikke at dette er en uttømmende liste, men heller en liste over mulige ideer. Tenk på dette, helst som et hoppende punkt

Tekstredigerere

Tekstredaktører er et tema for mye kontrovers. Jeg mener, la oss innse det, vi tilbringer det meste av dagen i dem, og på grunn av det har vi ofte svært partiske preferanser. Jeg er heller ikke utenfor denne sirkel av forspenning, heller ikke forvent en journalistisk forståelse av alle tekstredaktører i verden her. Men heller, noen av mine favoritter og hvorfor jeg liker dem.

Når du leser dette skjønt, husk at jeg bruker mer enn ett tekstredigeringsprogram og for meget spesifikke formål. Jeg vil ofte holde noen tekstredigerere stengt med en klientfiler inni dem. Hva jeg mener med det er, i Sublime Text 2, kan jeg jobbe med et skinnprosjekt og ha som 14 faner hentet der inne at når jeg starter Sublime, åpner den dem alle sammen. Og så, for ikke å forstyrre det, holder jeg faktisk en klients nettsted. Jeg kan gjøre en HTML- eller CSS-design for i TextMate. Og med skriving holder jeg vanligvis det i enten en separat TextMate-katalog i Dropbox, eller i Scrivener. Så jeg holder alt skilt på den måten. Så, selvfølgelig, snakker jeg om Sublime Text 2 (tilgjengelig for Windows og Mac) og TextMate (kun tilgjengelig for Mac).

Textmate

TextMate er en av de beste redaktørene der ute, for Mac. Den har en forenklet design, et vakkert grensesnitt, og et kraftig funksjonssett. Men en av de sanne identifikatorene for produktets kvalitet er samfunnet bak det. Det er voldsomt. De lager bunter, skript og stort sett alt du kan forestille deg.

Men husk at MacroMates (skaperne) har blitt savnet virkelig i utviklingen. Nå kan det være litt overdrevet, men det hadde vært år etter år før de opprettet den andre versjonen som adresserte mange menneskers bekymringer og problemer. Med det sagt, er det fortsatt et vakkert redaktør og et sted jeg elsker å gå for å skrive Markdown eller kode av nesten hvilken som helst type. Jeg bruker den til alt jeg kan, når jeg ikke bruker Sublime Text 2. Den har også en vakker skrifttype, og mange har skrevet bøker, artikler, hele webapps alle med denne vakre redaktøren - og med god grunn. Hvorfor går du ikke sjekke hvorfor, og se for deg selv .

Sublim tekst 2

Sublime Text 2 er en flott tekstredigerer, men jeg er ikke sikker på hvilken type shorthand å referere til det av - så jeg vil bare si Sublime. Sublime, som det var, er en flott redaktør. Jeg har aldri brukt den før versjon 2, men jeg vil si at det er bare herlig. Jeg er ikke så sikker på forskjellene - annet enn skrifttypen og standard bakgrunnsfarge - mellom den og TextMate. Jeg vil imidlertid si at jeg elsker skrifttypen som den bruker ( jeg vet, tilsynelatende ubetydelig - men viktig for meg ), og jeg elsker også måten den gjør på fanebladet.

I stedet for å snakke om funksjoner, vil jeg i stedet snakke om noen andre ting. En ting om det som er litt vondt, før du hopper inn i andre ting , er at du ikke kan kalle det fra kommandolinjen like enkelt som TextMate. Med TextMate skriver du bare "kompis", og den åpner den katalogen i sin lille prosjektlader. Den fungerer bare perfekt. Selv om du fortsatt finner Sublime nyttig uten denne funksjonen. Jeg føler bare at det å jobbe i Sublime er en fryd. Jeg er ikke sikker på hvorfor, kanskje det fungerer på en mørk bakgrunn, er det fint, men jeg liker bare å jobbe i Sublime. Jeg bruker den når jeg trenger å få en massiv mengde arbeid gjort. Det er et massivt skinnerprosjekt - eller lignende. Jeg tror du vil finne det nyttig også, så Sjekk det ut .

Kodeorganisasjon og metodikker

Organisasjonen er et tema rundt som det er mye debatt. Mange mennesker virkelig foretrekker ikke kompliserte systemer for å hjelpe dem å holde seg organisert, men i virkeligheten kan en del komplikasjoner på kort sikt hjelpe deg å holde orden på lang sikt. Jeg vet det høres ikke-intuitivt ut, men det er veldig nøyaktig. Spesielt når det gjelder versjonskontrollsystemer. Ta det fra meg, noen som stolte på FTP, og jeg gjør det noen ganger , og jeg har aldri vært lykkeligere med et versjonskontrollsystem.

Bruke kildekontroll er en fin måte å holde orden på. Å sørge for at du holder sikkerhetskopier av utviklingsprosessen din, er veldig viktig, og det vil egentlig ikke bli kuttet i det lange løp, og overlate det til ulike mappehierarkier. Jeg mener, det kan virke bra når datamaskinen din kjører, men hvis du har en krasj eller harddiskfeil, blir du litt fullført tapt.

Hva kan du gjøre for å løse dette selv? Vel, du kan bruke et versjonskontrollsystem som tar et øyeblikksbilde av utviklingskatalogen din i løpet av tiden du jobber. Å bruke dette er en veldig fin måte å ha en konstant ny versjon og en konstant tilgang til backup hvis det skulle være feil eller noe slags tap. Det er også bare bra å ha en periode. Jeg mener, tenk på hvor mange ganger du var som "Jeg lurer på hvordan jeg gjorde det, eller implementerte den funksjonen." Vel, nå vet du bokstavelig talt.

Og når det gjelder versjonskontrollsystemer, er git en fin måte å gjøre dette på. Du trenger ikke engang noen kjennskap til systemer som Mercurial eller Subversion for å komme i kontakt med VC-systemet som er Git. Faktisk, jeg hadde ingen erfaring med disse systemene i det hele tatt, og kom opp med Git ganske fort faktisk.

Du kan følge kommandoene direkte fra GitHub når du åpner et Repository, og så legger du bare inn dem i terminalen din, og du vet bokstavelig talt nesten alt du trenger. Etterpå er alt du trenger å gjøre, å gjøre kommandoen for kommandoen, når som helst du vil gjøre en endring. Vær imidlertid oppmerksom på at hvis du allerede har dev-filer i mappen, kan du bruke "git add." I stedet for eksempelet "berør README" for å legge til alle filene dine. Svært lignende konsept for å åpne et TextMate eller vindu i terminalen, hvor perioden angir en slik handling .

Nå, før jeg er ferdig på denne delen, vil jeg gjerne si at jeg aldri har brukt Mercurial eller Subversion, men faktisk er de mulige alternativer og er ganske populære blant visse folkemengder. Det er enda nettsteder som lar deg være vert for filene dine fra slike systemer som SourceForge, akkurat som GitHub gjør.

Før jeg er ferdig, vil jeg også nevne en siste ting. En Git GUI som vil hjelpe prosessen litt. Og det er, GitBox . Det er et veldig bra program, og i utgangspunktet alt du trenger å gjøre for å bruke det er satt opp en Repository på samme måte som du ville andre gang (fra kommandolinjen). Deretter åpner du bare GitBox og legger i den aktuelle katalogen fra datamaskinen din, og du er bokstavelig talt alt satt.

Når som helst du gjør en endring, blir det automatisk lagt merke til og vist i GitBox, og du kan deretter gå om å legge igjen en kommentar til din forpliktelse og deretter Skyve den. Vær imidlertid oppmerksom på at metoden går: "endre -> kommentarer (hvis nødvendig / noen) -> commit -> push".

Pass på at du bare presser etter at du har begått deg, ellers vil ingenting skje. Og hvis du jobber med et lag, må du sørge for at du trekker deg før du gjør kommentarer, begår eller noe, for å være sikker på at du holder deg borte fra eventuelle feil du måtte ha.

Supersets, og kodeverktøy

Et superset, er ofte definert av en kode syntaks eller ekstrapolering som sitter på toppen av språket under den. Eksempler på dette kan være CoffeeScript sitter på toppen av JavaScript - eller Node.js sitter på toppen av Node (selv om det kan betraktes som et bibliotek også). Det kan også beskrives som noe som SASS eller LESS sitter på toppen av CSS som faktisk legger til funksjonalitet og nye metoder for å håndtere ting.

SASS, legger også til en ny tilgjengelig syntaks som kan brukes på samme måte som CoffeeScript tilbyr til JavaScript. Et godt eksempel på et bibliotek vil være jQuery på JavaScript, selvfølgelig. Det er noe vi alle sikkert vet og elsker nå, men det er en god påminnelse om at vi bruker et bibliotek og / eller superset.

Nå vil jeg ikke snakke om hvert bibliotek i verden - fordi jeg bare ikke har brukt dem alle. Jeg vil heller ikke at denne artikkelen skal fokusere på bestemte biblioteker. Som en del har jeg valgt å snakke om supersets i stedet, og kodeverktøy for visse språk som de fleste av oss bruker. For eksempel HTML, CSS og Ruby on Rails spesielt.

I stedet for å hoppe rett inn, la oss ta en titt på noen eksempler for å forstå hvorfor du ville bruke disse verktøyene og / eller supersets. For eksempel, la oss si at du jobber i CSS og HTML i Rail (med utvikleren din kanskje eller mens du er utvikler), og du føler at du sparer tid for å skrive så mye ERB (som er måten du legger til Ruby-kode i skinner du vil skrive i skinner - mer på det her ).

Vel, det ville være en god ting å gjøre HAML for å øke hastigheten på å skrive HTML-koden, og for å øke hastigheten på å implementere Ruby-koden i den. HAML er en superset, slags HTML, som lar deg skrive HTML-kode uten å måtte bekymre deg for å lukke kodene dine, og det gir deg også mulighet til å bruke hvitt plass til din fordel - mye som Python. La oss ta en titt på et eksempel.

Og det skaper:

Du kan sikkert se hvordan det vil spare deg for mye tid. Det er også veldig morsomt og rent å skrive. Det er en glede, i all ærlighet.

Nå, hva med det CSS? Du kan spare mye tid på å skrive det også! SASS tilbyr en svært lik funksjonalitet, men uten å lære en ny form for syntaks. Så med en delmengde av SASS (en delmengde av superset) kan du faktisk bruke hvit-rom til din fordel. Så la oss ta en titt på hva det er.

Vel, i SASS vil dette se ut som:

Som du kan se, i SASS trenger vi ikke {} eller de avsluttende halvkolonene. Vi bruker også den hvite plassen til å betegne at skriftstørrelsen er et barnelement i "wrapper" -klassen.

medLet si deg Du antar også at bare folk som gjør backend dev bruker versjoning kontrollsystemer, men faktisk burde vi alle vite nå, det er ikke tilfelle. Du kan bruke Git og Github til å holde oversikt over hver gang du gjør en kodeplikter, og med verktøy som Gitbox har det aldri vært enklere.

Nå, selvfølgelig, ikke alle dere skal bruke Ruby on Rails når du skriver kode - men jeg antar at en god del av dere jobber med folk som bruker den. Uansett, la oss dekke noen løsninger for en solo person som ikke arbeider eller bruker Rails på noen måte. For CSS LESS er en god løsning på det. Zen Coding er også en løsning for alle som ikke jobber med Rails, men ønsker bare å øke hastigheten der de skriver standard HTML-koder. Det er veldig veldig nyttig for alle. Zen koding er veldig lett å begynne å jobbe med. Bruk ting som Zen Coding for å lette HTML-kodene dine. For eksempel skriver du:

du får:

Du kan også fortsatt bruke MINDRE for å få mixins og variabler og slikt. Det er ganske enkelt å jobbe med.

Du vil kanskje også ta et fint verktøy for å jobbe i terminalen kalt Go2Shell. Den er tilgjengelig på mac app butikken gratis. Du kan bare bruke det når du må åpne terminalen i en bestemt katalog som er ganske vanlig. Så for å bruke det, vil du bare navigere til den katalogen i finneren din og bare klikke på programmet go2shell og boom din terminal åpnes for den filen. Det er utrolig. Og det vil om å pakke det opp for nå, hold deg innstilt etter sommeren, men for en kort liste over steder å besøke fra artikkelen.

Det er noen av de mest nyttige supersettene og verktøyene jeg kjenner til for å få noen av de beste resultatene. Jeg vil også nevne at dette ikke var en uttømmende eller fullstendig liste på noen måte, så vær så snill å finne ut mer om det. Og som lovet, her er noen av koblingene til det vi berørte på i artikkelen. GitBox , GitHub , Kompass , SASS , HAML , MINDRE , Ruby on Rails . God jakt!

• ← Roundup av nettsidene for enkelt sider
• Ekspert Website Monitoring gratis! →