Czy zastanawiałeś się kiedyś nad możliwościami swojego IDE? Jaki jest twój styl pracy ze środowiskiem programowania? Używasz go bardziej jako notatnik, czy korzystasz z wbudowanych skrótów klawiszowych czy innych zaawansowanych funkcji? Dowiedz się więcej o tym, że umiejętność programowania to także umiejętność obsługi narzędzi z tym związanych.
Dlaczego chcę się podzielić moimi spostrzeżeniami?
Pewnie wiele razy mogłeś przeczytać na tym blogu, że programowaniem interesuję się już od podstawówki. Od tego ważnego dla mnie momentu minęło już co najmniej kilkanaście lat Ale dopiero teraz, na praktykach, dowiedziałem się jaka moc drzemie we współczesnych środowiskach programistycznych. Uświadomiłem sobie, że wykorzystywałem jedynie bardzo niewielką część dostarczanych możliwości. Marnowałem czas na ręczne wykonywanie czynności, które program mógł zrobić za mnie. Traciłem cenne chwile życia na przekopywanie się przez dziesiątki menu i okienek konfiguracyjnych, kiedy wystarczyło użycie prostego skrótu klawiszowego.
Większość początkujących programistów nie zna tajników środowisk programistycznych, których używają, gdyż nikt nie uświadomił ich że jest to bardzo ważne. W jednym z poprzednich artykułów pisałem, że język programowania jest narzędziem. Teraz mogę uaktualnić swoją opinię i napisać, że te narzędzie jest częścią większej równie skomplikowanej maszynerii, której triki i tajniki również warto poznać w możliwie jak największym stopniu.
Czym jest środowisko programistyczne (IDE)?
Czym właściwie jest środowisko programistyczne? Niby proste pytanie, powiesz. Środowisko programistyczne służy do tego, aby ułatwić programiście pracę. Dzięki temu możesz poświęcać więcej czasu na właściwe rozwiązywanie problemu, a mniej czasu na bezproduktywną zabawę. IDE pomaga ci w szybkim nawigowaniu po kodzie projektu, nad którym pracujesz. Środowisko programistyczne wyręcza cię w końcu w obsłudze dodatkowych narzędzi, które są niezbędne do uruchomienia programu napisanego w danym języku programowania.
Jaki byłby świat gdyby nie te kombajny?
Wyobraź sobie, że rzucasz sobie wyzwanie. Polega ono na programowaniu używając jedynie windowsowego notatnika i konsoli cmd systemu Windows. Brzmi jak prawdziwa tragedia, prawda? Już pewnie cierpnie ci skóra, mój drogi czytelniku, na myśl o pracy w tak wyśmienicie wygodnym środowisku?
No cóż. Zacznijmy tę pracę. Uruchamiasz notepad. Zaczynasz pisać kod. Pojawiają się pierwsze dolegliwości odstawienne, wynikające z nagłego porzucenia prawdziwego IDE :). Zaczynasz widzieć świat w sposób czarno biały, niczym daltonista. Piękny, kolorowy, pogrubiony w wielu miejscach ze względu na słowa kluczowe kod zamienia się w jednokolorową mieszaninę różnych liter i cyfr.
Pod wpływem ogromnego bólu istnienia zaczynają powstawać kolejne linijki kodu. Pojedyncze funkcje zaczynają nabierać jakiegoś określonego kształtu. W końcu nadchodzi pora. Część kodu musi wyemigrować do innych plików.
Pojawia się kolejny problem. Dziesiątki otwartych okienek notepada zaczynają mieszać się w głowie. Kombinacja ALT+TAB próbuje niejako zastąpić braki, aczkolwiek marnym skutkiem.
W końcu nadchodzi pora na próbę uruchomienia programu, który powstał z potu i łez. Ale zaraz zaraz. Jeszcze trzeba go skompilować. Okno Bielutkie, posmagane w niektórych miejscach czarnymi pląśami zastępuje jednolicie czarne okienko cmd. Klawiatura pali się od długich linii komend kompilatora wpisywanych z prędkością światła.
Kompilacja nigdy nie udaje się za pierwszym razem. Najpierw trzeba właściwie wprowadzić polecenie, aby potem naprawić kilkanaście drobnych literówek. Pojawia się kolejny symptom odstawienny IDE – niezwykle ciężkie wyszukiwanie błędów. Nie pomaga także brak auto-uzupełniania poleceń.
Kompilator wyrzucił nam masę błędów i ostrzeżeń. Łaskawie poinformował nas co prawda o linijce, w której wystąpił problem. Jednakże powstaje problem liczenia tych linii w momencie, kiedy pliki mają ich już po kilkaset. Notepad nie obsługuje numerowania linijek co sprawia, że pracę tę musisz wykonać samodzielnie. Oczy zaczynają palić ze zmęczenia wynikającego we wpatrywanie się w zlewające się linijki kodu.
Nie dajesz rady. Wyzwanie nie zostało pokonane. Ty natomiast już wiesz, ile pozornie bardzo prostych problemów IDE rozwiązuje out of the box.
Co tracisz, nie umiejąc obsługiwać IDE?
Czas poświęcony na boilerplate-code
Duża część tworzonych programów to tzw. boilerplate code. Co mam na myśli? Linijki kodu, które właściwie się nie zmieniają i występują w takiej lub innej formie w każdym projekcie. Standardowym przykładem są gettery i settery w Javie. Są one praktycznie zawsze takie same. Przy klasie zawierającej dużo atrybutów ręczne napisanie kilkudziesięciu linijek kodu może zabrać kilkadziesiąt minut czasu i być naprawdę monotonne.
Łatwość refactoringu
Wyobraź sobie, że piszesz duży program. Po kilku dniach pracy zauważasz, że w wielu miejscach powtarza się jedna i ta sama wartość, która jest wpisana na sztywno w kod programu. Czy nie bardziej eleganckie byłoby wydzielenie takiej wartości do oddzielnej zmiennej/stałej? Oczywiście, że tak! Ale co się z tym wiąże? Konieczność utworzenia nowej zmiennej i tym samym zastąpienia wszystkich wartości wpisanych na sztywno w kod tą zmienną. Przy małym projekcie być może nie zajmie to zbyt dużo czasu. Ale co jeśli takich miejsc jest kilkaset a program podzielony jest na kilkadziesiąt plików? Wtedy taki problem to co najmniej kilka godzin wyjętych z życiorysu.
Spójność formatowania i czytelność kodu
Czytelność kodu jest naprawdę bardzo ważna. Szczególnie wtedy, jeśli ktoś będzie w przyszłości na nim pracował. Niezwykle istotna jest także spójność stylu. To, czy stawiamy klamrę otwierającą w tej samej linijce w której kończy się deklaracja metody czy dopiero w następnej może nie ma wpływu na działanie programu, ale ma wielki wpływ na czytelność. Teraz wyobraź sobie, że przygotowujesz się do analizy kodu źródłowego programu który ma kilkadziesiąt plików. Co zrobisz w sytuacji, gdy w każdym z nich stosowana jest inna konwencja? Albo dostaniesz oczopląsu, albo będziesz, łagodnie mówiąc, zdenerwowany ciągłym przestawianiem mózgu na czytanie inaczej sformatowanego tekstu.
Git i konflikty
Kto pracował z gitem, ten wie jak mocno wyprowadzają z równowagi konflikty. Konflikty występują najczęściej wtedy, gdy razem ze swoim współpracownikiem nieopatrznie zmodyfikujemy ten sam plik w tym samym miejscu. Git niestety nie jest jeszcze na tyle inteligentny aby domyślił się, która wersja pliku ma być tą ostateczną. Moja czy mojego współpracownika? A może obydwie mają w sobie ziarno prawdy?
Git oznacza miejsca, w których wystąpił konflikt specjalnymi znacznikami. Proces ręcznego usuwania konfliktów polega na zrobieniu porządku w plikach, w których wystąpił konflikt.
Podczas projektów, które robiliśmy na studiach rozwiązywanie konfliktów było najczęściej wykonywane ręcznie. Przez analizę pliku, wywalenie gitowych znaczników i samodzielne złączenie obydwu plików. Zajmowało to czasami naprawdę dużo czasu.
Analiza kodu
Prawidłowe działanie napisanego przez nas programu jest z pewnością kwintesencją pracy. Może się jednak okazać, że program wywala się przez jakiś głupi błąd, który popełniliśmy niechcących, a którego za żadne skarby świata nie możemy znaleźć. Istnieje także inny rodzaj kłopotów, który może nie powoduje crashu aplikacji, ale stwarza np.: potencjalne luki bezpieczeństwa. Tych błędów możemy nie zauważyć.
Konkludując powyższe rozważania
Wszystkie powyższe problemy w dużej mierze rozwiązuje odpowiednio skonfigurowane i wyposażone w rożne pluginy IDE. Oszczędza nam to naprawdę masę czasu, który możemy wykorzystać w bardziej pożyteczny sposób.
Co dalej?
Narobiłem ci czytelniku smaczku, a w sumie nie podałem rozwiązania. No cóż, powiemy o tym w następnym artykule.
Następne artykuły będą poświęcone środowisku programistycznemu IntellJ IDEA. Z pierwszej części dowiesz się co nieco o skrótach klawiszowych, które warto znać. Dowiesz się, jakie pluginy warto zainstalować, a także jak optymalnie korzystać z IDE programując w języku Java.