Pulpit programistyczny może wyglądać na zajęty, ukrywając jedną potrzebną informację. Edytor, podgląd, terminal, dokumentacja i narzędzie do śledzenia problemów są istotne, ale nie są równie istotne w każdym momencie.
Zamiast wybierać układ dlatego, że przypomina konfigurację innej osoby, prześledź jedną zwyczajną zmianę od początku do końca. Najlepszy układ tej pętli jest bardziej użytecznym punktem wyjścia niż stała siatka każdego używanego narzędzia.
Krótka odpowiedź
Rozmieść okna wokół pętli „edytuj – uruchom – sprawdź”. Daj redaktorowi wystarczająco dużo miejsca, trzymaj wynik blisko i pokazuj dokumentację lub dzienniki, gdy odpowiada na konkretne pytanie.
Zaplanuj jeden mały cykl rozwoju
Weź normalną zmianę: dostosuj formularz, napraw nieudany test lub sprawdź transformację danych. Zapisz, gdzie edytujesz, jak to uruchamiasz i gdzie sprawdzasz wynik. To powierzchnie robocze, które zasługują na wygodne pozycje.
W przypadku interfejsu opartego na przeglądarce pętlą może być edytor, terminal, przeglądarka. W przypadku narzędzia wiersza poleceń może to być edytor i terminal z dokumentacją w pobliżu. W przypadku aplikacji natywnej wynikiem może być działająca aplikacja lub symulator. Pojedynczy, zalecany układ nie może pasować do wszystkich równie dobrze.
Zamknij niepowiązane okna projektów dopiero po zapisaniu potrzebnej pracy. Pozostaw aktywne zadanie z rozpoznawalnym zestawem okien, aby móc stwierdzić, czy układ jest pomocny, przed dodaniem kolejnych narzędzi.
Nadaj edytorowi szerokość opartą na treści
Dopasuj edytor do kodu i paneli, których faktycznie potrzebujesz. Drzewo plików, drugi panel edytora i diagnostyczny pasek boczny zajmują miejsce przed rozpoczęciem kodu. Jeśli czytanie pliku centralnego stanie się niewygodne, usuń panel, którego nie potrzebujesz lub poszerz okno.
Układ przewijany może zachować wybraną szerokość, podczas gdy do paska dodawane są dodatkowe okna. W Glidro gotowe ustawienia zmiany rozmiaru ułatwiają ponowne przeglądanie powtarzających się rozmiarów. Wybierz mały, użyteczny zakres, zamiast próbować przewidzieć każdy możliwy układ.
Nie rozwiązuj problemu szerokości okna, zmniejszając tekst, dopóki nie zmieści się każde narzędzie. Jeśli tekst jest trudny do sprawdzenia, widoczna gęstość staje się kosztem. Zachowaj szerokość umożliwiającą edycję, a następnie w razie potrzeby przejdź do okna pomocniczego.
Umieść wynik w miejscu, w którym będziesz go sprawdzał
Umieść podgląd obok edytora, gdy często je porównujesz. Jeśli chcesz widzieć oba jednocześnie, sprawdź, czy połączona szerokość pozostawia widoczną użyteczną treść. Jeśli podgląd wymaga szerokiej rzutni, przełączaj się między pełnymi widokami roboczymi, zamiast wymuszać wprowadzające w błąd wąskie porównanie.
Szerokość okna przeglądarki jest częścią testu interfejsu internetowego, dlatego należy jasno określić, co obserwujesz. Podgląd zawężony układem pulpitu nie zastępuje celowego testu responsywności. Oddziel pytanie „czy mogę zobaczyć swój wynik?” z pytania „czy przetestowałem właściwą rzutnię?”
Jako drugi wyświetlacz użyj go, gdy pomaga ciągła widoczność. Zachowaj rezerwę dla tego samego projektu wyłącznie na laptopie, aby oddokowanie nie zakłócało zrozumienia przepływu pracy.
Daj terminalom i logom zadanie
Trzymaj terminal używany do bieżącego polecenia blisko edytora lub wyniku. Oznacz lub w inny sposób rozróżnij sesje na podstawie własnych funkcji terminala, jeśli Twoja aplikacja je obsługuje. Rząd wizualnie podobnych muszli sprawia, że nawigacja przestrzenna jest mniej użyteczna, ponieważ cel podróży pozostaje niejednoznaczny.
Przenieś dziennik, aby odpowiedzieć na pytanie, a następnie wróć do kodu. Jeśli podczas odtwarzania musisz stale oglądać wydruk, zapewnij mu widoczną przestrzeń na tę fazę. Nie zakładaj, że każdy proces w tle zasługuje na stale widoczne okno.
Zdecyduj, czy do tego projektu pasują terminale zintegrowane z edytorem, czy osobne okna. Menedżer kontroluje okna, a nie każdy wewnętrzny panel edytora. Użyj własnej nawigacji edytora dla treści znajdujących się w nim i elementów sterujących oknami dla przejść między aplikacjami.
Chroń kontekst projektu i własność skrótu
Oddziel niepowiązane projekty, gdy ich okna przeglądarki i terminale są zbyt łatwe do pomylenia. Granica zadania może pomóc w rozpoznaniu, które repozytorium, podgląd i notatki należą do siebie. Przed wydaniem kolejnych poleceń potwierdź katalog roboczy i środowisko docelowe za pomocą samych narzędzi.
Sprawdź skróty okien pod kątem powiązań edytora i terminala. Kombinacja klawiszy używana do przenoszenia słów, poleceń terminala lub nawigacji w edytorze nie powinna stać się niespodziewaną akcją układu. Przetestuj wybrane powiązanie w rzeczywistych aplikacjach na pierwszym planie i zmień jednego właściciela, gdy pojawi się konflikt.
Glidro zapewnia edytowalne skróty i elementy sterujące dołączaniem aplikacji. Użyj ich, aby dopasować je do posiadanych narzędzi programistycznych, a następnie zachowaj prostą ścieżkę pauzy, gdy specjalne okno wymaga zwykłej obsługi. Nasz istniejący Przewodnik konfiguracji kodowania MacBooka zawiera uzupełniający przewodnik dotyczący laptopa.
Częste pytania
Czy terminal powinien zawsze pozostać widoczny?
Tylko wtedy, gdy liczy się ciągła wydajność. W przypadku wielu zadań wystarczy trzymać go w pobliżu i łatwo się skupić.
Czy menedżer okien może zorganizować okienka edytora?
Zarządzanie oknami działa na poziomie okna. Użyj własnych elementów sterujących edytora dla zakładek, paneli wewnętrznych i zintegrowanych terminali.
