Bruke verktøy for kvalitets WordPress Development

Byggverktøy, temaer, plugins og applikasjoner i WordPress krever en rekke forskjellige ting hvis vi vil sørge for at vi er bevæpnet med de beste verktøyene som er nødvendige.

Hvis du skulle spørre, si 10 forskjellige personer hvilke verktøy de foretrekker, vil du ikke bare få et bredt utvalg av svar - ting fra IDEs til avhengighetsadministrasjonsprogrammer for å bygge verktøy - men du vil også gi en rekke forskjellige svar , som alle gir lignende funksjonalitet som det du trenger.

For eksempel kan noen av tingene du leser om inkludere:

  • Grynte
  • Bower
  • komponist 
  • CodeKit
  • JSLint
  • … og mer

Dette treffer ikke engang overflaten av emner som webservere, databasesystemer og versjoner av PHP. Alle disse er viktige emner som bør diskuteres, men i eget innlegg.

Når du arbeider med WordPress, inkluderer noen av de ikke-forhandlingsbarene som det gjelder å få arbeid gjort effektivt, følgende:

  1. En IDE
  2. En Debugger
  3. Kode Linting og Minification
  4. Versjonskontroll
  5. Distribusjonsverktøy

Som med de fleste ting, har utviklere sine spesielle valg om verktøyene de liker å bruke og hvorfor de liker å bruke dem.

I denne artikkelen skal jeg dele noen av verktøyene jeg foretrekker å bruke, og som jeg har funnet nyttig i min profesjonelle WordPress-utviklingsinnsats; Men jeg vil gjerne avklare at dette ikke er en endelig liste over hvilke verktøy du har bør bruker.

I stedet tenk på dette som en veiledning for eksempler på hva som utgjør kvalitetsverktøy for kvalitetsutvikling. Hvis du er fornøyd med verktøysettet du bruker, så flott! Men hvis du er på utkikk etter noe som kan hjelpe deg med å få jobbet gjort på en mer effektiv måte, så kan disse kanskje hjelpe deg med å sette på riktig vei.

Før vi begynner, vil jeg dele at jeg bruker OS X, så mange av mine anbefalinger vil være basert på den plattformen. Imidlertid har mange av programmene jeg bruker har både Windows og Linux kolleger, samt verktøy som er åpen kildekode og er tilgjengelig på tvers av plattformen.

1. IDEer

Å ha en IDE for å skrive kode er viktig. Sikker, noen utviklere foretrekker noe så enkelt som TextEdit eller Notepad ++. Mer kraft til dem! Men hvis du er på utkikk etter noe med syntaksutheving, kodeavslutning, støtte for plugins, S / FTP-integrasjon, og til og med versjonskontrollintegrasjon, så finnes det en rekke verktøy som er tilgjengelige..

Personlig er min IDE valg Coda 2.

Denne spesielle IDE resulterer i blandede meninger over hele linja i WordPress utvikling. Noen foretrekker Atom, noen foretrekker Sublime Text, noen foretrekker Vim, noen foretrekker PHPStorm, og alle har sine styrker.

Personlig liker jeg Coda 2 for fortsatt støtte, oppdateringer, mobile variasjoner av applikasjonen, og det generelle utseendet. Jeg liker fremgangene de har gjort med hensyn til støtteplattformer som WordPress, og muligheten til å ha innebygd kodeutfylling er fin.

Gitt, andre IDE tilbyr nøyaktig samme funksjonalitet; Men hvis du velger å gå med Coda, her er noen plugins som jeg foretrekker for WordPress-utvikling. I ingen bestemt rekkefølge:

  • WordPress Mode for Coda 2
  • PHP Docblock Generator
  • Hvit ut

Selvfølgelig er det mange andre som du kan installere, også.

Når det gjelder andre IDE-er som du anbefaler, vennligst sørg for å sjekke ut konklusjonen for å se hvordan vi ønsker å inkorporere dem i kommentarfeltet av dette innlegget.

2. Debuggere

En av de kraftigste verktøyene i en utviklerens verktøykasse er debuggeren. For de som ikke er kjent, lar dette programvaren overvåke hva nøyaktig kildekoden din gjør når den løper gjennom hva programmet gjør i løpet av kjøretiden.

Dette gir deg muligheten til å:

  • se hvilken funksjon som avfyres
  • se verdiene til de ulike variablene
  • gå over bestemte funksjoner som du vil unngå
  • gå inn i funksjoner som du vil se (for eksempel WordPress-kjernefunksjoner)
  • ... og så mye mer

Mange IDEer, for eksempel PHPStorm, kommer med en debugger innebygd. Men hvis du velger å bruke en annen IDE som ikke inneholder en debugger, så anbefaler jeg Codebug.

Det er en elegant, brukervennlig debugger som gir deg all kraften til en innfødt debugger, men i en frittstående applikasjon. Det er vel verdt prislappen å legge til i arsenalet.

Et ord med forsiktighet: Hvis du er ny for å feilsøke og / eller ikke er sikker på hvordan systemet fungerer, vennligst vær sikker på å lese dokumentasjonen. Det er faktisk relativt lett å lære, men det har sin læringskurve. 

Når du har blitt vant til å bruke en debugger, skjønner du hvordan du noen gang levde uten en.

3. Kode Linting og Minifiseringsverktøy

Kode Linting og Minifiseringsverktøy kan være to separate emner, men i disse dager går de så hånd i hånd som jeg trodde de var verdt å inkludere sammen.

linting

Først, for de som ikke er kjent, er linting i utgangspunktet prosessen med å sørge for at koden, i dette tilfellet, JavaScript-koden din, er opp til en bestemt standard. Det er at det ikke bruker noen dårlige praksis.

Ifølge Wikipedia:

lint var navnet opprinnelig gitt til et bestemt program som flaggret noen mistenkelige og ikke-bærbare konstruksjoner (sannsynligvis bugs) i C-språkkilden. Begrepet brukes nå generisk til verktøy som flagger mistenkelig bruk i programvare skrevet på hvilket som helst dataspråk.

I vårt tilfelle har vi verktøy som JSLint og JSHint som tillater oss å gjøre akkurat det med vår JavaScript-kode.

Du kan definitivt finne lindere for andre språk også, men uten tvil er det vanligste tilfellet der du finner linting i WordPress, med hensyn til JavaScript. Du kan også finne dette innebygd i noen av de byggverktøyene som er nevnt i begynnelsen av denne artikkelen.

forminskning

Minifisering refererer til prosessen med å ta et språk - det være seg CSS, Sass, MINDRE, JavaScript, og så videre - og fjerner deretter alle hvite plasser, lange variabelnavn og så videre i en mer kompakt fil.

Tanken er ikke å lage forvirret kode, men det er å lage lette filer som du kan betjene nettleseren i et produksjonsmiljø, slik at nettstedet ditt lastes raskere fordi det har mindre å laste ned.

Det er også begrepet sammenkobling som overskrider omfanget av denne artikkelen, men ideen bak sammenhengen er at alle de minifiserte skript og stilark vil bli kombinert i en enkelt fil slik at nettleseren bare trenger å lage to forespørsler, en for hver fil.

I alle fall vil alle de ovennevnte verktøyene også ta vare på minifisering (og sammenkobling) av skript og stiler og vil sende dem ut i katalogen du velger.

4. Versjonskontroll

Når du jobber med en kodebase, uansett om det er med deg selv eller med et lag, er det alltid nyttig å sørge for at du opprettholder konsekvente versjoner av programvaren din.

Kort sagt, versjonskontroll er en måte at du kan forplikte koden til et lager slik at, som du eller dine lagkammerater gjør endringer, blir de nyeste versjonene av koden opprettholdt på en slik måte at du kan se en historie om hva som har vært gjort, og at du kan vende tilbake til et tidspunkt i tidslinjen, bør noe gå galt.

I form av hva programvare er best for versjonskontroll, det finnes verktøy som Subversion, Git og Mercurial.

Hvis du er vant til å jobbe i WordPress-økonomien, er du mer enn sannsynlig kjent med Subversion som det er det kjernen bruker for å opprettholde endringene som går inn i systemet.

På samme måte, hvis du noensinne har bygget og slettet et plugin, så har du hatt å jobbe med Subversion for å forplikte koden din, merke utgivelsen din og så videre.

Men Git blir mer og mer populært. Uansett er de to mest populære nettstedene for Git hosting GitHub og Bitbucket. Uansett, hvis du leter etter en solid Git klient, så anbefaler jeg Tower 2.

Selv om det er min klient av valg, er det rikelig av andre alternativer. I siste omgang er poenget å sørge for at du legger til koden i kildekontroll, du jobber med en klient som du elsker, og om mulig har du koblet deg til et distribusjonssystem slik at hver gang du skyve en bestemt egenskap eller krav, miljøet som klienten bruker til å se gjennom produktet oppdateres med den nye koden.

5. Distribusjonsverktøy

Når du jobber med å bygge et WordPress-prosjekt eller et hvilket som helst programvareprosjekt, er det standard arbeidsflow på høyt nivå som vi alle følger:

  • Et utviklingsmiljø der vi har en lokal maskin der vi utvikler oss.
  • Et scenemiljø som vi distribuerer koden vår slik at klientene kan hamre på prosjektet mens vi jobber oss gjennom kravene.
  • Og så produksjonsmiljøet, som er der sluttprosjektet distribueres.

På dette tidspunkt er det ikke uvanlig å ha et distribusjonssystem koblet til kildekoden management software slik at hver gang en ny oppdatering er forpliktet til kildekoden depot, vil den nyeste versjonen av prosjektet bli utgitt.

Heldigvis finnes det en rekke flotte verktøy som er tilgjengelige for å sette opp automatiserte distribusjoner.

Codeship

Kodeship stiller seg selv som en tjeneste for kontinuerlig integrasjon som kan utføre de nødvendige skriptene for å bygge, teste og distribuere prosjektet alt fra en Git-forpliktelse.

Dette betyr at du kan utføre et antall skript som skal brennes under distribusjon og motta varsler før du ruller noe ut til produksjonen.

Kodeship er en god løsning, avhengig av størrelsen på teamet ditt og / eller prosjektet ditt, spesielt for større organisasjoner som består av eiere, ledere, prosjektledere og så videre.

Når det er sagt, har jeg personlig brukt dette verktøyet på et to-personers lag og har vært fornøyd med resultatene.

DeployBot

DeployBot ble tidligere kalt Dploy.io. I likhet med Codeship, har DeployBot som mål å ta kildekoden forpliktet til et Git-depot og distribuere det til et miljø du velger.

Den har også muligheten til å kjøre skript, bygge og kompilere kode, og distribuere den til forskjellige miljøer basert på konfigurasjonen du har oppgitt.

Naturligvis er disse ikke alle distribusjonsverktøyene som er tilgjengelige, men disse er to som du sannsynligvis vil finne når du arbeider i en profesjonell programvarekapasitet. Hver av dem tilbyr sine egne sett med fordeler og ulemper for det du kanskje prøver å gjøre; Men siden dette ikke er en gjennomgang eller sammenligningsartikkel, la jeg den øvelsen opp til deg for å finne ut hva som passer best for arbeidsflyten din.

Konklusjon

Som nevnt i innledningen, er disse verktøyene ikke noe mer enn anbefalinger for hvor du skal komme i gang med noen verktøy for WordPress-utvikling. Jeg vet at mange av dere har dine egne preferanser til hva du liker å bruke for hvert av de ovennevnte kriteriene.

Med det sagt vil jeg gjerne for alle dere dele hva dine foretrukne verktøy er, og hvorfor du liker å bruke dem i kommentarene. På den måten vil nåværende og fremtidige lesere ikke bare ha et innlegg med anbefalinger, men også kommentarer som gir alternativer.

Tross alt handler utviklingen ikke bare om problemløsing. Det handler om å finne verktøy som også er en glede å jobbe med i åtte og så mange timer om dagen vi bruker på en datamaskin.