Ett utvecklingsskrivbord kan se fullt ut samtidigt som det döljer informationen du behöver. Kodredigeraren, förhandsvisningen, terminalen, dokumentationen och ärendehanteraren kan alla vara relevanta, men inte lika mycket i varje ögonblick.
Välj inte en layout bara för att den liknar någon annans. Följ i stället en vanlig ändring från början till slut. Ett arrangemang som passar det arbetsflödet är en bättre utgångspunkt än ett permanent rutnät för varje verktyg du använder.
Kort svar
Ordna fönstren kring arbetsflödet redigera, köra och granska. Ge kodredigeraren tillräckligt med utrymme, håll resultatet nära och visa dokumentation eller loggar när de hjälper dig att besvara en konkret fråga.
Kartlägg en liten utvecklingscykel
Gör en normal förändring: justera ett formulär, fixa ett underkänd test eller inspektera en datatransformation. Skriv ner var du redigerar, hur du kör det och var du inspekterar resultatet. Det här är arbetsytorna som förtjänar bekväma positioner.
För ett webbläsarbaserat gränssnitt kan loopen vara kodredigerare, terminal och webbläsare. För ett kommandoradsverktyg kan det vara kodredigerare och terminal med dokumentation i närheten. För en inbyggd app kan resultatet bli en körapp eller simulator. Ett enda föreskrivet arrangemang kan inte passa alla dessa lika väl.
Stäng icke-relaterade projektfönster först efter att du har sparat det arbete du behöver. Lämna den aktiva uppgiften med en igenkännbar uppsättning fönster så att du kan se om layouten hjälper innan du lägger till fler verktyg.
Ge kodredigeraren en innehållsbaserad bredd
Anpassa kodredigerarens storlek efter koden och panelerna du faktiskt behöver. Filträd, en extra redigeringsruta och diagnostikpanelen tar plats innan du ens kommer till koden. Om den centrala filen blir obekväm att läsa, ta bort paneler du inte behöver eller vidga fönstret.
En rullande layout kan bevara den valda bredden medan ytterligare fönster läggs till i remsan. I Glidro gör förinställda storleksändringar det lätt att återbesöka återkommande storlekar. Välj ett litet användbart utbud istället för att försöka förutse alla möjliga arrangemang.
Lös inte ett problem med fönsterbredd genom att krympa text tills varje verktyg passar. Om text är svår att inspektera har den synliga tätheten blivit en kostnad. Behåll den bredd som stöder redigering och navigera sedan till stödfönstret när det behövs.
Placera resultatet där du ska inspektera det
Placera förhandsgranskningen bredvid kodredigeraren när du jämför dem ofta. Om du behöver se båda samtidigt, kontrollera att de kombinerade bredderna lämnar det användbara innehållet synligt. Om förhandsgranskningen behöver en bred vy, växla mellan fullständiga arbetsvyer istället för att tvinga fram en missvisande alltför trång jämförelse.
En webbläsarfönsterbredd är en del av ett webbgränssnittstest, så var tydlig med vad du observerar. En förhandsgranskning som gjorts smal av skrivbordslayouten är inte en ersättning för ett medvetet responsivt test. Separera frågan "kan jag se mitt resultat?" från "har jag testat rätt visningsport?"
För en andra skärm, använd den när kontinuerlig synlighet hjälper. Behåll en reserv för enbart bärbar dator för samma projekt så att avdockning inte bryter din förståelse av arbetsflödet.
Ge terminaler och loggar ett jobb
Håll terminalen som används för det aktuella kommandot nära editorn eller resultatet. Märk eller särskilj sessioner på annat sätt genom terminalens egna funktioner om din app stöder dem. En rad med visuellt liknande skal gör navigering mellan fönster mindre användbar eftersom destinationen förblir tvetydig.
Ta fram en logg för att svara på en fråga och återgå sedan till koden. Om du måste titta på utdata kontinuerligt under en reproduktion, ge det synligt utrymme för den fasen. Anta inte att varje bakgrundsprocess förtjänar ett permanent synligt fönster.
Bestäm om terminaler som är integrerade i redigeraren eller separata fönster passar detta projekt. Hanteraren kontrollerar fönster, inte alla interna redigeringsfönster. Använd kodredigerarens egen navigering för innehåll i den och fönsterkontroller för övergångar mellan appar.
Skydda projektkontext och genvägsägande
Separera orelaterade projekt när deras webbläsarfönster och terminaler är för lätta att blanda ihop. En uppgiftsgräns kan hjälpa dig att känna igen vilket arkiv, förhandsgranskning och anteckningar som hör ihop. Bekräfta arbetskatalogen och målmiljön genom själva verktygen innan du utfärdar följdkommandon.
Granska fönstergenvägar mot din kodredigerare och terminalbindningar. En tangentkombination som används för ordförflyttning, ett terminalkommando eller redigeringsnavigering bör inte bli en överraskningslayoutåtgärd. Testa den valda bindningen i de faktiska förgrundsapparna och ändra tilldelningen i den app där konflikten uppstår.
Glidro tillhandahåller redigerbara genvägar och kontroller för appinkludering. Använd dessa för att passa de utvecklingsverktyg du har, behåll sedan en enkel pausrutt när ett speciellt fönster behöver vanlig hantering. Vår befintliga inställningsguide för MacBook-kodning erbjuder en kompletterande laptop-fokuserad genomgång.
Vanliga frågor
Ska terminalen alltid vara synlig?
Endast när kontinuerlig produktion är viktig. För många uppgifter räcker det att ha den nära och lätt att fokusera.
Kan en fönsterhanterare ordna redigeringsrutor?
Fönsterhantering fungerar på fönsternivå. Använd kodredigerarens egna kontroller för flikar, interna rutor och integrerade terminaler.
