Wywiad z programistą. Najczęstsze błędy i problemy w kodowaniu

Share on facebook
Share on twitter
Share on linkedin
Czas czytania: < 1 min.

Wielu z nas obiła się o uszy teoria 10 000 godzin. Zakłada ona, że aby osiągnąć mistrzostwo – albo pierwszy, najniższy stopień mistrzostwa, czymkolwiek on jest – trzeba nad czymś spędzić przynajmniej tyle czasu. Oznaczano ją już jako mit, oznaczano jako prawdę objawioną. Czy faktycznie potrzeba aż takiego nakładu? Nie wiemy, ale ryzyko błędów dobrze dostrzec na początku. Rozmawiam z naszym programistą Marcinem Lesińskim.

Czytelnicy bloga Botland znają Marcina m.in. z artykułów o druku 3D, projektów inteligentnego domu na bazie Raspberry czy tworzenia własnego oświetlenia ambient dla telewizorów.

Oskar Pacelt

Czego z pewnością musi wystrzegać się początkujący programista?

Marcin Lesiński, specjalista ds. technicznych w Botland

Myślę, że zamiast mówić o tym, czego musi się wystrzegać początkujący programista, należy raczej zająć się tym, na co powinien zwracać uwagę. Podstawą udanego kodowania jest dbałość o szczegóły oraz umiejętność myślenia przyczynowo-skutkowego. To, po dodaniu szczypty kreatywności, daje nam przepis na programistę (śmieje się). Podstawowe atuty dobrego kodu to... najpierw czytelność. Musimy mieć pewność, że jakakolwiek zmiana w programie nie zmusi nas do szukania fragmentu odpowiedzialnego za daną funkcję nawet przez kilka godzin. Starajmy się też być konsekwentni w używaniu odpowiednio usystematyzowanych nazw zmiennych.

Mówisz o dbałości o szczegóły. Rozumiem, że wyjątkowo częste są błędy z nieuwagi.

Tak, nieuwaga, pośpiech i próba nadmiernej interpretacji sensu danego programu sprawia, że łatwo o pomyłkę lub co gorsza powolny kod. Często elementem składowym kodu który sprawia największe problemy są tabulatory w kodzie, mówimy tutaj o języku Python, nie rzadziej zdarza się zapomnieć średnika, czy źle definiować daną funkcję.

"Powolny kod"?

Każdy który wykonuje się wolno, a mógłby szybciej. Przez zbędnie dużą objętość generuje obliczenia i zajmuje procesor. Przekombinowany.

Wspomniałeś o języku Python, który uchodzi za niewybaczający najmniejszych pomyłek. Wiąże się to pewnie z doborem odpowiedniego języka dla siebie.

Tak, masz rację, jednak nie bójmy się takich języków. Większość z nas zaczynała od tworzenia prostych stron w HTML, a kończyła kilka lat później pisząc oprogramowania zakrawające o obsługę sztucznej inteligencji czy uczenia maszynowego, ale to tak bardziej o mnie. Uważam jednak, że każdy język programowania jest dobry - warto zaczynać od prostych przykładów i zastanowić się, do czego użyjemy danego języka. Patrząc na przykład stworzonego na naszym blogu projektu systemu dla inteligentnego domu możemy pomyśleć, że jedynym rozwiązaniem będzie Python, ale dlaczego? Bo jest popularny wśród użytkowników Raspberry Pi? Bzdura. To zbędne utrudnienie, korzystamy tutaj z PHP i odwołań do bazy danych w MySQL, i stworzyliśmy tym sposobem dużo bardziej składny kod niż w przypadku tworzenia każdej kondygnacji kodu w osobnym pliku. Wracając do samych podstaw programowania najlepiej zacząć od nauki podstaw języka angielskiego, oczywiście na szczeblu technicznym. Wybór samego języka to kwestia indywidualna, nie chciałbym tutaj doradzać.

Konwencja dzisiejszej rozmowy to poszukiwanie pułapek. Co z kodem nieskładnym? Czym grozi zabałaganiony lub zbyt skomplikowany kod w praktyce?

O ile wiemy, że z kodu będziemy korzystać tylko my i będzie on działał najwyżej kilka dni, to tak naprawdę niczym. Jednak zwracajmy uwagę na dobre nawyki i od początku wyjaśnijmy, na czym polega ta bolączka. Zbyt skomplikowany kod to niesamowicie częsty problem początkujących, często funkcja która może być zawarta w kilku linijkach kodu jest rozwijana do kilkudziesięciu lub nawet kilkuset linijek. Nieprzejrzysty kod może być jak język małego dziecka, który rozumieją tylko rodzice. A co, jeżeli ktoś usiądzie do tego kodu ktoś inny?

Dlaczego? A raczej: skąd to się bierze?

Wynika to najczęściej z niewiedzy i nieznajomości funkcji danego języka lub wątpliwych prób ulepszenia kodu. Jednak prawda jest taka, że im szerzej próbujemy opisać coś w kodzie, tym gorzej to wychodzi. Dodatkowo pamiętajmy o tym, że im więcej kodu jest do przetworzenia, tym więcej czasu zajmie to procesorowi. Oczywiście pisząc program, który będzie sterował światłem w domu, nie będzie to zauważalne. Natomiast przy obsłudze bazy danych, w której jest kilka tysięcy rekordów, program zostanie mocno spowolniony, tam zauważymy to na pewno. Jeśli mówimy o bałaganie w kodzie, to powód, dla którego warto regularnie “sprzątać kod”, jest tylko jeden - łatwiej będzie nam cokolwiek w nim znaleźć i w razie potrzeby usunąć lub poprawić.

Z Twoich słów wynika, że wielu stawiających w środowisku pierwsze kroki chce na nowo wynajdować koło. Biorą się za zadania naprawdę trudne. Co sądzisz na przykład o zabieraniu się za pisanie własnej biblioteki?

Zuchwałe rzemiosło. Myślę, że to błąd, strata czasu i zupełnie niepotrzebne działanie, o ile nie tworzymy komercyjnego projektu, który ma być idealnie dopasowany pod konkretne potrzeby. Żyjemy w dobie Internetu. Trudno znaleźć problem, który nie był już gdzieś opisany. Oczywiście mówię o projektach tworzonych przez początkujących, na wyższych poziomach bywa ciężej.

Okej, rozróżnijmy jeszcze na prostym przykładzie praktycznym co robi biblioteka, a co kod.

Tak, warto rozróżnić czym jest kod, a czym biblioteka, której w nim używamy. Biblioteka jest również kodem, jednak napisanym w celu ułatwienia konkretnych czynności, spróbujmy podać przykład wyświetlania danych na jakimkolwiek wyświetlaczu, może być to nawet proste LCD w wersji alfanumerycznej, aby wyświetlić tu jakikolwiek piksel musimy znaleźć jego adres i sposób wywołania konkretnego stanu. Biblioteka robi to za nas, wystarczy, że w kodzie wywołamy jej funkcję i wpiszemy znaki alfanumeryczne, a biblioteka zajmie się transkrypcją tablicy znaków na bity wysyłane do wyświetlacza.

Zapomnieć średnika albo popełnić literówkę w nazwie zmiennej, to jedna sprawa. Rozumiem, że z pełni zoptymalizowanego kodu tworzy się wówczas wypluwana lista debuggera. Wróćmy jednak jeszcze do tematu porządku w kodzie. Możesz podać jakiś przykład dobrej i złej praktyki w tym wypadku? Choćby na szczeblu podstawowym.

Pewnie. Najłatwiejszym sposobem na utrzymanie porządku w kodzie jest podział na sekcje. Oczywiście kod często możemy napisać w jednej linii, jednak wtedy szukanie jakiegokolwiek fragmentu zajmie nam lata. Lepiej dzielić wszystko na sekcje odpowiedzialne za dane funkcjonalności kodu, najłatwiej za pomocą tabulatorów i klawisza Enter.

Idąc za naszym tematem - co oceniłbyś jako największy horror programisty? Mile widziane Twoje własne doświadczenia.

Moim zdaniem największym problemem jest właśnie szukanie błędów w nieuporządkowanym kodzie, szczególnie gdy kod tworzony jest przez cały zespół. Często znalezienie jednego błędu sprawia, że musimy wertować i poprawiać inne fragmenty programu. Dlatego tak chętnie sugeruję dbanie o porządek i standaryzację wszystkiego co robimy. Kiedyś na pewno wróci to do nas z podwójną siłą - i praktyki dobre, i praktyki złe.

Podsumujmy, Marcinie: co zalecasz młodszym w programowaniu koleżankom i kolegom?

Pewnie. Pierwszą radą jest to, abyście nie bali się pytać. Nikt nie wie wszystkiego, a najgorsze, co może być, to siedzenie z rozłożonymi rękami. Oczywiście nie zachęcam tutaj do wyręczania się innymi, ale do wyczuwania takich momentów blokady. Kolejna rada dotyczy budowania założeń co do konkretnego projektu. Program to lista poleceń dla procesora i o tym musimy pamiętać. Warto przed napisaniem programu wziąć kartkę i długopis, albo odpalić notepada, i wypisać listę założeń dla danego programu. Łatwiej będzie rozpoznać, co będzie czynnikiem wywoławczym dla danej funkcji. Pamiętajmy również o dogłębnym testowaniu naszego softu tak, aby nawet w zupełnie innych warunkach program działał tak samo. Program ma działać wszędzie, nie tylko na komputerze, na którym jest pisany. Nie możemy bać się wyzwań, są one podstawą do naszego rozwoju i tego musimy się trzymać.

Niezależnie od poziomu zaawansowania i narzędzia życzymy Wam powodzenia w kodowaniu. Warto najpierw zjeść zęby na poprawkach, aby później umiejętnie zjadać niepotrzebne fragmenty poleceń. Nie ma kodu bez głodu!

Książki dla programistów

Podziel się:

Share on facebook
Share on linkedin
Share on twitter
Oskar Pacelt

Oskar Pacelt

Wierzy, że udany tekst jest jak list wysłany w przyszłość. W życiu najbardziej interesuje go prawda, pozostałych zainteresowań zliczyć nie sposób. Kocha pływać. Zajmuje się korektą tekstów (czyt. uprzykrzaniem życia współpracownikom), tłumaczeniami i ciekawostkami ze świata technologii.
Oskar Pacelt

Oskar Pacelt

Wierzy, że udany tekst jest jak list wysłany w przyszłość. W życiu najbardziej interesuje go prawda, pozostałych zainteresowań zliczyć nie sposób. Kocha pływać. Zajmuje się korektą tekstów (czyt. uprzykrzaniem życia współpracownikom), tłumaczeniami i ciekawostkami ze świata technologii.

Zobacz więcej:

Dodaj komentarz