ile testów jednostkowych warto napisać?

a na co mnie to?

Testy jednostkowe (jak i wszelkie pozostałe) przydają się. Co prawda nie są, jak sądzą niektórzy, gwarancją tego, że nasz kod nie posiada błędów i jest wolny od jakichkolwiek pomyłek. Dają nam jedynie informacje, że nie udało się danego błędu znaleźć oraz, co równie ważne, że w określonych przypadkach kod/aplikacja zachowuje się tak, jak zakładamy.

Ta druga informacja jest w stanie ułatwić nam życie w naprawdę wielkim stopniu, gdy dochodzimy do momentu, gdy kod trzeba refaktoryzować/modyfikować. Testy dają nam pewność, że w danych przypadkach, po wszystkich wprowadzonych zmianach, wszystko nadal działa w sposób prawidłowy.

Konstruktor w interfejsie i klasie abstrakcyjnej?

wstęp

Abstrahując od tego, na co pozwala nam dany język programowania (np. PHP pozwala niestety na wszystko), to czy w interfejsie jest sens posiadać deklarację konstruktora? A co w przypadku klas abstrakcyjnych? Jak sądzicie, taka funkcjonalność może się przydać, czy raczej jest to coś zbędnego, czego najprawdopodobniej nigdy byście nie wykorzystali?

Ważne, żeby był porządek:)

o czytelności kodu raz jeszcze

Było o tym, jakie stosować nazwy w kodzie, było o komentarzach, a teraz przyszła pora na kolejny wpis dotyczący czytelności kodu. I ponownie poruszam temat błahy, ale mam nadzieję, że rady w nim zawarte komuś się przydadzą:)

Dzisiaj będzie o kolejności, w jakiej atrybuty i metody powinny występować w kodzie, w zależności od ich definicji.

Komentarze? Tylko pod wpisem, nie w kodzie:)

na początek

Na początku był kod. Kod, który się rozrastał, żył, ewoluował, a pracę nad nim wykonywało programistów wielu. I kod ten spełniał swoje zadanie. I nigdy nie dotknął go zbędny proces refaktoryzacji, co pozwoliło, że rozmiary jego były naprawdę okazałe, jego możliwości - mnogie, a czytelność - żadna.

"Na szczęście", w trakcie pracy nad kodem, wielu programistów, którzy mieli z nim do czynienia, otaczali kolejne linijki instrukcji, pokaźną ilością komentarzy, które miały na celu przekazać przyszłym pokoleniom tajemnice zawarte w kodzie i uzmysłowić jego działanie.

Nowy wygląd strony

Jak łatwo zauważyć pobawiłem się trochę wyglądem strony:) Zdecydowałem się na taki zabieg z dwóch powodów. Po pierwsze, stary wygląd już mnie zaczął nudzić:P Po drugie, chciałem dodać trochę radosnych kolorów:)

Skąd ten wpis? Bo nie jestem do końca pewien, czy wygląd jest dobry, czy nie rozprasza uwagi, czy kolory nie są zbyt jaskrawe. Niestety moje zdolności odnośnie projektowania wyglądu stron internetowych nie są powalające, dlatego też zdecydowałem się na opublikowanie tego krótkiego wpisu, z nadzieją na jakieś uwagi z Waszej strony:)

Jeżeli coś Wam się nie podoba, coś warto zmienić lub coś po drodze popsułem i nie zauważyłem tego, to będę wdzięczny za komentarze, najlepiej konstruktywne:P
Ponieważ milczenie jest oznaką zgody, to brak komentarzy uznam za podzielenie mojego pomysłu na nowy wygląd strony, więc lepiej zastanówcie się dwa razy, czy warto z komentowania zrezygnować:)

Rzeczy po imieniu nazywać

nie o formie, a o treści

Jest wiele artykułów na temat nazewnictwa i z przykrością stwierdzam, że i ja go poruszę:) Zdaję sobie sprawę, że dla niektórych Was temat jest prosty, ale uważam, że jest to na tyle istotna rzecz, że warto poświęcić jej choć jeden wpis.

Chciałem jeszcze na wstępie zaznaczyć, że nie będę zajmował się tym, czy w nazwach powinniśmy używać podkreśleń, czy też wielkich liter, czy wszystko powinno być pisane ciągiem itp. Tu już wszystko zależy od polityki firmy i konwencji (bądź jej braku) przyjętych w danym języku programowania.

"Język inżynierii systemów SysML"

celem wyjaśnienia własnych poczynań

Dzisiaj skończyłem czytać książkę "Język inżynierii systemów SysML. Architektura i zastosowania. Profile UML 2.x w praktyce" i choć kiedyś sobie obiecałem, że na blogu nie będę umieszczać żadnych recenzji, czy też opinii na temat książek, doszedłem do wniosku, że pora na weryfikację tego poglądu:)
Jeżeli przeczytam coś, obok czego naprawdę nie powinno się przejść obojętnie - napiszę o tym..
Jeżeli przeczytam coś, czego należy unikać za wszelką cenę - również postaram się opublikować stosowny artykuł:)
Pomijam oczywiście książki, które przeczytałem do tej pory, bo albo wrzuciłem o nich wzmiankę na Google+ albo na Twitterze, a nawet jeżeli nie, to są istotniejsze tematy, na które warto pisać:P

Które metody umieścić w interfejsie?

krótki wstęp, a w nim o tym, czym jest interfejs

Do czego wykorzystuje się interfejsy? Do zapewnienia, że obiekty danej klasy będą posiadały określone metody. Po co chcemy mieć tą pewność? Ponieważ w danym miejscu ich posiadanie jest niezbędne do bezbłędnego wykonania pewnych instrukcji. Dlaczego wszystkie metody interfejsu są abstrakcyjne? Gdyż nie wymagamy określonego ich działania, wymagamy jedynie ich istnienia.

Mój kod jest świetny!

Testowanie to naprawdę świetna sprawa. Pokazuje, czy wszystko działa:)
Tylko, że niestety nie pokazuje. Jedynie dostarcza nam informacji, że nie udało nam się znaleźć błędu, a to jest naprawdę istotna różnica.

ten pieprzony init()

ten pieprzony init

Zend w wersji 1.x obfitował w klasy, które posiadały deklarację pustej metody init(), która była wywoływana w konstruktorze.

Do czego jest ona wykorzystywana? Twórcy Zenda doszli do wniosku, że jeżeli chcesz np. stworzyć odpowiednio skonfigurowany formularz (np. do dodawania produktów), to idealnym rozwiązaniem będzie rozszerzenie klasy Zend_Form i umieszczenie całej kofiguracji owego formularza w nadpisanej metodzie init(), która wykona się przy tworzeniu nowego obiektu.

Sprytne, no nie? I jeszcze w dodatku można pokusić się o stwierdzenie, że jest to implementacja wzorca template method.

Chciałbym jednak zasmucić wszystkich tych, którzy praktykują takie rozwiązanie. Ani to sprytne nie jest, a użycie wzorca jest niepoprawne i niepotrzebne.