Share
Åh, jeg elsker raske og enkle tekstredaktører. Å være en Linux-bruker bodde jeg i mange år med Kate og KWrite. Med noen tweaks og plugins kunne jeg gjøre dem veldig klare. Jeg skrev hele prosjekter i Perl, Bash, og til og med noen PHP og Java i disse redaktørene. Jeg kan sette pris på all entusiasmen som går rundt Sublime Text eller TextMate, men jeg kunne ikke leve uten en fullblåst IDE i dag.
Jeg observerte at det er to slags programmerere. Den første typen har en tendens til å bruke applikasjoner som kan tilby større og større kodehåndteringsproduktivitet, men på bekostning av den plutselige læringskurven og vanskeligheter med bruk. Disse programmererne er de som foretrekker Vi (m) eller Emacs.
Den andre kategorien programmerere har en tendens til å migrere fra enkle redaktører til IDEer. Dette er like naturlig for en evolusjon som den første kategorien. Det fører imidlertid til en annen tankegang og en annen oppfatning av prosjektet og koden. Jeg er programmerer fra denne kategorien, så i denne artikkelen vil vi snakke om IDE jeg bruker for øyeblikket: PhpStorm.
Verktøy og brukerpreferanser for applikasjoner er så volatile at jeg sjelden skriver om et bestemt rammeverk eller program. Men hvis du bruker et program 10-14 timer hver dag, blir det en del av deg, en del av hvordan du ser koden din, dine prosjekter. Det blir motorveien for din daglige arbeidsflyt. Så det fortjener å bli nevnt og presentert.
Jeg pleide å hente en rask tekstredigerer når jeg trengte å kode bare et kort skript eller program. Men jeg gjør ikke lenger. Dagens datamaskiner og IDE er så raske at det er liten forskjell mellom å starte PhpStorm og skrive koden eller starte KWrite og skrive koden. Programmet selv er nesten like fort som en redaktør, og skaper et prosjekt, selv om en eller to faktiske filer ikke er noe langsommere som gjør de samme filskapene i redaktøren din.
OK, OK ... Dette er alle likheter. Men hva handler dette IDE om? IDE kommer fra integrert utviklingsmiljø. Dette uttrykket har to viktige deler: integrert og utviklingsmiljø. Utviklingsmiljødelen kan ses som redaktør og de spesifikke funksjonene for kildekoden manipulering: kode skriving funksjoner, utheving, auto-komplett, komplekse redigering funksjoner som multi-seleksjon og multi-edit, refactoring verktøy, og så videre. Integrasjonsdelen kan ses som integrasjon mellom utviklingsmiljøet beskrevet ovenfor og ulike eksterne verktøy, testrammer, dokumentversjoneringssystem, debuggere og brukergrensesnittbyggerverktøy.
Nøkkelegenskapen til en IDE er forståelsen av koden du skriver. En IDE har ikke bare en liste over kommandoer du kan bruke på ditt favoritt språk, som PHP. Den har komplekse algoritmer for å forstå koden din. PhpStorm vil ikke foreslå deg en kommando eller et uttrykk som ville være syntactically feil. Det vet for eksempel at du ikke kan skrive "skriv ut ('Hello World');"direkte i en klasse, uten å sette den inn i en funksjon. Så det vil ikke foreslå"skrive ut()"kommandoen når den ikke kan brukes. Men dette er bare toppen av isfjellet. La oss se noen mer konkrete eksempler.
Ja. Hvis du har lest de to første delene av Refactoring Legacy Code-serien, The Golden Master og Magic Strings & Constants, har du kanskje observert at det er skjermbilder vist i opplæringen med en IDE. Slik ser PhpStorm ut. Og følgende er hvordan PhpStorm hjelper meg når du lærer deg å programmere.
Dette er viktig. De fleste enkle redaktører kan også gjøre grunnleggende kodeutheving, men en IDE er en annen historie. Her kan du ha forskjellige fremhevingsoppsett for forskjellige språk som PHP, HTML, CSS og så videre. Hver med sine egne regler. For eksempel liker jeg å ha strenger grønne i CSS og oransje i PHP og HTML.
Til venstre kan du se alle de støttede filtyper og språk (noen kan legges til av plugins), i midten kan du se de forskjellige PHP-språkelementene som kan konfigureres separat, i øverste høyre hjørne er alternativene hvert element kan ha, og i bunnen er det en forhåndsvisning.
Da vi jaktet på magiske strenger i vår refactoring økt, kunne vi enkelt få øye på disse strengene ved bare å finne oransje ting på skjermen. Det samme gjelder for magiske konstanter og tall. Når de søkte etter, var den blå fargen vår venn.
Struktur og layout er viktig når vi trenger å forstå kildekoden, og riktig farging og utheving er viktig i denne saken.
Jeg har brukt mange IDEer og redaktører gjennom hele karrieren min. Den som jeg virkelig likte og verdsatt var NetBeans. Men etter omtrent fem års eksklusiv NetBeans bruk måtte jeg gi opp. Det er noe PhpStorm kan tilby, som ingen annen editor eller IDE for PHP kan gjøre. Dette er et sett med refactoring verktøy som er nødvendig i vårt daglige arbeid.
Utheving, innrykk, prosjektledelse, maler, makroer er alle funksjoner som finnes i de fleste redaktører. Integrasjoner med testmiljøer og debuggere er per definisjon en del av en IDE. Smarte og komplekse refactoringverktøy er imidlertid en helt annen historie.
Som programmerere bruker vi halvparten av vår tidskode, ca. 40% modifiserer og refactoring eksisterende kode, og hvis vi er heldige, veldig heldige, 10% skriver helt ny kode. Så å ha gode, raske og pålitelige refactoring-funksjoner vil hjelpe oss med å konsentrere vår innsats mer om hva du skal refactor og mindre om hvordan du gjør det. Vi vil spare tid også, men jeg vurderer gevinsten i mindre innsats for å være mye viktigere. Når du kan kaste tanken om prosessen inn i IDE, og bare tenke på logikken, algoritmen, avhengighetene, SOLID-prinsippene, er det en gevinst i produktivitet som må vurderes.
Derfor forlot jeg gratis og åpen kildekode NetBeans for den betalte PhpStorm. Det finnes i PhpStorm et sett med refactoringverktøy som gjør det spesielt, gjør det verdt å betale for.
En av de enkleste refactorings vi allerede har jobbet med i Magic Strings & Constants var Introduce Local Variable, også kjent som "Extract Variable". Her er en påminnelse om trinnene vi må ta for å bruke denne refactoring:
Disse trinnene er enkle å følge hvis vi har en enkelt verdi som skal omdannes til en variabel, men hva med trinn to? Hvordan finner du pålitelig alle forekomster av den verdien? Du må analysere koden din og ta bevisste beslutninger om hva du skal erstatte og hva, ikke. Her er et eksempel.
klasse SomeClass funksjon printAPairOfPlayers () echo "Spillerne er:"; ekko "Spillernavn:". $ Dette-> getRandomPlayerName (); ekko "Spillernavn:". $ Dette-> getRandomPlayerName (); funksjon printOnePlayer () echo "Spillernavn:". $ Dette-> getRandomPlayerName (); funksjon getRandomPlayerName () // Noen logikk for å finne spillernes navn // returner $ playerName;
I printAPairOfPlayers () vi kan observere at strengen "Spillernavn: "gjentas to ganger. Hvis vi ønsker å trekke ut denne strengen i en lokal variabel, en variabel inne i funksjonen, må vi erstatte begge hendelsene i printAPairOfPlayers () men ikke den i printOnePlayer (). Hvis printOnePlayer () ville være 100 linjer under, kan vi ikke engang innse at det er en annen duplisering av strengen i en annen metode.
Så vi vil ha en lokal variabel. Vi lager først variabelen, kjører testene, så ser etter strengen og finner den i den andre ekko uttalelser. Vi erstatter det, kjøre testene, vi ser igjen, vi finner det i det siste ekko uttalelse, erstatter vi det, vi driver testene. Vi ser igjen, vi når slutten av metoden. Vi bestemmer oss for at vi er ferdige med vår ekstrakt lokal variabel refactoring. Dette er ganske krevende kognitiv prosess, spesielt med stygg og ikke godt forstått kode.
Ville det ikke være nyttig å trykke på en enkelt snarvei, eller velg et alternativ i en kontekstmeny og har alt dette gjort av IDE? Det ville være kjempebra, og PhpStorm er ganske i stand til å gjøre det for deg.
I koden ovenfor plasserer du bare markøren inne i "Spillernavn: "streng hvor som helst og Høyreklikk.
Etter å ha valgt "Ekstra variabel ... ", Vil PhpStorm analysere koden din og søke etter ulike koden du kanskje vil trekke ut. Det vil foreslå to muligheter for vår sak.
Dette er ikke bare en kul funksjon, men en veldig nyttig. Det er så mange tilfeller når duplisering kan oppstå utenfor synsfeltet ditt. Når en utvinning er foreslått, blir analysen laget av PhpStorm gjennom hele koden, ikke bare de få linjene du kan se på skjermen. I dette tilfellet er alternativene åpenbare. For øvelsen, la oss velge bare strengdelen, uten sammenkobling.
Nå som koden du ønsker å trekke ut ble identifisert, er det neste trinnet å nevne det. "playerHeadersString"virker et fornuftig variabelt navn. Du trenger ikke å sette"$"Foran navnet i inntastingsfeltet. PhpStorm vil sette det i koden for deg automatisk. Et annet viktig aspekt er at det er en avkrysningsboks. PhpStorm fant alle forekomster for vår variabel. Vi valgte å trekke ut en lokal variabel, så PhpStorm visste bare å søke i den nåværende metoden, og det fant bare to hendelser. Samme streng i metoden printOnePlayer (), ble ikke talt eller foreslått, og det vil ikke bli erstattet. Det ville føre til feil kode, og PhpStorm er smart nok til ikke å skrive ugyldig kode for deg.
En annen fordel med PhpStorm er at du ikke trenger å kjøre testene dine ofte. Når vi gjorde en manuell refactoring, kjører vi tester etter hvert trinn. Hvis vi gjorde en skrivefeil eller erstattet noe som vi trodde var det samme, men i virkeligheten ikke var det, trengte vi et sikkerhetsnett for fort å fortelle oss det. PhpStorm erstatter imidlertid ikke noe som ikke er logisk korrekt i sammenheng. Du kan bli overrasket over at et stykke kode du også forventet å bli hentet ut, vil ikke være, men i det minste kan du være sikker på at den resulterende koden vil være riktig. I tillegg har vi mindre skritt. Manuelt gjør vi bare ett trinn. Etter det eneste trinnet må vi kjøre testene en gang.
Det spiller ingen rolle hvordan du ser på det, det er lettere, raskere og mye mindre feilaktig enn noe annet å gjøre refactoring.
Å trekke ut vår streng i en klassevariabel - også kjent som klassefelt - vi kan bruke "Ekstraheringsfelt"refactoring alternativ fra samme meny som ovenfor. Vi vil bli bedt om å identifisere koden vi trenger å trekke ut, og vi vil bli presentert med en litt annen form.
Foruten navnet hans har vi nå tre funnet hendelser. PhpStorm visste at vi ønsket en klassevariabel og det var i stand til å identifisere samme streng der det var nødvendig. Vi har også muligheter til å initialisere variabelen på forskjellige steder og angi synligheten. Ved å velge alternativene som i bildet, vil den resulterende koden være som nedenfor.
Selvfølgelig, hvis du vil at den skal være offentlig eller initiert i konstruktøren, er alt du trenger å gjøre bare å velge de riktige alternativene og la PhpStorm gjøre jobben for deg..
Når du trekker ut en variabel, vil du initialisere den så nær den første bruken som mulig. I de fleste tilfeller er dette enkelt, spesielt hvis det er en enkelt bruk av variabelen. Men hva med mer komplekse saker? La oss se på en av våre variable ekstraksjoner fra Magic Strings & Constants.
I rull() metode, på linje 73 - den valgte - det er et nummer "11". Det er et magisk nummer vi nettopp har identifisert, og vi ønsker å trekke ut det.
Hvis vi gjør vår ekstraktmetode for hånd, må vi følge disse trinnene:
Nå er det komplisert for et menneske å gjøre. Og det er feilaktig. Vi antar at du har tester som kan hjelpe deg, men hva om du jobber med noe uklar, untestable kode? PhpStorm vil forstå konteksten til koden din. Det vil riktig trekke ut variabelen for alle hendelser og sette den nøyaktig hvor den skal være.
Det vi presenterte ovenfor om refactoring-verktøy, er bare toppen av isfjellet. Extracting variabler er trolig den enkleste og enkleste refactoring du kan gjøre. Vi brukte ikke ekstraktmetode eller ekstrakter underklasse eller enda mer komplekse omdreininger i våre refactoring leksjoner, men vi vil. Vi lærer å gjøre dem for hånd, men jeg vil oppfordre deg til å bruke en smart IDE til å gjøre jobben for deg.
PhpStorm er veldig bra til å omdøpe variabler eller metoder selv over hundrevis av klasser. Tenk deg hvor vanskelig det ville være å endre navnet på en offentlig metode som brukes i 100 forskjellige klasser i prosjektet ditt. PhpStorm kan gjøre det til en fem minutters jobb i stedet for en to timers jobb. Det kan finne og endre navn på alle metodene, og du trenger bare å sjekke om gisp-kamper før du forteller det å handle.
Ja, ja ... Du må verifisere noen funnet forekomster fordi PHP er et dynamisk skrevet språk, og i noen tilfeller er det bare ingen måte PhpStorm, eller noen annen IDEs algoritme, eller program for den saks skyld kan vite hvilken type objekt er brukes til den spesifikke metoden samtale. Tenk deg, du har to helt forskjellige klasser. På hver av dem har du en offentlig metode kalt "findAll ()". Dette er veldig vanlig og riktig.
Nå er det 50 klasser som bruker din første klasse og en annen 50 med den andre. Hvis du brukte riktige grensesnitt og skriver hinting der det er mulig, vil PhpStorm foreslå de riktige klassene å endres. Men hvis du ikke angav hvilken type du bruker, eller du brukte ikke noe grensesnitt implementert av klassen din med findAll () metode, det er ingen måte å fortelle automatisk, hvilken av dine to klasser, begge har en findAll () metode, vil bli brukt. Det er essensen av PHPs dynamiske skriving. Men mens dette er en fordel i noen tilfeller er det en ulempe når vi må gjøre refactoring som dette. Når dette skjer, er det eneste som kan gjøres for et menneske å vurdere behovet for endringen.
Med alle disse, selv om det finnes andre refactorings tilstede i PhpStorm, er det allerede den beste IDE bare med refactorings. Omdøping, utvinning og innlining av variabler, utvinning og innlining er de mest brukte refactorings vi gjør hver dag. Hvis disse fungerer bra, har vi en vinnende IDE.
Men PhpStorm stopper ikke her. Den har mange andre refactoring verktøy som gjør at du føler deg bra i vanskelige situasjoner. Det har virkelig det "kirsebær på toppen" følelse.
Du gjør TDD, ikke sant? Hvis du ikke gjør det, bør du. Testing er like viktig for programmering som å skrive selve produksjonskoden. Jeg kunne ikke forestille meg livet uten TDD. Jeg har vært så vant til det de siste årene, at selv å tenke på kode uten å tenke på testene, føles det unaturlig og vanskelig.
Ved testing må prosessen og verktøyene være like gode som selve produksjonskoden. PhpStorm har god integrasjon med PHPUnit. Det er den eneste PHP IDE jeg kjenner til som faktisk kobler direkte til PHPUnit-rammen, strekker den ut og bruker den til å samle all informasjonen som må presenteres. Dette gir en mye mer intim forbindelse med PHPUnit, en bedre utgang for brukeren og mye høyere testhastigheter.
Andre IDEer pleier å bare bruke PHPUnit-kjørbare, skrive utdataene i en XML-fil og tolke resultatene for å vise den til deg. Slik fungerer NetBeans. Denne tilnærmingen gir større fleksibilitet for deg, brukeren, hvis du vil hacke systemet og overbevise det om å kjøre testene dine på uvanlige måter (for eksempel over telnet eller SSH). Men dette har også en stor ulempe. Ting blir sakte. Først og fremst må en skallprosess være forked. "exec ()"er alltid en viktig tidskonsument. Da må resultatet skrives til en fil, muligens på en ekstern maskin.
Vi vet alle at filsystemet er sakte, veldig sakte. SSD-er gjør det litt bedre, men de er fortsatt lysår unna RAM-hastigheten. Så, hvis vi driver fjerntestene våre, må vi kopiere den filen til vår maskin. Så ikke bare trenger vi å slå filsystemet en gang, vi må også legge til den tiden, kostnaden for nettverkskommunikasjon pluss å skrive den til en lokal fil. Da må filen leses tilbake, slik at den endelig kan vises til brukeren.
Selv om det er en super tilpassbar og fleksibel løsning, tar det bare tid. For mye tid når vi tenker på enhetstester og millisekundtester. Og enhetstester som tar lengre tid enn fem millisekunder å kjøre, er ikke enhetstester lenger.
PhpStorm løser, eller i det minste reduserer, overhead ved å bruke PHPUnit internt og forteller det å sende resultatet i den måten PhpStorm foretrekker. Dette reduserer fleksibiliteten. Du kan ikke hacke den til å teste utenfor sine grenser. Men det øker hastigheten mye. Ikke mer exec, ingen flere filer skrevet til sakte filsystemer. Ekstern kjøring kan legge til prisen på nettverkskommunikasjon, men vi kan ikke eliminere det uansett. En annen god fordel er at direkte bruk av PHPUnit tillater mer detaljert informasjon om mislykkede tester som skal presenteres på en mer organisert måte. Så vi får fart, detaljer og klarhet på bekostning av fleksibilitet.
Å være vant til NetBeans, jeg fant det vanskelig først, å akseptere denne ufleksibiliteten, men på slutten av dagen, selv om jeg noen ganger må kjøre et eksternt skript for å teste koden min på eksterne maskiner, vil gevinstene fra den bedre PHPUnit-integrasjonen er rådende.
Som de fleste IDE er Phpstorm også prosjektorientert. Vanligvis i et prosjekt kan du ha kildefiler og tester. Som PhpStorm fungerer, krever det at du spesifiserer en enkelt mappe som mappen for tester. Jeg synes det er ganske nyttig å ha samme katalogstruktur mellom kildekoden og testkoden. Dette hjelper PhpStorm til å finne tester enklere og lar deg bytte mellom produksjonskode og tester med en enkelt snarvei.
Men det er ikke alt. Når det gjelder å finne og åpne filer, er det en unik funksjon i PhpStorm: Gå til Alt (eller Søk Alt) - Jeg elsker absolutt denne. Først av alt, standard tastaturgenvei til Shift + Shift (dobbeltskift) er så naturlig å bruke, for det andre er det den mest nyttige navigasjonsfunksjonen. Det ble nylig introdusert, og før det hadde vi separate navigasjonsbokser og snarveier for Åpne fil ved navn, Åpne fil etter klassenavn, åpen fil inneholder symbolet (variabel eller metodenavn) og så videre. Nå kan jeg bare doble skift og begynne å skrive. Det er utrolig og raskt.
Det er så mange kule funksjoner i dagens IDEer at vi kunne fortsette med denne historien for ytterligere tre opplæringsprogrammer og fortsatt ikke fortelle alt. Men vi må stoppe på et tidspunkt. Så som en flott etterbehandling for vår mini-maraton av PHPUnit-funksjoner i PhpStorm, er det noen få siste som mine kolleger og jeg på Syneto setter pris på:
Accentsconagua
hg"kommandoen sannsynligvis to ganger eller så bare virker.OK, nok snakk. Jeg vil nå la deg gå, laste ned og prøv PhpStorm selv. Ha det gøy.
