Optimering og organisation kan betyde mange ting, men hvad betyder det for dig? Gør ting hurtigere, bedre eller mere effektive? Betyr det at gøre ting mere programmatisk, simplistisk eller ved at bruge værktøjer, som er mere egnede til jobbet?

Tja, med stor sandsynlighed betyder det en lille smule af alle disse. Du er sandsynligvis en person, der arbejder som udvikler eller designer, og forsøger konstant at optimere din arbejdsgang - og godt, disse ting kunne helt sikkert være det du leder efter (i hvert fald lidt).

Men husk på, at mange tips og teknikker du omfavner, men det betyder faktisk meget lidt, medmindre du rent faktisk gør dit arbejde. Så med det for øje vil jeg gerne tilbyde nogle af mine foretrukne arbejdsgange og metoder til organisation og optimering.

De fleste mennesker antager, at de kun skal holde sig organiserede og effektive, hvis de arbejder i et hold, for når alt kommer til alt, hvis du kun er en person, hvorfor ikke bruge din egen organisatoriske metode? Nå er der ikke noget galt med det i sig selv, men du skal bruge nogle standardiserede teknikker for at få mest muligt ud af din tid. For eksempel versionskontrolsystemer.

Også ting som sprog supersets og simplistiske sprog syntaks værktøjer kan være meget nyttige. Lad os dykke ind i nogle af disse på en mere specifik måde, og vær opmærksom i slutningen af ​​artiklen, vil jeg gå over nogle kodeoversætninger og værktøjer, der fokuserer på bestemte sprog, som jeg føler, at de fleste af os arbejder med. Resten vil dog være ganske bredt scoped.

Værktøj

Værktøjer er en fantastisk måde at øge den hastighed, som du skriver og implementerer kode på. Nogle gange kan de være en distraktion, men oftest kan de være meget hjælpsomme. Jeg vil tale om hovedsagelig om dem, jeg har vokset til at elske i årenes løb, men der er mange flere derude, som jeg ikke vil dække - så føl ikke, at dette er en udtømmende liste, men snarere en liste over mulige ideer. Tænk på dette, helst som et springpunkt

Tekstredaktører

Tekstredaktører er et emne af meget kontrovers. Jeg mener, lad os se det, vi bruger det meste af vores dag inde i dem, og derfor har vi ofte utroligt forspændte præferencer. Jeg er heller ikke uden for denne cirkel af bias, så forvent ikke en journalistisk forståelse af alle tekstredaktører i verden her. Men snarere et par af mine favoritter og hvorfor jeg kan lide dem.

Når du læser dette dog, skal du huske på, at jeg bruger mere end et tekstredaktør og til meget specifikke formål. Jeg vil ofte holde et par tekstredigerere lukket med en klients filer inde i dem. Hvad jeg mener med det er i Sublime Tekst 2 Jeg kan arbejde på et skinner projekt og har som 14 faner trukket op derinde, at når jeg starter Sublime, åbner den dem alle sammen. Og så for ikke at forstyrre det, holder jeg faktisk en klients hjemmeside. Jeg kan lave et HTML- eller CSS-design til i TextMate. Og ved skrivning holder jeg det normalt i enten en separat TextMate-mappe i Dropbox eller i Scrivener. Så jeg holder alt adskilt på den måde. Så jeg vil naturligvis tale om Sublime Text 2 (tilgængelig til Windows og Mac) og TextMate (kun tilgængelig til Mac).

TextMate

TextMate er en af ​​de bedste redaktører derude, til Mac. Det har et forenklet design, en smuk grænseflade og et kraftfuldt funktionssæt. Men en af ​​de sande identifikatorer for produktets kvalitet er fællesskabet bagved det. Det er voldsomt. De laver bundt, scripts og stort set alt hvad du kan forestille dig.

Husk dog, at MacroMates (skaberne) virkelig manglede i sin udvikling. Nu kan det være lidt overdrevet, men det var år efter år, før de skabte den anden version, der behandlede mange folks bekymringer og problemer. Med det siges dog, er det stadig en smuk redaktør og et sted, jeg elsker at gå for at skrive Markdown eller kode af næsten alle typer. Jeg bruger den til alt, hvad jeg kan, når jeg ikke bruger Sublime Text 2. Det har også en smuk skrifttype, og mange har skrevet bøger, artikler, hele webapps, som alle bruger denne smukke editor - og med god grund. Hvorfor går du ikke tjekke hvorfor, og se selv .

Sublim tekst 2

Sublime Tekst 2 er en god teksteditor, men jeg er ikke sikker på, hvilken slags stenografi der skal henvises til - så jeg vil bare sige Sublim. Sublim, som det var, er en god redaktør. Jeg har aldrig brugt det før version 2, men jeg vil sige, at det bare er dejligt. Jeg er ikke så sikker på forskellene - bortset fra skrifttypen og standard baggrundsfarve - mellem den og TextMate. Jeg vil dog sige, at jeg elsker den skrifttype, som den bruger ( jeg ved, tilsyneladende ubetydelig - men vigtig for mig ), og jeg elsker også den måde, den gør på fanebladet.

I stedet for at tale om funktioner, vil jeg i stedet tale om et par andre ting. En ting om det, der er lidt smerte, før du hopper ind i de andre ting , er, at du ikke kan kalde det fra kommandolinjen lige så nemt som TextMate. Med TextMate skriver du bare "mate." Og det åbner den pågældende mappe i sin lille projektlades, det virker bare perfekt. Selvom du stadig finder Sublime nyttige uden denne funktion. Jeg føler bare, at arbejde i Sublime er en glæde. Jeg er ikke sikker på hvorfor, måske, at det arbejder på en mørk baggrund, er rart, men jeg nyder virkelig bare at arbejde i Sublime. Jeg bruger det, når jeg har brug for at få en massiv mængde arbejde udført. Det er et massivt skinner projekt - eller lignende. Jeg tror, ​​du vil også finde det nyttigt, så tjek det ud .

Kode organisation og metoder

Organisationen er et emne, hvor der er meget debat. Mange mennesker foretrækker ikke komplicerede systemer for at hjælpe dem med at blive organiseret, men i virkeligheden kan en smule komplikationer på kort sigt hjælpe dig med at holde orden på lang sigt. Jeg ved, at det lyder ikke-intuitivt, men det er meget præcist. Især når det kommer til versionsstyringssystemer. Tag det fra mig, en person, der stolte på FTP, og jeg gør stadig nogle gange , og jeg har aldrig været lykkeligere ved hjælp af et versionsstyringssystem.

Brug af kildekontrol er en god måde at holde orden på. At sikre, at du holder sikkerhedskopier af din udviklingsproces, er virkelig vigtig, og det er ikke rigtig at skære det på lang sigt, hvis du overlader det til forskellige mappehierarkier. Jeg mener, det kan virke fint, når din computer kører, men hvis du har et krasch eller harddiskfejl, er du meget lidt færdiggjort tabt.

Hvad kan du dog gøre for at løse dette? Nå, du kunne bruge et versionsstyringssystem, der tager et øjebliksbillede af din udviklingskatalog i løbet af de gange, du arbejder. Brug dette er en rigtig god måde at have en konstant ny version på og en konstant adgang til backup, hvis der er fejl eller en form for tab. Det er også bare godt at have en periode. Jeg mener, tænk på hvor mange gange du var som "Jeg spekulerer på, hvordan jeg gjorde det eller implementerede den funktion." Nå, nu ved du bogstaveligt talt.

Og når man taler om versionsstyringssystemer, er git en god måde at gøre dette på. Du behøver ikke engang nogen viden om systemer som Mercurial eller Subversion for at komme i kontakt med VC-systemet, der er Git. Faktisk havde jeg ingen erfaring med disse systemer, og jeg kom faktisk i gang med Git ganske hurtigt faktisk.

Du kan følge kommandoer direkte fra GitHub når du åbner et repository, og så indtaster du bare dem i din terminal, og du kender så bogstaveligt talt næsten alt hvad du behøver. Derefter er alt, hvad du skal gøre, at gøre kommandoen kommandoen, når som helst du vil foretage en forandring. Husk dog, at hvis du allerede har dev-filer i mappen, kan du bruge "git add." I stedet for eksemplet "touch README" for at tilføje alle dine filer. Meget lignende koncept for at åbne et TextMate eller vindue i terminalen, hvor perioden angiver en sådan handling .

Nu, inden jeg er færdig med dette afsnit, vil jeg gerne sige, at jeg aldrig har brugt Mercurial eller Subversion, men faktisk er de mulige muligheder og er ganske populære blandt visse folkemængder. Der er endda websteder, der giver dig mulighed for at være vært for dine filer fra sådanne systemer som SourceForge, ligesom GitHub gør.

Før jeg er færdig, vil jeg også nævne en sidste ting. En Git GUI, der vil hjælpe din proces ganske lidt. Og det er, GitBox . Det er et rigtig godt program, og stort set alt hvad du behøver at gøre for at bruge det er oprettet et Repository på samme måde som du ville nogen anden gang (fra kommandolinjen). Så åbner du bare GitBox og tilføjer i den pågældende mappe fra din computer, og du er bogstaveligt talt alt indstillet.

Når som helst du foretager en ændring, vil det automatisk blive bemærket og vises i GitBox, og så kan du gå om at efterlade en kommentar til din begå og derefter trykke den. Husk dog, at metoden går: "skift -> kommentarer (hvis nødvendigt / nogen) -> commit -> push".

Sørg for at skubbe først efter at du har begået dig, ellers sker der ingenting. Og hvis du arbejder med et hold, skal du sørge for at trække dig før du laver kommentarer, begår eller noget, for at sikre dig, at du holder dig væk fra eventuelle fejl, du måtte have.

Supersets og kodeværktøjer

En superset defineres ofte af en kodesyntax eller ekstrapolering, der sidder oven på sproget under det. Eksempler på dette kunne være CoffeeScript siddende oven på JavaScript - eller Node.js sidder oven på Node (selvom det også kunne betragtes som et bibliotek). Det kan også beskrives som noget som SASS eller LESS sidder oven på CSS, der faktisk tilføjer funktionalitet og nye metoder til håndtering af ting.

SASS tilføjer også en ny tilgængelig syntaks, der kan bruges på samme måde som CoffeeScript tilbyder til JavaScript. Et godt eksempel på et bibliotek ville være jQuery på JavaScript, selvfølgelig. Det er noget, vi alle sikkert ved og elsker nu, men det er en god påmindelse om, at vi bruger et bibliotek og / eller superset.

Nu vil jeg ikke tale om hvert eneste bibliotek i verden - fordi jeg bare ikke har brugt dem alle. Jeg vil heller ikke have denne artikel at fokusere på specifikke biblioteker. Derfor har jeg valgt at tale om supersets i stedet og kodeværktøjer til bestemte sprog, som de fleste af os bruger. For eksempel HTML, CSS og Ruby on Rails specifikt.

I stedet for at hoppe lige ind, lad os tage et kig på nogle eksempler for at hjælpe med at forstå, hvorfor du ville bruge disse værktøjer og / eller supersets. Lad os f.eks. Sige at du arbejder i CSS og HTML i Rail (med din udvikler måske eller mens du er udvikler), og du har lyst til at spilde tid på at skrive så meget ERB (hvilket er den måde, du tilføjer Ruby-kode til skinner vil skrive i skinner - mere om det her ).

Nå, en god ting at gøre ville være at bruge HAML for hurtigere at skrive din HTML, og også for at fremskynde implementeringen af ​​din Ruby-kode i den. HAML er et superset af slags HTML, som giver dig mulighed for at skrive HTML-kode uden at skulle bekymre sig om at lukke dine tags, og det giver dig også mulighed for at bruge hvid plads til din fordel - ligesom Python. Lad os tage et kig på et eksempel.

#wrapper%ul%li This created an unordered list, that is properly semantic.

Og det skaber:

  • Test Li
  • Du kan sikkert se, hvordan det vil spare dig for meget tid. Det er også rigtig sjovt og rent at skrive. Det er en glæde, helt ærligt.

    Hvad med den CSS? Du kan spare meget tid på at skrive det også! SASS tilbyder en meget lignende funktionalitet, men uden at skulle lære en ny form for syntaks. Så med en delmængde af SASS (en delmængde af superset) kan du faktisk bruge hvidrum til din fordel. Så lad os tage et kig på, hvad det er.

    .wrapper {font-size: 12em;}

    Nå i SASS ville det se ud som:

    .wrapperfont-size: 12em

    Som du kan se, i SASS behøver vi ikke {} eller den afsluttende halvkolon. Vi bruger også det hvide rum til at angive, at skrifttypestørrelse er et barnelement i "wrapper" -klassen.

    med Lad os sige dig Du går også ud fra, at kun folk, der laver backend dev, bruger versioneringskontrolsystemer, men faktisk skal vi alle ved nu, det er ikke tilfældet. Du kan bruge git og Github til at holde styr på hver gang du laver en kodeforpligning, og med værktøjer som Gitbox har det aldrig været lettere.

    Nu skal du selvfølgelig ikke alle bruge Ruby on Rails, når du skriver kode - men jeg forestiller mig, at en god del af jer arbejder med folk, der bruger det. Anyway, uanset lad os dække nogle løsninger til en solo person, der ikke arbejder eller bruger Rails på nogen måde. For CSS LESS er det en god løsning på det. Zen Coding er også en løsning for alle, der ikke arbejder på Rails, men vil bare fremskynde den hastighed, hvorpå de skriver standard HTML-tags. Det er virkelig meget nyttigt for nogen. Zen kodning er virkelig nemt at begynde at arbejde med. o Brug ting som Zen Coding til at lette dine HTML tags. For eksempel at skrive:

    ul > li*6

    du får:

    Du kan også stadig bruge MINDRE for at få mixins og variabler og sådan. Det er ret nemt at arbejde med.

    Du vil også gerne have et godt værktøj til at arbejde i terminalen kaldet Go2Shell. Den er tilgængelig på mac app butik gratis. Du kan bare bruge det, når du skal åbne terminalen i en bestemt mappe, som er ret almindelig. Så for at bruge det, vil du bare navigere til den pågældende mappe i din finder og bare klikke på programmet go2shell og boom din terminal åbner for den pågældende fil. Det er fantastisk. Og det vil om at pakke det op for nu, holdes tunet til efter sommeren, men for en kort liste over steder at besøge fra artiklen.

    Det er nogle af de mest nyttige supersæt og værktøjer, jeg kender til at få nogle af de bedste resultater. Jeg vil også gerne nævne, at dette ikke var en udtømmende eller komplet liste på nogen måde, så vær så venlig at finde ud af mere om det. Og som lovet er her nogle af forbindelserne til det, vi har rørt om i artiklen. GitBox , GitHub , Kompas , Sass , HAML , MINDRE , Ruby on Rails . Glædelig jagt!