Zawartość
- Kod debugowania: jak to zrobić
- Battling Bugs
- Dlaczego robaki unikają przechwytywania
- Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
- Filozofia debugowania
Źródło: Abscent84 / iStockphoto
Na wynos:
Przemyślani liderzy wymyślili bardziej płynną strukturę wydań oprogramowania w celu połączenia środowisk programistycznych i produkcyjnych, ale programowanie komputerowe wciąż ma w sobie element magii.
Każdy, kto pracował nad kodowaniem nawet najbardziej podstawowych projektów, wie, że proces ten wymaga sporo cierpliwości. Liczne pułapki związane z próbami pisania kodu od zera to piosenka i taniec wszystkich sposobów, w jakie ludzki programista lub programista może popełnić błąd. Jest to długa lista, która obejmuje wszystko, od błędów składniowych, które zwykle zostaną złapane przez kompilator, po głębsze błędy „na poziomie wzroku”, które wymagają bardziej inteligentnego przeglądu. W tym celu szkoły i ośrodki szkoleniowe uczą informatyków, jak „debugować” program. Interesujące jest jednak to, że każda osoba rozwija własną, unikalną odpowiedź na to wyzwanie. W rzeczywistości może to być obszar, w którym wymagany jest więcej niż osobisty wgląd. (Przeczytaj o najważniejszych elementach programowania w The Pioneers of Computer Programming.)
Kod debugowania: jak to zrobić
W niektórych przypadkach specjaliści informatyki mogą wykorzystywać zasoby ze studiów deweloperskich lub środowisk programistycznych do izolowania błędów w programie. Gdy tego rodzaju obsługa błędów lub systemy nie są dostępne lub przydatne, debugowanie wymaga przejścia kodu po linii. Wiele środowisk programistycznych, takich jak Microsoft Visual Basic Studio, ma funkcje, które umożliwiają wyraźne, wizualne „przechodzenie” krok po kroku przez kod.
Przechodzenie przez kod pomaga na dwa główne sposoby: po pierwsze, programiści mogą zobaczyć, co się dzieje, gdy komputer odczytuje kod, i gdzie koncentruje się na funkcjach rekurencyjnych i innych interakcjach kodu. Po drugie, programiści często widzą wartości różnych zmiennych, używając poleceń najechanych myszką lub innych części interfejsu. Znajomość wartości w zmiennych jest kluczowym sposobem na zrozumienie, co robi komputer z kodem, który został mu przekazany.
Battling Bugs
Proces opisany powyżej może wydawać się prosty, ale faktyczne wyzwanie debugowania może być o wiele bardziej skomplikowane. Doskonały przykład tego procesu można znaleźć w thrillerze technologicznym trafnie zatytułowanym „Bug” Ellen Ullman, byłej programistki i informatyka, której proza świeci literacko. Mimo że książka jest fikcją, wiele mówi o tym, co się dzieje, gdy programiści i komputery wchodzą w interakcje.
Pomijając wiele mrocznych szczegółów w książce, ułożenie dwóch osób Ullmana, testera i programisty, pokazuje niektóre z głównych wyzwań, przed którymi stanęli technicy kariery we wcześniejszej erze tworzenia oprogramowania. Zasadniczo jej błąd, który nazywa „Jester”, wymknął się wszystkim w firmie produkującej oprogramowanie z lat 80. XX wieku, nadwerężając relacje z pracownikami, obniżając zaufanie inwestorów i ogólnie powodując zamieszanie. Tymczasem autor bardzo dużo zastanawia się nad tym, jak wpływają na nas komputery i dlaczego, jeśli chcemy zatriumfować nad ich osobliwościami, musimy „myśleć jak maszyna”. (Aby dowiedzieć się więcej o historii programowania, zobacz Programowanie komputerowe: od języka maszynowego do sztucznej inteligencji).
Dlaczego robaki unikają przechwytywania
Jednym z powodów, dla których błąd w książce Ullmana był tak trudny do rozwiązania, jest to, że pojawiał się tylko w dziwnych momentach. To wyzwanie naprawdę sprawdza się w wielu innych takich usterkach (pamiętaj tylko o rozległych próbach Toyoty po plotkach użytkowników o uciekającym Priusie). Załóżmy, że ktoś mówi ci, że masz błąd. Jeśli nie możesz sprawić, by komputer okazał się problemem, od czego w ogóle zaczynasz go naprawiać?
Przyczyną tej usterki, ujawnionej na końcu książki, jest kolejny świetny przykład złożoności pisania kodu na komputer osobisty w tamtych czasach - i być może nadal w naszym. Zasadniczo błąd został ukryty w małej, zagnieżdżonej funkcji, która po prostu zapewniała podstawową orientację w innych fragmentach kodu. Ponieważ zostało napisane przez zewnętrznego programistę, a także z powodu braku komunikacji między programistami, prawdziwe źródło problemu pozostało ukryte przez miesiące - prawdziwy świadectwo problemów może wynikać z niewłaściwie udokumentowanej pracy zespołowej.
Jeśli chodzi o błąd komputera, podstępny szczegół może wprowadzić chaos w uporządkowany w inny sposób system. Dobre umiejętności kodowania mogą więc czasem być bardziej sztuką niż nauką (Ullman nazywa to „szaleństwem”), przez co kodowanie jest z natury nieuporządkowanym biznesem.
Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
Nie możesz poprawić swoich umiejętności programistycznych, gdy nikt nie dba o jakość oprogramowania.
Filozofia debugowania
Programiści często muszą pracować z komputerami - nie ludźmi - aby osiągnąć wyniki. Ullman sugeruje, że kodery i testery są często najskuteczniejsze, gdy są w stanie odłożyć wszystkie niuanse ludzkiej myśli i rozebrać rozumowanie do podstawowych zastosowań logiki komputerowej. Oznacza to odłożenie na bok wielu rzeczy, z którymi wszyscy przychodzimy do pracy każdego dnia, aby uzyskać przejrzystość. Jest to jakość, która pozwala prosperować wielu najlepszym profesjonalistom z dziedziny informatyki, nawet w czasach, gdy dla większości projektów wprowadzono znacznie więcej ram.
Przemyślani liderzy wymyślili bardziej płynną strukturę wydań oprogramowania w celu połączenia środowisk programistycznych i produkcyjnych, ale programowanie komputerowe wciąż ma w sobie element magii. Oto dlaczego najlepsi programiści to coś więcej niż kodery strukturalne; mają instynkt rootowania i naprawiania błędów, które zagrażają funkcjonalności maszyn, na których coraz bardziej polegamy.