Een ontwikkelomgeving kan er druk uitzien, terwijl het enige stukje informatie dat u nodig heeft verborgen blijft. De editor, preview, terminal, documentatie en issue tracker zijn allemaal relevant, maar ze zijn niet op elk moment even relevant.
In plaats van een lay-out te kiezen omdat deze lijkt op de opstelling van iemand anders, kun u beter één gewone verandering van begin tot eind volgen. De beste opstelling voor die lus is een nuttiger startpunt dan een permanent raster van elk gereedschap dat u gebruikt.
Kort antwoord
Rangschik de vensters rond uw edit-run-inspect-lus. Geef de editor voldoende ruimte, houd het resultaat dichtbij en breng documentatie of logs in beeld als zij een specifieke vraag beantwoorden.
Breng één kleine ontwikkelingscyclus in kaart
Neem een normale wijziging: pas een formulier aan, repareer een falende toets of inspecteer een datatransformatie. Schrijf op waar u bewerkt, hoe u het uitvoert en waar u het resultaat inspecteert. Dit zijn de werkoppervlakken die een handige positie verdienen.
Voor een browsergebaseerde interface kan de lus editor, terminal, browser zijn. Voor een opdrachtregelprogramma kan dit een editor en terminal zijn met documentatie in de buurt. Voor een native app kan het resultaat een actieve app of simulator zijn. Eén enkele voorgeschreven regeling kan niet allemaal even goed passen.
Sluit niet-gerelateerde projectvensters pas nadat u het benodigde werk hebt opgeslagen. Laat de actieve taak achter met een herkenbare reeks vensters, zodat u kunt zien of de lay-out helpt voordat u meer hulpmiddelen toevoegt.
Geef de editor een op inhoud gebaseerde breedte
Grootte van de editor rond de code en panelen die u daadwerkelijk nodig heeft. Een bestandsboom, een tweede editorvenster en een diagnostische zijbalk verbruiken allemaal ruimte voordat de code begint. Als het centrale dossier oncomfortabel wordt om te lezen, verwijder dan een paneel dat u niet nodig heeft of verbreed het venster.
Een scrollende lay-out kan de gekozen breedte behouden terwijl er extra vensters aan de strip worden toegevoegd. In Glidro zorgen voorinstellingen voor het wijzigen van de grootte ervoor dat terugkerende formaten gemakkelijk opnieuw kunnen worden bekeken. Kies voor een klein bruikbaar bereik in plaats van te proberen op iedere mogelijke regeling te anticiperen.
Los een probleem met de vensterbreedte niet op door de tekst te verkleinen totdat alle gereedschappen passen. Als tekst moeilijk te inspecteren is, is de zichtbare dichtheid een kostenpost geworden. Houd de breedte aan die bewerking ondersteunt en navigeer vervolgens naar het ondersteunende venster wanneer dat nodig is.
Plaats het resultaat waar u het gaat inspecteren
Plaats het voorbeeld naast de editor als u ze regelmatig vergelijkt. Als u beide tegelijk wilt zien, controleer dan of de gecombineerde breedten de nuttige inhoud zichtbaar laten. Als de preview een brede viewport nodig heeft, wissel dan af tussen volledige werkweergaven in plaats van een misleidende, beperkte vergelijking te forceren.
De breedte van een browservenster maakt deel uit van een webinterfacetest, dus wees expliciet over wat u waarneemt. Een voorbeeld dat beperkt is door de bureaubladindeling is geen vervanging voor een opzettelijke responsieve test. Scheid de vraag "kan ik mijn resultaat zien?" van “heb ik de juiste viewport getest?”
Gebruik een tweede scherm als continu zicht helpt. Zorg voor een reserve voor alleen een laptop voor hetzelfde project, zodat het loskoppelen uw begrip van de workflow niet schaadt.
Geef terminals en logs een taak
Houd de terminal die voor de huidige opdracht wordt gebruikt dicht bij de editor of het resultaat. Label sessies of onderscheid ze op andere wijze via de eigen functies van de terminal, als uw app deze ondersteunt. Een rij visueel vergelijkbare schelpen maakt ruimtelijke navigatie minder nuttig omdat de bestemming dubbelzinnig blijft.
Breng een logboek naar voren om een vraag te beantwoorden en keer dan terug naar de code. Als u tijdens een reproductie continu naar de output moet kijken, geef deze dan zichtbare ruimte voor die fase. Ga er niet vanuit dat elk achtergrondproces een permanent zichtbaar venster verdient.
Bepaal of in de editor geïntegreerde terminals of afzonderlijke vensters bij dit project passen. De manager beheert vensters, niet elk intern editorvenster. Gebruik de eigen navigatie van de editor voor de inhoud erin en vensterbedieningen voor overgangen tussen apps.
Bescherm de projectcontext en het eigendom van sneltoetsen
Scheid niet-gerelateerde projecten wanneer hun browservensters en terminals te gemakkelijk te verwarren zijn. Een taakgrens kan u helpen herkennen welke repository, preview en notities bij elkaar horen. Bevestig de werkmap en de doelomgeving via de tools zelf voordat u vervolgopdrachten geeft.
Sneltoetsen voor auditvensters voor uw editor- en terminalbindingen. Een toetsencombinatie die wordt gebruikt voor woordverplaatsing, een terminalopdracht of editornavigatie mag geen verrassende lay-outactie worden. Test de gekozen binding in de daadwerkelijke voorgrond-apps en verander één eigenaar wanneer er een conflict optreedt.
Glidro biedt bewerkbare sneltoetsen en bedieningselementen voor het opnemen van apps. Gebruik deze zodat ze passen bij de ontwikkeltools die u heeft, en gebruik vervolgens een eenvoudige pauzeroute als een speciaal venster een gewone behandeling vereist. Onze bestaande MacBook-coderingsinstallatiehandleiding biedt een aanvullende, op laptops gerichte walkthrough.
Veelgestelde vragen
Moet de terminal altijd zichtbaar blijven?
Alleen als continue output ertoe doet. Voor veel taken is het voldoende om hem dichtbij de hand te houden en hem gemakkelijk te kunnen concentreren.
Kan een vensterbeheerder editorvensters inrichten?
Vensterbeheer vindt plaats op vensterniveau. Gebruik de eigen bedieningselementen van de editor voor tabbladen, interne vensters en geïntegreerde terminals.
