Dlaczego wolę Ridera od Visual Studio?

Dlaczego wolę Ridera od Visual Studio? Zdjęcie tytułowe

Dziś biorę na tapet dwa najpopularniejsze IDE dla .NET developerów – Visual Studio i JetBrains Rider. Czym się różnią? I dlaczego używam już (prawie) tylko Ridera? 😉

Szybkość działania

Głównym i wystarczającym powodem do przesiadki na Ridera jest szybkość działania. Jeśli korzystasz z Visual Studio z ReSharperem, różnica będzie ogromna. Rider dostarcza te same funkcjonalności co wtyczka JetBrainsa do VS i wiele więcej, a działa przy tym X razy szybciej. Nie znam dokładnych statystyk, ale gwarantuję, że momentalnie poczujesz ogromną różnicę.

Śmiem twierdzić, że Visual Studio nawet bez ReSharpera działa wolniej niż Rider. Polecam po prostu spróbować. Ja od ponad roku nie wracam już do VS (prawie – ale o tym w dalszej części).

Wyszukiwanie

Wyszukiwanie w Riderze to bajka. Pierwszym przydatnym skrótem klawiszowym jest Ctrl+T, który otwiera okno wyszukiwania:

Okno wyszukiwania w JetBrains Rider

Można osobno szukać klas, plików czy symboli (np. pól w klasach). IDE zapamiętuje też ostatnio wyszukiwane elementy i prezentuje je na górze listy. Super to działa.

Kolejnym trybem, którego bardzo często używam, jest wyszukiwanie tekstowe w plikach (Crtl+Shift+F):

Wyszukiwanie w plikach

Jest to bardzo przydatne, jeśli potrzebujemy znaleźć w całej solucji wybrany tekst, np. tłumaczenie albo treść wiadomości z błędem, który widnieje w zgłoszeniu od klienta. W dolnej części okna dostajemy od razu podgląd odpowiedniego fragmentu pliku.

Wyszukiwanie tekstowe można zawęzić do solucji, projektu, katalogu albo scope.

Zawsze brakowało mi takiego „dynamicznego” wyszukiwania tekstów w Visual Studio. ReSharper trochę pomagał funkcją search everywhere, ale nie działało to tak dobrze i naturalnie jak w konkurencyjnym IDE od JetBrains.

Synchronizacja ustawień

Wiele ustawień IDE, w tym wielkość czcionki, ustawienia edytora i wtyczki, można synchronizować z kontem JetBrains:

Synchronizacja ustawień w Riderze

Przez długi czas nie było takiej opcji w Visual Studio, chociaż czytam, że ponoć też już jest. Nie wiem jednak jak działa w praktyce 😉

Tooling do testów

Bardzo lubię tooling do testów w Riderze. Jeśli aktywujemy plugin dotCover, dostajemy wiele ciekawych dodatków, między innymi continuous testing. Pozwala to na uruchomienie wybranego zestawu testów w momencie zapisu pliku po zmianach w kodzie albo po każdym lokalnym buildzie. Bardzo przydatne gdy stosujemy TDD albo refactorujemy kod.

Bardzo spoko działa też code coverage:

Code coverage w JetBrains Rider

W Visual Studio oczywiście również da się to osiągnąć korzystając z rozszerzenia dotCover, ale tutaj jest to bardziej naturalne. No i oczywiście działa szybciej 😉

Konfiguracje buildowania

Super ficzerem Ridera jest też możliwość szerokiej konfiguracji customowych buildów i uruchamiania. Jest to przydatne, gdy pracujesz ze złożonym systemem i po buildzie chcesz np. odpalić jakiś skrypt, potem jakąś aplikację, później kolejny skrypt itd.

Build buduje się na zasadzie kroków, które mogą być w zasadzie czymkolwiek:

Run/Build configurations w JetBrains Rider

Po całym procesie Rider może też uruchomić przeglądarkę internetową na wskazanym URLu, nawet z podpiętym debuggerem JS 😉

Problemy Ridera

Ale czy Rider jest taki idealny? No, prawie 😉

Jedyna rzecz, którą nadal robię w Visual Studio, to przebudowywanie T4MVC w projekcie ASP.NET MVC 5. Tego IDE od JetBrains jeszcze nie ogarnia.

Poza tym, dla nowego użytkownika Ridera debugowanie może wydawać się nieintuicyjne. Mnie i kolegów z zespołu od początku denerwowało, że Rider często z automatu „wchodził” w trybie debugowania w kod zewnętrznych bibliotek.

Drugi problem był z wyjątkami. Dostajesz zgłoszenie błędu. W scenariuszu A leci wyjątek X. Odpalasz więc apkę w trybie Debug, powtarzasz scenariusz A i oczekujesz, że IDE „zatrzyma” się w miejscu rzucenia wyjątku X. A tu niespodzianka – Rider stawia breakpoint gdzieś w bibliotekach .NETa 🤯 Albo w innym, zupełnie „z dupy” miejscu.

Żeby uniknąć tych problemów, polecam skonfigurowanie Ridera w następujący sposób:

Zalecane opcje debugowania w Riderze

Czyli wyłączamy opcję „Enable external source debug” i włączamy „Break on user-unhandled exceptions (.NET/.NET Core only)”.

Jeśli w Twojej sytuacji debugger nadal nie zatrzymuje się poprawnie na rzucanych wyjątkach, możesz pomyśleć o dorzuceniu wszystkich możliwych wyjątków w oknie Run -> Stop On Exception:

Lista wyjątków, na których na zatrzymywać się debugger w Riderze

Efektem będzie zatrzymywanie się przez debugger w miejscu rzucenia każdego z wybranych wyjątków. Na początku mogą to być wyjątki frameworka czy inne, co może Cię wkurzać. Na szczęście w momencie zatrzymania debuggera na takim wyjątku jest możliwość zignorowania go, co usunie go z powyższej listy. Po jakimś czasie działania w ten sposób na liście wyjątków pozostaną już tylko te, które Cię interesują 😉

Podsumowanie

Jeszcze raz na koniec – dla mnie Rider jest genialnym IDE i absolutnie gniecie Visual Studio. Nawet jeśli Twój pracodawca nie finansuje licencji na Ridera, cena $149 za rok (za pakiet dotUltimate) nie wydaje się bardzo wygórowana. Tym bardziej że można to wrzucić w koszty prowadzenia firmy 😉

A jak jest u Ciebie? Rider czy VS? 🙂

Programista, cyfrowy nomada od 2019 r. Autor bloga programistawpodrozy.pl
Subscribe
Powiadom o
guest
8 komentarzy
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Adam
Adam
16 dni temu

Używam od roku i nie planuję powrotu do VS. Jak ktoś nie chce płacić można spróbować EAP jetbrains.com/rider/nextversion/

Piotr
Piotr
16 dni temu

Czy Rider daje już możliwość odpinania okien i przenoszenia na inny monitor, jak VS czy dalej można mieć tylko jedno (główne) okno?

Leszek
Leszek
7 dni temu

Mozna prosic o artykul z twojego TDD z GildedRose?

Grzegorz
Grzegorz
3 dni temu

Dodałbym przede wszystkim, że Rider jest 64 bitowy a VS wciąż 32. To jest duży plus na korzyść Ridera.