Ostatnimi czasy więcej czytam niż piszę i tak mi się kilka przemyśleń zebrało na temat: “co ja bym zrobił lepiej w tym projekcie”. Żeby było jasne, to są moje przemyślenia, do których bd starać się zastosować. Czysta teoria, nie potwierdzoną praktycznie żadną praktyką. Może poza kilkoma linijkami kodu. Czytam teraz takie różne kawałki kodu, pisze różne testy i wynika z tego prosta sprawa. Taniej, szybciej i skuteczniej jest napisać kawałek prostego testu, a potem poprawić drobne błędy. Niż napisać oddać testerom i “czekać” na listę błędów. Można inaczej: jedna osoba pisze kod, druga testy. Według mnie to jest strasznie uciążliwe, o każdej zmianie trzeba informować piszącego test, a nie zawsze się o tym pamięta. Jak testy nie przechodzą to nie do końca wiadomo kto zjebał, takie to nie poręczne. W dodatku w tej sytuacji, osoba pisząca testu musi wiedzieć co się dzieje w kodzie, znać specyfikacje i ogólnie ogarniać komponent – dla mnie to nie potrzebne powtarzanie. Osobiście uważam, że developer który pisze kod, jest za niego odpowiedzialny jak i za jego jakość => sam powinien zadbać o jego poprawne działanie.
Oczywistą oczywistością jest to, że nie będzie po kolei. Tzn od ważnej do nie ważnej, od małej do dużej, czy od żółtej do czerwonej.
Do rzeczy:
Weryfikuj zawsze dane wejściowe, jeżeli używasz wskaźników to przede wszystkim sprawdź czy wskazują tam gdzie powinny. Czyli nie są null, jeżeli będziesz z nich odczytywać lub do nich zapisywać. Lub czy są null jeżeli będziesz do nich przypisywać. To w ogóle temat rzeka z tymi wskaźnikami. Jeżeli oczekujesz wartości sprawdź, czy te które dostałeś są poprawne, np. mieszczą się w obsługiwanych zakresach. Ten mały i prosty kawałek kodu, ułatwi późniejsze debugowanie. Po wszystkim można taki kod wrzucić w #ifdef _DEBUG_ i po sprawie.
Odruchowo do każdego kodu, który wypocisz dodaj kawałek testu, który sprawdzi czy rzeczywiście, to co zrobiłeś działa tak byś sobie życzył. Postaraj się wywołać metodę / funkcję z każdym możliwym parametrem, nawet z takim, który uznasz za błędny. Przecież od tego masz weryfikacje danych wejściowych. Jeżeli kod ma coś zwrócić sprawdź czy wynik jest tym czego oczekujesz lub czy rzucony wyjątek jest tym o który chodzi. Do każdego z rodzaju testów stwórz sobie osobne środowisko, a ingerencje w kod testowany naprawdę ogranicz do niezbędnego minimum. Najgorszą sprawą jest, gdy okazuję się że test jednostkowe i systemowe nie mogą zostać przeprowadzone na tym samym kodzie, lub że wyniki dla tych samych komponentów dadzą inny wynik.
Po tym jak obmyślisz już co piszesz, jak, w czym, etc. I narysujesz sobie kilka kwadracików ze strzałeczkami i takich tam. Kiedy myślisz, że to już ten moment że możesz już pisać. Odczekaj jeszcze z 5 minut. Popatrz na te ładne obrazki i pomyśl czy to na pewno tak ma być. Nie zapomniałeś o czymś? Co się stanie i jak bardzo będziesz się musiał namęczyć żeby dodać jakiegoś nowego ficzera? Albo czy możliwe będzie ponowne wykorzystanie komponentów, które właśnie zamierzasz zakodzić. Czy napewno dziedziczenie a nie agregacja 😉 Jeżeli po 5 minutach nadal jesteś pewien swego, to śmiało zaczynaj pisać.
Tutaj się trochę powtórzę, ale to mój blog więc mogę. Chodzi mi o obrazki, jak sobie narysujesz już wszystkie klocki układanki, wszystkie przepływy, kto, z kim i dlaczego. Zrób przysłowiowy krok w tył i spójrz czy nie będzie Ci wstyd takiego gniota później pisać i poprawiać. Prawie zawsze można lepiej.
Życie: nigdy nie zaczynaj dnia pracy od suszonych owoców.
Jak już ktoś przebrniesz przez moje propozycje, dorzuć coś od siebie.
Wstyd mi za tego posta, ale musze.