Informacje o nowych artykułach oraz akcjach edukacyjnych prosto na Twojej skrzynce e-mail!

Błędy popełniane w procesie tworzenia oprogramowania

Materiał powstał przy współpracy z marką Testspring.

Jeśli chcesz zostać dobrym programistą, Twoja edukacja będzie trwała do końca kariery zawodowej związanej z pracą przy tworzeniu kodu. Programowanie to jedna z tych profesji, gdzie nauka nie kończy się wraz z egzaminami na studiach i obroną pracy magisterskiej, inżynierskiej czy licencjackiej… tutaj wszyscy uczą się każdego dnia, a przynajmniej powinni, jeśli chcą osiągnąć coś więcej podczas swojej kariery. Pod piękną nazwą “inżynier oprogramowania” kryje się sporo wiedzy teoretycznej, a także praktycznej. Nie od dzisiaj wiadomo, że wszystkiego na kursach, studiach i innych webinarach po prostu się nie nauczymy. Tak naprawdę, większość umiejętności twardych zdobywamy, ucząc się na własnych błędach – jeśli oczywiście ktoś nam je wcześniej pokaże lub po prostu sami dojdziemy do wniosku, że coś zrobiliśmy źle.

W dzisiejszym materiale chciałbym Ci przybliżyć kilka błędów, jakie często popełniają młodzi, ale też nieco starsi programiści. Wielu można by uniknąć w bardzo prosty sposób, co z kolei znacząco poprawiłoby jakość kodu i uchroniło przed narastającym długiem technologicznym.

Nie wynajduj koła na nowo

Pierwsza rzecz, która jest trywialna, ale wydaje mi się, że wiele osób ciągle się na tym łapie. Nie odkrywamy koła na nowo. Posłużę się tutaj praktycznym przykładem. Mamy do porównania zawartość dwóch zmiennych typu String – zawierających ciągi znaków. W jaki sposób to zrobimy? Pierwsze, co przychodzi na myśl, to wykorzystanie operatora “==”:

Działa? W pewnym sensie tak. Cel został osiągnięty, idziemy dalej. Wszystko fajnie tylko co, jeśli zmienna a będzie nullem? No dobra, sprawdźmy sobie wcześniej, czy a i b nie są null’ami:

Działa? Oczywiście, że tak. Sęk w tym, że w tym momencie większości powinna zapalić się już czerwona lampka. Prosta rzecz, a takie długie wyrażenie? A co, jeśli zrobimy tak:

Hmm… nie działa!? No to trzeba dopisać kolejne warunki. Tak możemy się bawić w nieskończoność, aż w końcu komuś zabraknie cierpliwości. Rozwiązanie? Bardzo proste – wszędzie, gdzie się da, korzystaj z wbudowanych funkcji i dostępnych metod. Ktoś to wcześniej napisał, przetestował, sprawdził – nie wynajduj koła na nowo.

Code review to okazja do nauki

Wszystkie błędy w tym między innymi, ten opisany w poprzednim punkcie, powinny zostać wyłapane przy okazji code review. Tak zwanego przeglądu kodu. Powinny, ale nie zawsze są. Powody tego są różne, brakuje czasu, chęci, kompetencji i tak dalej. Dla młodszego programisty, a także tych z nieco większym doświadczeniem to najlepszy sposób na to, aby stać się jeszcze lepszymi developerami. Nauka na własnych błędach to najlepsza szkoła życia. Dobrze zorganizowane code review to nie tylko korzyść dla autora kodu, to przede wszystkim narzędzie dla zespołu, który na bieżąco orientuje się, co dzieje się w projekcie, a także minimalizuje powstawanie długu technologicznego. Zaniedbanie tego punktu może prowadzić do poważnych konsekwencji. Jak już do nich dojdzie, to choćby doba miała 48h, gwarantuję, że i tak braknie czasu, aby ugasić wybuchające jeden po drugim pożary. Nie chciałbym osobiście brać w czymś takim udziału.

Nie twórz zbyt dużych metod

Nie ma nic bardziej paskudnego niż wielkie metody, których zadaniem jest obsługa miliona pięciuset sto dziewięćset funkcjonalności w danej aplikacji. Utrzymywania takiego kodu nie życzyłbym nawet największemu wrogowi. Jakakolwiek zmiana, jak choćby dodanie prostej modyfikacji w postaci nowej ikony, będzie trwała tyle, że Twój project manager prędzej wyrzuci Cię z pracy za lenistwo, niż Ty zdążysz cokolwiek zrobić. Zawsze staraj się w miarę możliwości tworzyć zwięzły kod, który będzie można również wykorzystać w innych komponentach projektu.

Nie twórz zbyt dużych kontrolerów

Kontynuując myśl z poprzedniego punktu, to samo tyczy się zbyt dużych kontrolerów. Pisząc kod, warto stosować się do zasady SoC (separacji zagadnień). Jako programiści wczujmy się od czasu do czasu w rolę testesterów i postarajmy ułatwić im pracę. Przy okazji pomożemy również sobie. Kiedy nasz projekt rozrośnie się do nieco większych rozmiarów, znacznie łatwiej będzie się pracowało, gdy wszystko jest uporządkowane. Czasami tworzone aplikacje dochodzą do takich rozmiarów, że czas potrzebny na naprawę wykrytego buga przez zespół QA to 7 godzin szukania danego fragmentu w kodzie, 30 minut poprawiania i 30 minut testowania, czy poprawka zadziałała. Takie liczby robią wrażenie. I nie, nie są to randomowe dane, to samo życie…

Dobieraj wzorce projektowe “z głową”

Wzorce projektowe to bardzo fajny “wynalazek”. Warto je stosować, ale należy to robić w sposób przemyślany i zrozumiały. Pisząc aplikację mobilną, nie korzystajmy z klasycznej wersji MVC – bo jest znany i lubiany – ale pomyślmy przez chwilę. W tym konkretnym przykładzie wykorzystanie takiej architektury to strzał w stopę. Co z tego, że użyliśmy fajnego i popularnego wzorca architektonicznego, jeśli nasza aplikacja ma problemy z zarządzaniem danymi, a my sami ciągle “walczymy” z różnymi dziwnymi rzeczami? W tym przypadku pewnie znacznie lepszym rozwiązaniem byłoby wykorzystanie wzorca MVVM lub też nieco zmodyfikowanej wersji MVC. Dobieraj wzorce projektowe oraz architektoniczne w sposób przemyślany i zrozumiały. Dobrze podjęte decyzje ułatwią wiele rzeczy, a złe w skrajnych przypadkach mogą nawet spowodować upadek projektu.

Proste rozwiązania są najlepsze

Rada oczywista, ale warto o niej napisać. Nic nigdy nie komplikuj na siłę! Mając do wykonania proste zadanie, jak choćby zaimplementowanie funkcji obliczającej silnie z n, zrób to w sposób najprostszy, jaki się da. Przykładowo z użyciem rekurencji. Jeśli chcesz, aby Twój kod był “ładniejszy” i krótszy – oczywiście możesz to zrobić i zastosować w tym konkretnym przykładzie paradygmat programowania funkcyjnego, czyli wyrażenia lambda. Zanim to jednak zrobisz, zadaj sobie jedno ważne pytanie. Co Ci to da? Jeżeli odpowiedzią będzie coś w stylu “krótszy kod i szacunek na dzielni”, to odpuść. Zrób to najprościej, jak potrafisz. Co innego, jeśli ta sama konstrukcja zapisana przy wykorzystaniu lambd, będzie z różnych przyczyn działa znacznie szybciej niż rozwiązanie oparte o rekurencję czy pętlę iteracyjną. Podejmuj takie decyzje świadomie tak, aby w razie czego móc je potem uzasadnić i obronić podczas code review.

Pamiętaj o testach

Kiedy tworzysz kod, nietrudno o pomyłkę. Możesz źle zinterpretować wymagania klienta, niepoprawnie obsłużyć wprowadzane przez użytkownika dane czy też nieodpowiednio zarządzać pamięcią. Możliwości jest naprawdę sporo, skłaniałbym się nawet do tego, że jest to zbiór nieskończony. Jak temu zaradzić? Odpowiedzią na to pytanie jest jedno słowo — testy. Pamiętaj jednak, że nawet przy 100% pokryciu kodu nie mamy gwarancji wyeliminowania wszystkich bugów. Podchodząc do tematyki testowania oprogramowania, warto posłużyć się tutaj odpowiednimi technikami i metodologiami. Wszystkie tego rodzaju działania, powinny być wykonane w sposób ustrukturyzowany i sformalizowany. Jeśli masz jakieś wątpliwości czy tak jest, zawsze możesz skorzystać z darmowego audytu oprogramowania, a w ostateczności również z innych usług zewnętrznych firm, które gruntownie przeanalizują wszystkie aspekty projektu.

Podsumowanie

W dzisiejszym artykule przedstawiłem Ci kilka ciekawych błędów, jakie popełniane są w procesie tworzenia oprogramowania. Tego typu sytuacji warto unikać, ale pamiętajmy, że nigdy nie unikniemy wszystkich. Warto zadbać o to, aby oprogramowanie było na bieżąco testowane przez odpowiedni zespół testerski, a w razie potrzeby może będzie konieczność skorzystania z audytu, który da odpowiedź, w jakim stanie znajduje się kod? Oby nigdy nie przytrafiła Ci się taka sytuacja. Jej uniknięcie nie jest wcale takie trudne, jak się wydaje.

Spodobało się?

Jeśli tak, to zarejestruj się do newslettera aby otrzymywać informacje nowych artykułach oraz akcjach edukacyjnych. Gwarantuję 100% satysfakcji i żadnego spamowania!

, , , , , , , , , ,

Dodaj komentarz

guest
0 Komentarzy
Inline Feedbacks
View all comments

Pin It on Pinterest