Author: Jarosław Stadnicki

Jakość czy też jak woli empik “Jakaść”

~ Jarosław Stadnicki ~ Leave a comment

Siedzę na tej zsyłce, patrze i napatrzyć się nie mogę – jak można pewne proste rzeczy tak spierdolić. Proste sprawy jak odczytanie ramki z sieci, prosty switch w środku i jak to może nie zadziałać? Ano może się okazuje – jak się chce to koledzy z B. centrum chujozy potrafią. Jak? A to proste! Nikt tutaj nie robi review kodu, a jeżeli zrobi się i to tak mają to głębiej my. Może dlatego że używają operatora “?” – z tym, nic strasznego, każdy na studiach musiał poznać zasadę działa tego dziada. Ale tutejsi przechodzą samych siebie, przykład: “a?b:c?d:e?f:g?h:i;” są tutaj takie kwiatki. Kod poprawny, a potem jak chcesz to zrozumieć to gorzej. Rozumiem goto, nawet polubiłem bo czasem ratuje dupsko, ale czy taki kod jest w porządku:

success:
  return S_OK;
fail:
  assert( FALSE );
  return E_FAIL:

Do tego dochodzi magiczny sposób formatowani kodu, który czytelny staje się nie wiem kiedy. Jeszcze nigdy nie widziałem tak złego formatowania. Bardzo często zdarza mi się uznać wywołanie funkcji za definicje jakiejś struktury (sic!).

Być może jest jeszcze jeden problem, a nawet dwa. Obiecuję dzisiaj więcej nie kaleczyć języka polskiego.
Raz – podczas pracy siedzią na facebook czy na czatach i zamiast być skupionym na robocie, wchodzić w zone, zen, nirwane, czy co tam klikają to, nie lubię tamtego i umawiają się na randki.
Dwa – brak odpowiedzialności. Jak się coś zjebie, to wszyscy bekną. Jak muszkieterzy 😉 Nie ważne czy robisz czy klikasz, masz pensję, a robotę jak nie ty, to ktoś inny odwali. Jak się zjebie, to trudno, przecież to nie ja pisałem.

Panowie wystarczy chcieć pisać dobrze, a z czasem się wszystko ułoży.
Tym oto mądrym zdaniem kończę kolejny żałosny wpis.

porady jak lepiej, najlepiej, wunder

~ Jarosław Stadnicki ~ 1 Comment

dzone – nie wiem czy znacie (pewnie tak), to taki agregator hiciorów z neta. Mam rssy od nich ze stronki i często można tam (zresztą nie tylko u nich), znaleźć wpis o tym co zrobić by być lepszym programistą, menagierem, testerem. Jak lepiej robić to i tamto lepiej czy w ogóle super. Praktycznie zawsze jest przy tym jakaś cyferka 8 sposobów, 3 drogi, 13 uproszczeń, bla bla bla. Już prawie się uodporniłem na takie wpisy, choć czasem się skuszę i kliknę i jak zwykle jestem zawiedziony – czemu? Bo zawsze jest to samo! Rób review, debuguj, skup się, testuj, … Którego nie klikniesz to na pewno takie punkty tam będą. Moje proste pytanie po co się z tym ciągle powtarzać?

Tak chciałem się tym podzielić z moim słitaśnym blogaskiem. Następny razem takiego linka nie kliknę 😉 (mam nadzieje).

Chcesz się pożalić, albo mnie wyśmiać – napisz
js

release, debug, #ifdef

~ Jarosław Stadnicki ~ Leave a comment

Czytam i czytam kod, staram się go zrozumieć. Czasem każą mi coś poprawić albo napisać testy. Ale jak widzę, że kod dla release, debug, czy np. QAC zachowuje się inaczej to lekki nerw mnie łapie. Pomijam różnice w dodatkowym kodzie z “logprint” czy “assert” – ok, to nie zmienia logiki aplikacji (chyba że jest app jest time-driven [sic!]). Ale! Jak można prześledzić zachowanie aplikacji, kiedy w jednej wersji zachowuje się inaczej niż w drugiej? Ja tego nie potrafię zrozumieć.
I jeszcze jedna dziwna rzecz, która do tej pory do mnie nie dotarła. Ktoś u klienta powiedział “mają być asserty“. No więc są:

if( warunek == ok )
{
    // do stuff 
}
else
{
    // assert( false );
}

I bardzo proszę mądrość internetową, która może tutaj kiedyś zawita o wytłumaczenie mi takiego kodu. Dodam że to w embedded, więc liczę na jakiś głębszy ukryty sens.

siara jak zwykle ale trzeba
uściski!
js

//łupdejt
Poprawka do formatowania kodu

Jak następnym razem zacznę projekt

~ Jarosław Stadnicki ~ Leave a comment

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.

krótko, szybko i na temat – jak zrobić własny widok

~ Jarosław Stadnicki ~ Leave a comment

Jestem świeżo po przeczytaniu więc jeszcze pamiętam i mam zapisane najważniejsze kroki, oto przepis na własny widok.
1) Bierzesz 1 widok, który chcesz zmodyfikować na własny użytek – dziedziczysz po owym.
2) Robisz obsługę wszystkich możliwych konstruktorów widoku po którym odziedziczyłeś. Raczej ważne – nigdy nie wiesz, z którego dalvik wywali Ci wyjątek!
3) Jeżeli potrzebujesz dodajesz odpowiednie .xml z parametrami dla kolorów, rozmiarów czy innego dziadostwa, którego nie chcesz i nie powinieneś trzymać zaszytego na stałe w kodzie
4) W swojej metodzie inicjującej – inicjujesz wszystko co będzie ci potrzebne do używania w nowej klasie widoku, np. zaczytujesz kolorki z .xml.
5) W onDraw dodajesz swój kod. Wszystko co będzie przed super.onDraw() będzie pod klasą bazową, wszystko co będzie po będzie nad tym co narysowała klasa bazowa. Oczywiście jeżeli wywołasz super.onDraw(…);
6) Definiujesz layout swojego widoku w odpowiednim .xml. Łudząco podobny do głównego layout’u aplikacji.
7) Używasz swojego nowego widoku w kodzie. Np.int id = R.layout.myNewView; blabla.setView(id);

Po odpaleniu i wywalaniu się aplikacji przeglądasz jaki wyjątek poleciał w dalvikvm, poprawiasz, jarasz się swoim nowym widokiem.

Mega droidowych hakierów pozdrawiam. Na razie nie wiem jak inaczej zrobić własny widok. Jak się dowiem to napisze. Na ten czas to musi wystarczyć.

Działa? Poka – Pochwal się! Pytania? – dajesz!

ps. Jak się dowiem jak to dodam obsługę [code]…[/code] żeby ładne różowe kolory były.