Stając się lepszym narzędziem do naprawy błędów

Uwielbiam być programistą. Tam powiedziałem. Jednak powiedziawszy to, ostatnio zdałem sobie sprawę, że naprawdę nie mogę znieść naprawiania błędów. W ogóle.

W rzeczywistości, gdy coś rozwijam, moja wydajność jest niezwykle wysoka. Nawet pisząc testy jednostkowe i przeprowadzając autotesty mojego rozwoju, ogólnie jestem naprawdę produktywny. Mogę dobrze się skupić i mogę wykonać zadania.

Jednak gdy nadchodzi czas kontroli jakości i pracuję nad naprawą błędów, moja inspiracja przybiera na sile. Muszę zmusić się do dość ekstremalnych środków (wiesz, wysoka BPM, nadmierna ilość kofeiny itp.), Aby cokolwiek zrobić. Moja praca zwykle polega na wkraczaniu w istniejący ogromny projekt i dodawaniu nowych funkcji lub naprawianiu błędów, więc nie mogę dokładnie powiedzieć mojemu pracodawcy, że potrzebuję kilku tygodni na napisanie testów jednostkowych dla całego ich kodu :) Ponadto technologia serwera, której często używamy, jest bardzo przeszkodą zarówno dla testów jednostkowych, jak i integracyjnych, ponieważ ma sporo problemów z modułem ładującym klasy Java. Nie jestem całkowicie przeciwny naprawianiu błędów, czasem może być fajnie, ale wcale nie jest fajnie gdy musisz wprowadzić drobne zmiany i odczekać 30 sekund do 3 minut, aby zobaczyć, czy zadziałały, czy nie (ze względu na sposób działania systemu).

Jak mogę poprawić swoją wydajność i motywację podczas usuwania błędów? Czy to coś, z czym ma do czynienia większość programistów?

wcale nie jest fajnie, gdy trzeba dokonać drobnych zmian i odczekać 30 sekund do 3 minut, aby zobaczyć, czy zadziałały, czy nie

To jest prawdziwy problem tutaj. Czujesz się bezproduktywny, kiedy musisz tak długo czekać na informację zwrotną, znam to uczucie. Być może uda się sfałszować więcej usług i stworzyć lepsze narzędzia testowe, aby uzyskać natychmiastową informację zwrotną.

Testowanie jednostkowe starszego kodu jest drogie lub może wymagać niebezpiecznych refaktoryzacji. Jednak tworzenie lepszych urządzeń testowych może pozwolić na ręczne przetestowanie w ciągu kilku sekund w porównaniu do minut i możesz uzyskać prawie taką samą wydajność jak praca z nowym kodem testowanym jednostkowo.

Oczekiwanie na opinie jest nudne i demotywujące, a nie samo naprawianie błędów.

Naprawianie błędów to niezwykle ważna umiejętność, której powinieneś się nauczyć. Czytałem gdzieś, że zwykle 80% czasu zajmuje naprawianie 20% problemów w aplikacji.

Wierzę w uczenie się na błędach, a naprawianie błędów jest okazją do uczenia się na błędach innych . Możesz wziąć to za naukę i pomoże ci być lepszym programistą w przyszłości. Taka była motywacja, kiedy zacząłem naprawiać wiele błędów i iść naprzód, aby ponownie przefakturować kod .

Osobiście uważam za pomocne przestać myśleć o błędach jako o „małych rzeczach”, ale raczej o dużych showstopperach, które są tak samo ważne jak ogromne funkcje, mimo że po prostu wymagają zmiany kilku linii kodu po godzinach debugowania. W ten sposób spędzenie całego dnia na zabiciu 3 wpisów śledzenia błędów jest o wiele mniej depresyjne (podejście zależy nieco od twojej osobistej zdolności do przekonania się, aby w to uwierzyć :-).

Być może pomaga to uczynić grę, na przykład razem ze współpracownikami ( kto naprawia najwięcej błędów dziennie? Lub, co gorsza, kto wykonał najmniejszą liczbę odbudowań dziennie? )

Byłem w twoich butach. Twórz automatyczne testy, kiedy i gdzie możesz. To nie musi być wszystko naraz. Gdy znajdziesz błąd, poświęć chwilę, aby spróbować zaprogramować przypadek testowy. Jeśli nie możesz zaprogramować przypadku testowego, napisz gdzieś krótką notkę o tym, jak ręcznie go przetestować, np. Kliknij tutaj, wpisz to itp. I umieść w jakiejś bazie wiedzy.

Debugowanie może być bardzo męczące, szczególnie w przypadku skomplikowanego kodu, którego nie napisałeś. Wymyśl cel „Napraw błąd 13533 do piątku”. Następnie ustaw nagrodę, jeśli osiągniesz cel: „Weź piwo z moimi kolegami w piątek wieczorem”. Pomoże to uczynić go bardziej satysfakcjonującym.

Poza tym czasami praca jest po prostu… pracą.

W tego typu sytuacjach potrzebujesz kreatywnego wyzwania. Zwykle pisze kod, ale tutaj nie jest.

Ale nie wszystko stracone. Pracuj nad rozwiązaniem swoich meta-problemów i włóż w to swoją energię. Dlaczego otrzymanie opinii zajmuje od 30 sekund do 3 minut? Jak możesz skrócić ten czas? (Być może możesz napisać skrypt lub narzędzie, którego nie zameldujesz, co pomoże ci to zrobić). To twoja nowa domena problemowa - twoje nowe wyzwanie twórcze.

Osobiście, za każdym razem, gdy jestem w fazie usuwania defektów, identyfikuję moje największe bariery, aby to zrobić szybko i bezboleśnie, i automatyzuję to, co muszę zautomatyzować, aby usunąć te bariery. To często skutkuje zwiększoną produktywnością i dodatkami do mojego osobistego portfolio do uruchomienia.

Krótko mówiąc, powiedziałbym „zawsze się rozwijaj”. :)

Czy masz problem z debugowaniem lub naprawą błędu? Jeśli możesz debugować wystarczająco, aby wyodrębnić składnik powodujący problem, spójrz na to jako nowe zadanie programistyczne.

1. Napisz kilka testów jednostkowych tylko dla fragmentu kodu, który się psuje. Upewnij się, że masz testy sprawdzające wszystkie pożądane funkcje, a niektóre z nich szczególnie izolują zachowanie błędne.
2. Napisz nowy kod, który przejdzie wszystkie właśnie napisane testy.
3. Zastąp stary kod nowym.
4. Przeprowadź kilka testów integracyjnych. W tym miejscu uruchomisz się na trzy minuty ponownego uruchamiania serwera, ale należy go zminimalizować, jeśli dobrze wykonałeś kroki 1-3.
5. Voila!

Może powinieneś spojrzeć na artykuł Brian Hayes „ Debugging Myself” , który ukazał się w American Scientist w 1995 r. Możesz podjąć kroki (takie jak zwykłe stosowanie warunków Yoda ), aby zmniejszyć lub wyeliminować najbardziej znienawidzone rodzaje błędów, które produkujesz.

Uważam, że debugowanie to umiejętność inna niż programowanie, chociaż jest powiązana. W szczególności debugowanie programów wielowątkowych jest prawie całkowicie inne niż ich pisanie.

Jeśli tworzenie oprogramowania jest nudne, robisz to źle. Innymi słowy, nie jest to problem z tobą, ale problem z twoją platformą i procesem. Czy zastanawiałeś się nad szukaniem pozycji w dynamicznym języku (np. Python, Ruby, JavaScript), w którym nie musisz czekać na restart serwera?

Niestety jest to część pracy. Będziesz miał gówniane projekty i gównianych pracodawców (nie twierdzę, że tak jest tutaj, tylko ogólnie).

Państwo mogą pisać testy jednostkowe przed ich kodu. Zakradnij się, jak możesz. Gdy już będziesz mieć coś, co możesz pokazać szefom, możesz zmienić bieg.

Użyj narzędzi do debugowania, aby naprawić spowolnienie, użyj testów jednostkowych, aby przetestować nowy kod i użyj ich, aby naprawić istniejące problemy kodu, a także rozbić istniejący kod na mniejsze części.

Możesz uczynić to wyzwaniem i stać się bohaterem ulepszającym proces. A jeśli to nie zadziała, będziesz mieć dobre doświadczenie do podjęcia pracy u następnego pracodawcy.

Większość programistów ma do czynienia z osobistymi problemami w usuwaniu błędów w pewnym momencie swojej kariery.

Właściwe poczucie odległości między osobami ma zasadnicze znaczenie dla Twojej motywacji. Nie należy nadmiernie lub zbyt mało identyfikować się ze swoją pracą. Jeśli nadmiernie identyfikujesz się ze swoją pracą, mogą pojawić się problemy, takie jak te, które opisałeś: Możesz bardzo niechętnie naprawiać błędy, ponieważ jesteś w połowie obwiniany. Zdobądź dystans wewnętrzny i dowiedz się, jak możesz racjonalnie rozwiązać swój problem.

Jeśli chodzi o szczególne problemy na twojej platformie, istnieje kilka sposobów na złagodzenie długich czasów wdrażania i testowania (a z drugiej strony, twoje nie są szczególnie długie).

Po pierwsze, im dłuższy jest czas testu, tym bardziej niechętny jest kult kultu. Jeśli dokonasz zmiany, pomyśl o tym, dopóki nie będziesz pewny, że naprawi błąd . Oczywiście to, jak pewny jest, zależy od długości cyklu testowego. Ale jeśli twoje cykle testowe stają się dłuższe i nie można uniknąć długich testów, poświęć więcej czasu na myślenie, a będziesz nagradzany i bardziej szczęśliwy w debugowaniu, ponieważ jest on szybszy i daje satysfakcjonujący efekt dobrej chwili „Fiat Lux” „.

Po drugie, nastawienie bardziej na testy jednostkowe, a mniej na testy integracyjne. Usuń każdy punkt awarii z trudnej do debugowania platformy, którą możesz.

Naprawianie błędów może być „niesamowite” lub „nużące”. Mam kredyty do gry, które są całkowicie związane z naprawieniem jednego błędu - błędu awarii, którego nikt inny nie mógł naprawić. Ale codzienne pielęgnowanie Bugzilli jest przytłaczające. Drobne błędy są uciążliwe. Poważne błędy są godne.

Oto realizacja: sam fakt, że masz ogromną listę drobnych błędów, jest jednym z głównych błędów. To po prostu nie błąd kodu. Jest to błąd procesu lub zarządzania.

Znajdź ten błąd i napraw go.

Jedną z rzeczy, które znalazłem wśród kolegów i autorytetów, którzy są dobrymi „debuggerami / narzędziami naprawiającymi błędy / rozwiązującymi problemy”, jest to, że zazwyczaj lubią rozwiązywać zagadki. Może to oznaczać krzyżówki, gry liczbowe (takie jak Sudoku) i logiczne itp.

Tak więc jednym ze sposobów, w jaki możesz stać się lepszym narzędziem do naprawy błędów, byłoby poświęcenie czasu na pracę nad rozwiązywaniem problemów lub umiejętności rozwiązywania zagadek.

Oto link do Wikipedii, który może być dobrym punktem wyjścia do rzeczy, które pomogą Ci lepiej rozwiązać problem.

Pamiętaj, że niektórzy ludzie są po prostu lepsi w rozwiązywaniu problemów lub po prostu lubią to bardziej. Niektórym się to w ogóle nie podoba, co utrudnia zmuszenie się do zrobienia - ale nie popełnijcie błędu - jeśli zmusicie się do nauki rozwiązywania łamigłówek, łatwiej będzie w przyszłości naprawić błędy .

Naprawianie błędów jest zazwyczaj uciążliwe, ponieważ może sprawiać, że robaki zajmują cały Twój czas i nie pozwalają na zabawę. Rzeczywistość jest jednak taka, że ​​naprawianie błędów jest bardzo dużą częścią naszych działań i zaczyna się już od napisania pierwszego wiersza kodu i uruchomienia kompilatora. Kiedy wydajesz kod po raz pierwszy, prawdopodobnie spędziłeś już godziny na naprawianiu błędów, ale nie wydaje się to w ten sposób, ponieważ naprawiałeś je w ramach procesu wdrażania funkcji. Realistycznie rzecz biorąc, bez względu na to, jak dobry jesteś programista, błędy wkradną się do twojego systemu.

Jak to sprawia, że ​​jest fajnie? Cóż, tak naprawdę nie potrafię odpowiedzieć na to pytanie, ponieważ naprawdę nie mogę sobie wyobrazić, co płynie po twojej indywidualnej łodzi. Dla mnie jestem trochę ćpunem narzędzi, więc odpowiedzią jest posiadanie bardzo niezawodnego łańcucha narzędzi i elastycznego procesu programowania, który przyczynia się do tego, że naprawianie błędów staje się mniej uciążliwe, a po prostu problem do rozwiązania szybko. Obecnie rozwijam się głównie w języku C # i zawsze szukam narzędzi, które wyeliminują żmudne marnowanie czasu na pisanie oprogramowania. Używam testowego podejścia do programowania opartego na bardzo dobrym API BDD o nazwie StoryQ . Korzystam z Resharper do automatyzacji dużej części mojego refaktoryzacji, a StyleCop pozwala zachować kontrolę nad takimi rzeczami, jak styl kodowania. Moim ostatnim dodatkiem do łańcucha narzędzi było włączenieNCrunch, który uruchamia moje testy nieprzerwanie i jednocześnie w tle podczas pisania kodu, i tak naprawdę to NCrunch okazał się być zmieniaczem gier.

Połączenie wszystkich tych narzędzi sprawiło, że moja wydajność ostatnio spadła, ponieważ tracę bardzo mało czasu, czekając na kompilację lub wykonanie. Otrzymuję natychmiastową informację wizualną w ramach mojego IDE, aby poinformować mnie, że mam problemy do rozwiązania, i układam mój kod testowy w taki sposób, aby w kilku liniach kodu mógł dokładnie wskazać dokładne miejsce, w którym nie tylko pojawia się awaria, ale tam, gdzie występuje przyczyna awarii ze względu na urocze pełne raportowanie, które otrzymuję z StoryQco mówi mi dokładnie, które części mojego testu przechodzą, a które nie, i gdzie w kodzie są awarie. Po usunięciu wszystkich marnotrawstw z czasu programowania, spędzam bardzo mało czasu na aktywnym debugowaniu, a więcej na rozwiązywaniu problemów oraz pisaniu testów i kodu. Problemy z wysoką rotacją sprawiają, że jestem zajęty i wnoszę dużą różnorodność do moich zadań. Dało mi również dużo czasu na zajęcie się innymi obszarami zainteresowań w ciągu dnia pracy, dzięki czemu mogę wprowadzać nowe i innowacyjne pomysły do ​​naszej linii produktów i procesów.