 |
| Photo by meantux |
IDE są świetne. Uwielbiam środowiska, które pozwalają mi w jednym okienku robić wszystko, od designu po testy integracyjne i deployment (czyli zazwyczaj commit do repozytorium). Problem w tym, że nie zawsze mam możliwość pracy w takim środowisku, czyli w projekcie mamy odgórnie ustalone NIDE - Non-Integraied Development Environment.
Uroki NIDE wynikają zazwyczaj z pracy nad systemami wbudowanymi. W moim obecnym projekcie mamy następujące feature'y:
- Brak odgórnie ustalonego edytora kodu i setki tysięcy (miliony?) linii kodu do ogarnięcia
- Dość rozbudowany skrypt konfigurujący linię komend, w której możemy kompilować i przeprowadzać statyczną analizę kodu
- Niezbyt popularny build toolchain i strukturę projektu opartą o coś na kształ makefile'ów
- Testy modułowe odpalamy na emulatorze uruchamiany z Visual Studio
- Za samo odpalenie testów odpowiedzialny jest program Rational Test Real-Time
- Żeby przetestować kod na działającym systemie musimy go wrzucić na sprzęt docelowy np. przez Visual Studio
- Informacje ze sprzętu trafiają do nas przez port COM, więc potrzebujemy jakiegoś programu do zbierania i przeglądania logów z portu szeregowego.
- Repozytorium kodu zamknięte szczelnie jak radziecki słoik i obsługiwane przez klienta napisanego w Javie.
Punkty od 2. do 8. są poza jurysdykcją programisty - takie są wymagania, tak musimy pracować. Okej, z tym się jestem w stanie pogodzić, skoro mogę wybrać edytor! Czego bym wymagał od edytora? Bez szczególnej kolejności:
- Możliwości skakania pomiędzy plikami, w szczególności do definicji funkcji/zmiennych... i oczywiście możliwość automatycznego szukania tych definicji.
- Program ma być darmowy. To się nie wydaje takie oczywiste, ale przede wszystkim zależy mi na społeczności. Wokół zamkniętych programów rzadko organizuje się grupa zapaleńców, a kiedy napotykam na jakiś problem i próbuję googlać za rozwiązaniem, to słyszę świerszcze.
- Szybkości. Dużo czasu mi schodzi na obsługę całej reszty NIDE, nie chciał bym dodatkowo walczyć z narzędziem, w którym realizuję sedno mojej pracy.
- Możliwie dobrej integracji z build toolchainem. Większość osób w projekcie skacze pomiędzy oknami edytora i linii komend: Zmiana w kodzie, [Switch!] kompilacja, sprawdzenie ewentualnych błędów, [Switch! i to kilkukrotnie] lokalizacja w edytorze, poprawki, [Switch!] kompilacja. Przy dwóch monitorach da się z tym żyć, ale... mi szkoda życia.
- Niezawodności. Nie wyobrażam sobie, żebym stracił choćby pół godziny pracy w wyniku jakiegoś tyci problemiku.
- Rozszerzalności. Jeżeli edytor nie ma czegoś, czego będę potrzebował, to chcę móc to sobie dorobić; łatwo i przyjemnie.
Uff... sporo się zrobiło tych wymagań. W następnej części pokażę, jak tym wymaganiom sprostał uwielbiany przez niektórych Eclipse. Narzekaniom nie będzie końca. Oczywiście żartuję... ale czy na pewno?
