Edytor kodu to najważniejsze narzędzie, z którego korzystam w codziennej pracy. Służy mi nie tylko do pisania mojego kodu, ale przede wszystkim do czytania kodu, który został napisany przez innych programistów. Dlatego tak ważne dla mnie jest, żeby obsługa była wygodna i intuicyjna a praca możliwie jak najbardziej efektywna.
Orły i sokoły
Na wstępie muszę zaznaczyć, że nie jestem żadnym autorytetem w dziedzinie obsługi edytora kodu: relatywnie niedawno zaczęłam interesować się optymalizacją mojej pracy za pomocą sprawnej obsługi tego narzędzia – wcześniej skupiałam się wyłącznie na nauce języka oraz frameworków czy bibliotek. Z czasem jednak zaczęłam dostrzegać, ile czasu zajmuje mi „wyklikiwanie” myszą rzeczy, które mogłabym zrobić za pomocą skrótu klawiszowego. To uwieranie stało się dla mnie naturalną motywacją do nauki obsługi mojego edytora.
Edytor a IDE
Również na początku muszę dokonać pewnego rozróżnienia: otóż nie każdy edytor to tylko edytor, niektóre narzędzia to IDE, skrót od Integrated Development Environment, czyli zintegrowanego środowiska programistycznego. Edytor to po prostu program, który pomaga pisać i czytać kod poprzez kolorowanie składni, podpowiadanie kodu, integrację z systemem kontroli wersji czy wsparcie przy debugowaniu kodu. Natomiast IDE to – jak wskazuje nazwa – całe środowisko, które służy do uruchomienia, debugowania, testowania czy refactoringu kodu źródłowego, jak również umożliwia obsługę innych elementów projektu, jak np. bazy danych.
W dalszych rozważaniach używam słowa „edytor” na określenie zarówno prostych narzędzi jak i IDE.
Który najlepszy?
Jak to zwykle bywa, w internecie znajduje się mnóstwo opinii na temat tego, który edytor jest najlepszy. Nie spotkałam się z żadną „świętą wojną” zwolenników i przeciwników jakiegoś narzędzia (jak to się czasem zdarza w przypadku „hoolsów” któregoś z frameworków), ale opinii jest wiele, a narzędzi do wyboru sporo. Nie zamierzam zabierać głosu w tej dyskusji z prostego powodu: kiedy zaczynałam uczyć się programowania, zainstalowałam Visual Studio Code, który tak mi się spodobał, że zdarza mi się korzystać z niego prywatnie do dzisiaj. Projekt, w którym pracuję wymusił na mnie pracę w IntelliJ (którym jestem zachwycona), jednak na potrzeby pisania domowych projektów obejmujących jedynie kod w JavaScript czy TypeScript jest zupełnie wystarczający. Zatem jako użytkownik jedynie dwóch z całej plejady edytorów nie mam za dużo do powiedzenia 😉
Obecnie jednak moja nauka obsługi narzędzia skupia się w głównej mierze na IntelliJ. Nie stanowi to wielkiego problemu, ponieważ edytory umożliwiają importowanie ustawień skrótów klawiszowych z innych edytorów. Tak oto w VS Code można skorzystać z wtyczki „IntelliJ IDEA Keybindings” i cieszyć się skrótami zaproponowanymi przez JetBrains. Analogicznie przeniosłam ustawienia kolorystyczne z VS Code do IntelliJ.
Pierwsze kroki
W moim przypadku wybór Visual Studio Code podyktowany był tutorialem z JavaScript, który oglądałam na początku nauki. Prowadzący korzystał z VS Code i chcąc nadążać za materiałem bez zbędnego zagłębiania się w wątki poboczne, zdecydowałam się skopiować w miarę możliwości jego środowisko. W międzyczasie obejrzałam na YouTube kilka filmów o konfiguracji i instalacji wtyczek i voila! Mogłam już ruszać samodzielnie w nieznane odmęty kodowania. W międzyczasie wydrukowałam sobie i zalaminowałam ściągawkę ze skrótów klawiszowych.
Z InteliiJ było trochę inaczej, najpierw małe wprowadzenie i konfigurację otrzymałam od kolegów z zespołu, później sama oglądałam tutoriale na YouTube (choćby oficjalne materiały dostępne tutaj). Również posiłkuję się zgrabnym pdfem, który zbiera najważniejsze skróty klawiszowe.
Im dalej w las, tym więcej drzew
Praca z IntelliJ jest dla mnie o wiele trudniejsza niż VS Code z powodu o wiele bardziej wymagającego projektu, ot i cała tajemnica. To jednak również szansa, żeby zwrócić uwagę na większą uwagę na aspekt produktywności, o której pisałam na wstępie, a narzędzia JetBrains bardzo tę produktywność wspierają. Zakładka Productivity Guide pokazuje statystyki użycia wbudowanych udogodnień, takich jak np. uzupełnianie tekstu czy komentowanie kodu.
Dodatkowo do każdej funkcjonalności znajduje się opis, więc śmiało mogę wyszukać „ficzery”, których nigdy nie używałam i zacząć wprowadzać do codziennej pracy.
Niestety, nie wszystko jest tak klarowne i widoczne na pierwszy rzut oka. Dla mnie największym problemem na początku pracy z IntelliJ były baaardzo małe i nierzucające się w oczy komunikaty.
W swojej pracy dość często muszę przełączać się między VPNami, a tylko jeden z nich gwarantuje dostęp do zdalnego repozytorium. Zdarzyło mi się, że uaktualniłam projekt, zbudowałam i uruchomiałam (około 5 – 7 minut), po czym okazało się, że z powodu błędnego VPNa kod nie mógł zostać zaktualizowany, o czym IntelliJ informuje komunikatem pisanym szarym tekstem czcionką 10 px w lewym dolnym rogu 😉 (zaznaczone krzyżykami).
Mam też swoje preferencje jeżeli chodzi o wyszukiwanie fragmentów kodu: zdarza mi się, że włączam VS Code tylko po to, żeby w bardziej przejrzysty dla mnie sposób wyszukać pewną frazę, pomimo że IntelliJ oferuje kilka różnych sposobów wyszukiwania.
Jak się uczę?
Przede wszystkim nie wszystkiego na raz. Często podczas pisania wyłapuję czynność, którą po raz n-ty wykonuję myszą i wyszukuję do tego skrót klawiszowy. Po jakimś czasie wchodzi mi to po prostu nawyk.
Kopalnią rozwiązań jest dla mnie pair programming, gdzie obserwuję moich kolegów w jaki sposób oni piszą i co potrafią zrobić dużo szybciej ode mnie. Wtedy staram się osiągnąć ten sam efekt lub po prostu zadaję pytania.
Podsumowując
W moim przypadku potrzeba zwiększenia produktywności wynika z wewnętrznej frustracji, świadomości, że mogłabym coś zrobić szybciej, lepiej i bardziej efektywnie. Jest to w moim przekonaniu najlepszy rodzaj motywacji, czyli wewnętrzna potrzeba. Każdego dnia staram się wprowadzać małe udoskonalenia procesu wytwarzania kodu, tak aby w efekcie po dłuższym czasie zaobserwować znaczną poprawę.