Share
En av de beste tingene med å lære en ny ferdighet i programvare er at du ofte gjennomgår denne prosessen for å få noe i gang, lære om noen av de feilene du har gjort, raffinere koden og deretter gjenta prosessen.
Til slutt handler det om å forbedre kvaliteten på det du gjør slik at sluttresultatet er bedre enn det ville ha vært hvis du bare hadde forlatt det som det var i sin første iterasjon.
Og egentlig, når det gjelder å skrive programvare, er en av tingene vi ofte hører og ofte snakk om kvalitet. Nærmere bestemt snakker vi om byggekvalitet inn i vår programvare.
Men jeg antar at hvis du spør ti utviklere hva kvalitet betyr for dem, vil du få ti forskjellige svar.
Ordet "kvalitet" tilbyr tre definisjoner:
Hvis du tenker et øyeblikk hvordan dette relaterer seg til produktene du bygger ved hjelp av WordPress, kommer det til rette?
Uansett kan "kvalitet" bety forskjellige ting for forskjellige mennesker. Men jeg tror det er visse ting som ikke er subjektive med hensyn til WordPress-utvikling.
Før jeg går videre, vil jeg være oppmerksom på at når du citerer noen andre, med mindre det er en kjent kilde, liker jeg å holde kilden anonym.
Årsaken er at jeg ikke vil ha folk som leser opplæringsprogrammer som dette for å bli sidesporet og forsøke å ta problem med hva personen har sagt. Det er ved siden av punktet, vet du?
Og det skjer. Jeg snakker av erfaring.
Med det sagt, nylig noen nærmet meg litt kode som jeg hadde gitt om å jobbe med WordPress kroker når du bygger temaer. Kort sagt sa de:
Å si flere linjer med kode er bedre enn mindre, er noe bare en hardkjerne, vil en erfaren WordPress-utvikler si. Jo mindre kode, jo bedre.
For hobbyister og de som bare lærer tauene i utviklingen, kan jeg se hvordan dette virker sant. For de som har jobbet i feltet for en stund, innser du sannsynligvis problemet med dette.
Jeg hevder ikke at mer kode alltid er bedre kode. Det er ikke. I stedet foreslår jeg at det er tider hvor en hel funksjon er bedre enn en enkelt linje med kode.
Hvordan bygger vi dette inn i vårt eget arbeid? Hvordan formidler vi dette til de som er mindre erfarne programmører? La oss ta en titt på et konkret eksempel og se om det er noe å skille fra det.
I WordPress 4.4 ble støtte for tittelkoder endret slik at du legger til støtte for det ved bare å inkludere følgende linje i din functions.php fil:
Hvis du ikke vil bruke den funksjonen, vil du bli krevd for å kode inn tittel element i headermalen på temaet ditt.
Selvfølgelig er det plugins og temaer som ennå ikke er oppdatert (på tidspunktet for denne opplæringen). For det formål er det fortsatt relativt vanlig å se noe som følgende linje av kode i malfiler:
<?php wp_title("); ?>
Men hvorfor ville noen rote med tittelen? Tenk på SEO plugins. De vil ofte forandre seg tittel elementer for å være mer søkemotor-vennlig.
La oss ta en titt på et ekte eksempel: Si at du jobber med et tema og dets tittel elementet omfatter et anrop til wp_title. Videre vil du sørge for at wp_title er filtrerbar slik at annen kode som de nevnte pluginene kan oppdatere den.
Det virker rettferdig nok, ikke sant? Men la oss si at du vil klare det litt ved å inkludere en separator og oppdatere sin posisjon. I dette tilfellet kan du gjøre noe slikt:
<?php wp_title( '|', true, 'right' ); ?>
Eller kanskje du vil ta det et skritt videre og introdusere navnet på bloggen og beskrivelsen. Eller kanskje du vil sette opp tittelen slik at den er annerledes på hjemmesiden.
Da kan du gjøre noe slikt:
<?php bloginfo('name'); ?> | <?php is_home() ? bloginfo('description') : wp_title("); ?>
Isolert, utenom noen plugins eller annet arbeid, ser det bra ut. Det er en enkelt kode som hobbyister kan bruke for å oppnå sitt endelige mål.
Men hva skjer når noen distribuerer temaet? Videre, hva skjer når noen vil bruke et plugin for å endre tittel element?
Det vil ikke fungere.
Dette er bare en grunn til at mindre kode ikke alltid er bedre kode, og hvorfor mindre kode kan være av mindre kvalitet.
For å sikre at bruken av wp_title () er så fleksibel som mulig, må vi definere en egendefinert funksjon og filtrere den ved hjelp av wp_title filter levert av WordPress:
Accentsconagua
= 2 || $ side> = 2) $ title = sprintf (__ ('Side% s', 'acme'), maks ($ paged, $ side)). "$ sep $ title"; returner $ title; Koden ovenfor er åpenbart mer kode enn enkeltlinjen i forrige eksempel, men det er også mer fleksibelt.
Først sjekker koden for å se om siden gjengis i et RSS-feed. I så fall returnerer den bare den angitte tittelen. Ellers legger det navnet på tittelen til det angitte $ title streng. Når du ser på hjemmesiden eller forsiden, plasserer koden beskrivelsen etter separatoren.
Til slutt, hvis brukeren søker gjennom nettstedet, preger koden sidetallet til separatoren og tittelen.
Dette gir grunnleggende funksjonalitet for å gjengi tittelelementet i temaet. Dette er ikke standard måten å gjøre det for alle temaer, men det er uten tvil en bedre måte å gjøre det på.
Som sådan kan du også tilpasse denne funksjonen for å passe det du tror er best for ditt eget arbeid.
Nøkkelopptaket for denne opplæringen er ikke hvordan du setter opp et filter for titler, eller hvordan du konfigurerer filtre, og det er heller ikke hvordan man skal håndtere titler. I tillegg, wp_title blir avskrevet, som nevnt tidligere i artikkelen.
Vi ender opp med en tilpasset versjon av tittelen. Vi gir også tredjepartsutviklere muligheten til å overstyre vår egen kode.
Selv om dette er mer kode, er det en høyere kvalitetsløsning.
Husk, skjønt: Det er ikke alltid tilfelle. Noen ganger mer kode kan redusere kvalitet og det kan øke kompleksiteten. Men det er ikke meningen med denne artikkelen. Kanskje det er best omtalt i en annen opplæring.
I stedet er formålet med denne opplæringen å vise hvor mindre kode kan resultere i lavere kvalitet og hvor mer kode kan forbedre kvaliteten. Men dette er ikke en hard og rask regel. Det skal heller ikke være.
I stedet er hensikten å introdusere tankegang til å tenke gjennom hva som definerer kvalitet. Noen ganger er mindre kode kvalitetskode; Noen ganger er mer kode kvalitetskode.
Når du jobber med prosjektet, ikke se etter måter å konsolidere kode bare på grunn av mindre kode. Se etter måter å skrive kode på slik at den er elegant, utvidbar, lesbar og vedlikeholdbar, og fremfor alt egnet til formål.
Alt sammen bidrar til å bidra til kvalitet.
Hvis du leter etter eksempler på andre WordPress-prosjekter som kan brukes til å undersøke kodekvalitet, bruke i arbeidet ditt eller i klientprosjekter, kan du også finne noe interessant på markedet.
Hvis du er interessert i andre ting jeg har skrevet eller produsert for Envato, kan du sjekke ut arbeidet mitt på min profilside, og du kan følge meg på bloggen min og / eller Twitter på @tommcfarlin hvor jeg snakker om programvareutvikling i sammenheng med WordPress.
Ikke nøl med å legge igjen noen spørsmål eller kommentarer i feedet under, og jeg vil sikte på å svare på hver av dem.
