Share
Åh, jag älskar snabba och enkla redigerare. Jag är en Linux-användare, jag bodde flera år tillsammans med Kate och KWrite. Med några tweaks och plugins kunde jag göra dem väldigt smart. Jag skrev hela projekt i Perl, Bash och till och med några PHP och Java i dessa redaktörer. Jag kan uppskatta all entusiasm som går runt Sublime Text eller TextMate, men jag kunde inte leva utan en fullblåst IDE idag.
Jag observerade att det finns två slags programmerare. Den första typen har en tendens att använda program som kan erbjuda större och större kodmanipuleringsproduktivitet men på bekostnad av den abrupta inlärningskurvan och svårighetsgraden i bruk. Dessa programmerare är de som föredrar Vi (m) eller Emacs.
Den andra kategorin av programmerare tenderar att migrera från enkla redigerare till IDE. Detta är lika naturligt för en utveckling som den första kategorin. Det leder emellertid till en annan tankegång och en annan bild av projektet och koden. Jag är en programmerare från denna kategori så i denna artikel kommer vi att prata om IDE jag använder för tillfället: PhpStorm.
Verktyg och användarinställningar för applikationer är så flyktiga att jag sällan skriver om en specifik ram eller applikation. Men om du använder en ansökan 10-14 timmar varje dag blir det en del av dig, en del av hur du ser din kod, dina projekt. Det blir motorvägen för din dagliga arbetsflöde. Så det förtjänar att nämnas och presenteras.
Jag brukade hämta en snabb textredigerare när jag behövde bara koda ett kort skript eller program. Men jag gör inte längre. Dagens datorer och IDE är så snabba att det finns liten skillnad mellan att starta PhpStorm och skriva koden eller starta KWrite och skriva koden. Applikationen själv är nästan lika snabb som en redaktör, och skapar ett projekt, även om en eller två faktiska filer inte är något långsammare att göra samma fil skapelser i din redaktör.
OK, OK ... Det här är alla likheter. Men vad handlar det här IDE om? IDE kommer från integrerad utvecklingsmiljö. Detta uttryck har två huvuddelar: integrerad och utvecklingsmiljö. Utvecklingsmiljödelen kan ses som redaktör och de specifika funktionerna för källkodsmanipulation: kodskrivningsfunktioner, framhäva, auto-complete, komplexa redigeringsfunktioner som multi-select och multi-edit, refactoringverktyg och så vidare. Integrationsdelen kan ses som integration mellan ovanstående utvecklingsmiljö och olika externa verktyg, testramar, dokumentversionssystem, debuggers och UI-byggverktyg.
Nyckelfunktionen i en IDE är dess förståelse av koden du skriver. En IDE har inte bara en lista över kommandot du kan använda i ditt favorit språk, som PHP. Det har komplexa algoritmer för att förstå din kod. PhpStorm kommer inte att föreslå dig ett kommando eller uttryck som skulle vara syntaktiskt felaktigt. Det vet till exempel att du inte kan skriva "skriva ut ("Hello World");"direkt inuti en klass, utan att lägga in en funktion. Så det kommer inte att föreslå"skriva ut()"kommandot när det inte kan användas. Men det här är bara toppen av isberget. Låt oss se några mer konkreta exempel.
Ja. Om du har läst de två första delarna av Refactoring Legacy Code-serien, The Golden Master och Magic Strings & Constants, kan du ha observerat att det finns skärmdumpar som visas i handledningen med en IDE. Så ser min PhpStorm ut. Och följande är hur PhpStorm hjälper mig när jag lär dig att programmera.
Detta är viktigt. De flesta enkla redigerare kan också göra grundläggande kodmarkering, men en IDE är en annan historia. Här kan du ha olika markeringsinställningar för olika språk som PHP, HTML, CSS och så vidare. Var och en med egna regler. Till exempel gillar jag att ha strängar gröna i CSS och orange i PHP och HTML.
Till vänster kan du se alla filtyper och språk som stöds (vissa kan läggas till med plugins), i mitten kan du se de olika PHP-språkelementen som kan konfigureras separat, i övre högra hörnet är alternativen varje element kan ha, och längst ner finns en förhandsvisning.
När vi letade efter magiska strängar i vår refactoring-session kunde vi enkelt upptäcka dessa strängar genom att bara hitta oransje på skärmen. Detsamma gäller för magiska konstanter och siffror. När de sökte efter var den blå färgen vår vän.
Struktur och layout är viktigt när vi behöver förstå källkod, och korrekt färgning och markering är väsentlig i denna fråga.
Jag har använt många IDEs och redaktörer under hela min karriär. Den som jag verkligen gillade och uppskattade var NetBeans. Men efter ungefär fem år av exklusiv NetBeans användning, var jag tvungen att ge upp det. Det finns något PhpStorm kan erbjuda, som ingen annan redaktör eller IDE för PHP kan göra. Detta är en uppsättning refactoringverktyg som behövs i vårt dagliga arbete.
Markering, indragning, projektledning, mallar, makron är alla funktioner som finns i de flesta redaktörer. Integrationer med testmiljöer och debuggrar är per definition en del av någon IDE. Smarta och komplexa refactoringverktyg är dock en helt annan historia.
Som programmerare spenderar vi hälften av vår tidskod, cirka 40% modifiera och refactoring befintlig kod, och om vi har tur, riktigt lyckliga, 10% skriver helt ny kod. Så att ha bra, snabba och pålitliga refactoringfunktioner hjälper oss att koncentrera våra ansträngningar mer på vad som ska refactor och mindre om hur man gör det. Vi sparar tid också, men jag anser att vinsten i mindre ansträngning blir mycket viktigare. När du kan förkasta tanken om processen i din IDE, och bara tänka på logiken, algoritmen, beroendet, SOLID-principerna, är det en produktivitetsvinst som måste övervägas.
Därför lämnade jag den fria och öppna källan NetBeans för den betalda PhpStorm. Det finns i PhpStorm en uppsättning refactoringverktyg som gör den speciell, gör det värt att betala för.
En av de enklaste refactorings som vi redan har arbetat med i Magic Strings & Constants var Introducer Local Variable, även känd som "Extract Variable". Här är en påminnelse om de steg vi måste ta för att använda denna refactoring:
Dessa steg är lätta att följa om vi har ett enda värde som ska omvandlas till en variabel, men hur är det med steg två? Hur hittar du tillförlitligt alla förekomster av det värdet? Du måste analysera din kod och ta medvetna beslut om vad du ska ersätta och vad, inte. Här är ett exempel.
klass SomeClass funktion printAPairOfPlayers () echo "Spelare är:"; echo "Spelarens namn:". $ This-> getRandomPlayerName (); echo "Spelarens namn:". $ This-> getRandomPlayerName (); funktion printOnePlayer () echo "Spelarens namn:". $ This-> getRandomPlayerName (); funktion getRandomPlayerName () // En del logik för att hitta spelarnamn // returnera $ playerName;
I printAPairOfPlayers () vi kan observera att strängen "Spelarnamn: "upprepas två gånger. Om vi vill extrahera strängen till en lokal variabel, en variabel inuti funktionen, måste vi ersätta båda händelserna i printAPairOfPlayers () men inte den i printOnePlayer (). Om printOnePlayer () skulle vara 100 linjer nedan, kanske vi inte ens inser att det finns en annan dubblering av strängen i en annan metod.
Så vi vill ha en lokal variabel. Vi skapar först variabeln, kör testen, leta efter strängen och hitta den i den andra eko uttalanden. Vi ersätter det, kör testen, vi ser igen, vi hittar den i det sista eko uttalande, ersätter vi det, vi kör testen. Vi ser igen, vi når slutet av metoden. Vi bestämmer att vi är klara med vår extrakt lokala variabel refactoring. Detta är en ganska krävande kognitiv process, särskilt med ful och inte väl förstådd kod.
Skulle det inte vara användbart att trycka på en enda genväg, eller välj ett alternativ i en snabbmeny och ha allt detta gjort av IDE? Det skulle vara fantastiskt, och PhpStorm är ganska kapabel att göra det för dig.
I koden ovan placerar du bara markören i "Spelarnamn: "sträng var som helst och Högerklicka.
Efter att ha valt "Extrahera variabel ... ", PhpStorm analyserar din kod och söker efter olika bitar av kod du kanske vill extrahera. Det kommer att föreslå två möjligheter för vårt fall.
Detta är inte bara en cool funktion, men en mycket användbar. Det finns så många fall när dubbelarbete kan ske utanför ditt synfält. När en extraktion föreslås görs analysen av PhpStorm genom hela koden, inte bara de få linjer som du kan se på skärmen. I det här fallet är alternativen uppenbara. För vår övning, låt oss välja bara strängdelen utan sammankoppling.
Nu när koden vi vill extrahera identifierades, är nästa steg att namnge det. "playerHeadersString"verkar vara ett förnuftigt variabelt namn. Du behöver inte sätta"$"före namnet i inmatningsfältet. PhpStorm sätter det i koden för dig automatiskt. En annan viktig aspekt är att det finns en kryssruta. PhpStorm hittade alla förekomster för vår variabel. Vi valde att extrahera en lokal variabel, så PhpStorm visste att man endast kunde söka i den nuvarande metoden och det hittade bara två förekomster. Samma sträng i metoden printOnePlayer (), räknades inte eller föreslogs, och det kommer inte att ersättas. Det skulle leda till felaktig kod, och PhpStorm är tillräckligt smart för att inte skriva ogiltig kod för dig.
En annan fördel med PhpStorm är att du inte behöver köra dina test ofta. När vi gjorde en manuell refactoring kör vi våra test efter varje steg. Om vi gjorde ett typsnitt eller ersatt något som vi trodde var detsamma men i verkligheten inte var det, behövde vi ett säkerhetsnät för att snabbt berätta för oss det. PhpStorm ersätter emellertid inte något som inte är logiskt korrekt i sammanhanget. Du kan bli förvånad över att ett stycke kod du också förväntat dig att bli utdraget kommer inte att vara, men du kan åtminstone vara säker på att den resulterande koden kommer att vara korrekt. Dessutom har vi mindre steg. Manuellt gör vi bara ett steg. Efter det enda steget måste vi köra våra tester en gång.
Det spelar ingen roll hur du ser på det, det är lättare, snabbare och mycket mindre felaktigt än något annat sätt att göra refactoring.
För att extrahera vår sträng till en klassvariabel - även känd som klassfält - kan vi använda "Extraheringsfält"refactoring alternativ från samma meny som ovan. Vi kommer att bli ombedda att identifiera kodstycket vi behöver extrahera, och vi kommer att presenteras med en något annorlunda blankett.
Förutom sitt namn har vi nu tre funna händelser. PhpStorm visste att vi ville ha en klassvariabel och det kunde identifiera samma sträng vid behov. Vi har också möjligheter att initiera variabeln på olika ställen och ställa in synligheten. Genom att välja alternativen som i bilden kommer den resulterande koden att vara som nedan.
Självklart, om du vill att den ska vara offentlig eller initierad i konstruktören, behöver du bara välja lämpliga alternativ och låta PhpStorm göra jobbet för dig.
När du tar bort en variabel vill du initiera den så nära den första användningen som möjligt. I de flesta fall är det enkelt, särskilt om det finns en enda användning av variabeln. Men hur är det med mer komplicerade fall? Låt oss återkomma till en av våra variabla extraktioner från Magic Strings & Constants.
I rulla() metod, på rad 73 - den valda - det finns ett nummer "11". Det är ett magiskt nummer som vi just identifierat och vi vill extrahera det.
Om vi gör vår extraktmetod för hand, måste vi följa dessa steg:
Nu är det komplicerat för en människa att göra. Och det är felaktigt. Vi antar att du har test som kan hjälpa dig, men vad händer om du arbetar med någon obskyr, otestbar kod? PhpStorm kommer att förstå kontexten för din kod. Det kommer att extrahera variabeln korrekt för alla händelser och ställa den exakt var den borde vara.
Vad vi presenterade ovan om refactoringverktyg är bara toppen av isberget. Extraktionsvariabler är förmodligen det enklaste och enklaste refactoring du kan göra. Vi använde ännu inte extraktionsmetod eller extraklassiklass eller till och med några mer komplexa namn i våra refactoring lektioner, men vi kommer att göra det. Vi lär oss hur du gör dem för hand, men jag uppmanar dig att använda ett smart IDE för att göra jobbet för dig.
PhpStorm är mycket bra för att omdöpa variabler eller metoder även över hundratals klasser. Föreställ dig hur svårt det är att ändra namnet på en offentlig metod som används i 100 olika klasser i ditt projekt. PhpStorm kan göra det fem minuters jobb istället för ett två timmars jobb. Det kan hitta och ändra namnet på alla metoder och du behöver bara kolla efter miss matcher innan du berättar att den ska fungera.
Ja, ja ... Du måste verifiera några funna händelser eftersom PHP är ett dynamiskt skrivet språk och i vissa fall finns det bara inget sätt att PhpStorm eller någon annan IDEs algoritm eller program för den delen kan veta vilken typ av objekt som är används för det specifika metodsamtalet. Tänk dig, du har två helt olika klasser. På var och en av dem har du en offentlig metod som heter "hitta alla()". Detta är mycket vanligt och korrekt.
Nu finns det 50 klasser med din första klass och ytterligare 50 med den andra. Om du använde korrekta gränssnitt och skriver hinting där det är möjligt, kommer PhpStorm att föreslå de korrekta klasserna att ändra. Men om du inte angav vilken typ du använder, eller du använde inte något gränssnitt som implementerats av din klass med hitta alla() metod, det finns inget sätt att berätta automatiskt, vilken av dina två klasser som båda har en hitta alla() metod, kommer att användas. Det är kärnan i PHP: s dynamiska skrivning. Men medan det här är en fördel i vissa fall är det en nackdel när vi behöver göra refactoring så här. När detta händer är det enda som kan göras för en människa att utvärdera behovet av förändringen.
Med alla dessa, även om det finns andra refactorings närvarande i PhpStorm, är det redan den bästa IDE bara med refactorings. Omdirigering, extrahering och inlining av variabler, extrahering och inlining metoder är de mest använda refactorings vi gör varje dag. Om dessa fungerar bra har vi en vinnande IDE.
Men PhpStorm slutar inte här. Den har många andra refactoringverktyg som gör att du mår bra i svåra situationer. Det har verkligen det "körsbär på toppen"känsla.
Du gör TDD, eller hur? Om du inte gör det borde du. Testning är lika viktigt för programmering som att skriva själva produktionskoden. Jag kunde inte föreställa mig mitt liv utan TDD. Jag har varit så van vid det under de senaste åren, att även tänka på kod utan att tänka på testen känner sig onaturligt och svårt.
Med testning måste din process och verktyg vara lika bra som själva produktionskoden. PhpStorm har stor integration med PHPUnit. Det är den enda PHP IDE jag vet om som faktiskt länkar direkt till PHPUnit-ramen, utökar den och använder den för att samla all information som behöver presenteras. Detta ger en mycket mer intim anslutning till PHPUnit, en bättre utgång för användaren och mycket högre testhastigheter.
Andra IDE tenderar att bara använda PHPUnit körbar, skriva utdata till en XML-fil och tolka resultaten för att visa den för dig. Så fungerar NetBeans. Detta tillvägagångssätt ger högre flexibilitet för dig, användaren, om du vill hacka systemet och övertyga det om att köra dina tester på ovanliga sätt (till exempel via telnet eller SSH). Men det här har också en stor nackdel. Saker blir långsamma. Först av allt måste en skalprocess gafflas. "exec ()"är alltid en viktig tidskonsument. Då måste resultatet skrivas till en fil, eventuellt på en fjärrmaskin.
Vi vet alla att filsystemet är långsamt, mycket långsamt. SSD-enheter gör det lite bättre, men de är fortfarande ljusår borta från RAM-hastigheten. Då, om vi kör fjärrkontrollen, måste vi kopiera den filen till vår maskin. Så inte bara behöver vi slå filsystemet en gång, vi måste också lägga till den tiden, kostnaden för nätverkskommunikation plus skriva den till en lokal fil. Då måste filen läsas tillbaka, så att den äntligen kan visas för användaren.
Medan det är en super anpassningsbar och flexibel lösning, tar det bara tid. För mycket tid när vi tänker på enhetstester och millisekundstest. Enhetsprovningar som tar längre tid än fem millisekunder att köra är inte heller enhetstester.
PhpStorm löser, eller åtminstone sänker, överkostnaden genom att använda PHPUnit internt och berätta att resultatet ska utföras på samma sätt som PhpStorm föredrar. Detta minskar flexibiliteten. Du kan inte hacka det för att testa utanför dess gränser. Men det ökar hastigheten mycket. Inte mer exec, inga fler filer skrivna till långsamma filsystem. Fjärrkontrollen kan lägga till priset för nätverkskommunikation, men vi kan inte eliminera det ändå. En annan bra fördel är att direkt med hjälp av PHPUnit kan mer detaljerad information om misslyckade test presenteras på ett mer organiserat sätt. Så vi får fart, detaljer och tydlighet på bekostnad av flexibilitet.
Att vara van vid NetBeans började jag först och främst acceptera den här flexibiliteten, men i slutet av dagen, även om jag ibland måste köra ett externt skript för att testa min kod på fjärrmaskiner, skulle vinsterna från den bättre integrationen av PHPUnit är rådande.
Liksom de flesta IDE är Phpstorm också projektorienterad. Vanligtvis i ett projekt kan du få källfiler och test. Som PhpStorm fungerar kräver det att du anger en enda mapp som mapp för test. Jag tycker det är ganska användbart att ha samma katalogstruktur mellan källkod och testkod. Detta hjälper också PhpStorm att lättare hitta dina tester och låter dig växla mellan produktionskod och test med en enda genväg.
Men det är inte allt. När det gäller att hitta och öppna filer finns en unik funktion i PhpStorm: Gå till Allt (eller Sök allt) - Jag älskar absolut den här. Först av allt, dess standard tangentbord genväg av Skift + Skift (dubbelskift) är så naturlig att använda, för det andra är det den mest användbara navigationsfunktionen. Det introducerades bara nyligen, och före det hade vi separata navigeringsrutor och genvägar för öppna fil med namn, öppna fil med klassnamn, öppna fil innehållande symbolen (variabel eller metodnamn) och så vidare. Nu kan jag bara dubbla skift och börja skriva. Det är fantastiskt och snabbt.
Det finns så många coola funktioner i dagens IDE som vi kunde fortsätta med den här historien för ytterligare tre tutorials och forteller inte allt. Men vi måste sluta vid någon tidpunkt. Så som en utmärkt efterbehandlare för vår mini marathon av PHPUnit-funktioner inom PhpStorm, här är några några sista som mina kollegor och jag på Syneto uppskattar:
Accentsconagua
hg"kommandot förmodligen två gånger eller så bara Arbetar.Okej, prata nog. Jag ska nu låta dig gå, ladda ner och prova PhpStorm själv. Ha så kul.
