Diagram prawdę Ci powie

porozmawiajmy o diagramach

Zdaję sobie sprawę, że pewnie wielu z Was odrzuca na samą myśl o UML-ach, ale chcąc nie chcąc, na pewnym etapie Waszej kariery się z nimi spotkacie i możliwe, że nawet sami będziecie musieli je wykorzystać do pracy twórczej.

Dlaczego tylu programistów czuje awersję do diagramów? Cóż, przypuszczam, że wynika to z pewnej niechęci do tego, czego nie znamy, w tym konkretnym przypadku – do języka, który jest nam obcy. Bo tym właśnie jest UML, językiem, który nie wszyscy rozumiemy, którym nie wszyscy mówimy. Dzisiaj jednak nie o tym.

YAGNI + Test First

czy warto pisać testy przed implementacją?

Testowanie samo w sobie przynosi korzyści, zazwyczaj w dłuższej (oby:) perspektywie czasu, ale prędzej czy później jesteśmy w stanie dostrzec ich wartość i nieraz oddychamy z ulgą, gdy widzimy, że ludzie pracujący nad kodem przed nami, poświęcili trochę czasu na napisanie solidnych zestawów. Lecz o zaletach posiadania testów już pisałem ostatnio (tutaj i ciąg dalszy :).

I o ile z tym, że posiadanie testów przynosi korzyści i jest to jedna z tych rzeczy, którą wielu programistów chce praktykować nie kłóci się nikt, o tyle nie wszyscy widzą jakikolwiek sens w pisaniu testów przed implementacją. Że niby sprawia, że kod jest lepszy, że jeszcze raz myślimy o problemie, że patrzymy na niego od innej strony, itp., itd.
Problem z tymi wszystkimi stwierdzeniami jest taki, że to są jedynie oklepane zwroty, którymi karmią nas bardziej doświadczeni, mądrzejsi znawcy tematu, którzy powołują się na własne doświadczenie i którym powinniśmy zaufać. I ja wcale nie twierdzę, że nie mają racji, czy też nie neguję ich kompetencji, ale człowiek (a programista też człowiek :) woli uczyć się na własnych błędach. Przynajmniej do momentu, gdy nie zobaczy konkretnego przykładu, który pokazuje mu, że jednak jest tak, jak podpowiada starszy kolega.

Diagramy statyczne nie są drogą do celu

Ostatnio miałem okazję przyglądać się kilku osobom, które nie mają zbyt wielkiego doświadczenia w tworzenia projektów. Posiadają wiedzę na temat programowania obiektowego, znają paradygmaty, wzorce, ogólnie całkiem nieźli z nich programiści, jednak swoją przygodę z tworzeniem designów dopiero zaczynają.
Jedną z obserwacji, która rzuciła mi się w oczy jest sposób w jaki większość z nich rozpoczyna tworzenie projektu. Mianowicie - zaczynają od tworzenia diagramów klas.

SOLIDny kod cz. 3 - Open/closed principle

łatwo powiedzieć

W najprostszej i najkrótszej postaci definicja drugiej zasady SOLID, to: elementy systemu powinny być otwarte na rozszerzenia, ale zamknięte na zmiany. Proste, jasne i przejrzyste, czyż nie? No dobra, może nie takie jasne i przejrzyste, ale przynajmniej proste. Łatwo zapamiętać:)

Może przesadzam z tym, że nie jest ona (definicja) równie przejrzysta jak prosta, bo w większości przypadków programista jest w stanie wytłumaczyć o co chodzi - "O to, żeby łatwo było rozszerzać bez mieszania w kodzie". Problemy zaczynają się wtedy, gdy docieramy do projektowanie czy też tworzenia kodu, bo to, co prosto powiedzieć, już wcale takie banalne w realizacji nie jest.

Jak umożliwić rozwój, który nie wymaga zmian?

You Aren't Gonna Need It

programista = wróżbita

Z moich obserwacji wynika, że większość programistów ma podświadomy pociąg do arkanów sztuk tajemnych, w szczególność do wróżbiarstwa. I o ile nie widzę nic złego w oderwaniu się od codziennej rutyny, to problem zaczyna się wtedy gdy owe zainteresowania zaczynają praktykować również podczas tworzenia kodu. I jeszcze śmiem twierdzić, że to również nie jest takie tragiczne, ale... no właśnie... ale najczęściej to przepowiadanie przyszłości programistom najzwyczajniej nie wychodzi zbyt dobrze.

Żeby nie powiedzieć - wcale.

Więcej nie znaczy wolniej cz.3 - projektowanie

zaprojektujmy coś...

Kiedy przeprowadziliśmy już analizę i wiemy, co klient chce abyśmy zrealizowali, wiemy, czego nie chce i obie strony rozumieją co i jak ma działać, możemy ruszać dalej, czyli przełożyć wymagania na coś, co lepiej pasuje do naszego obiektowego świata:)
Jednym zdaniem - pora na zaprojektowanie naszej aplikacji.

Więcej nie znaczy wolniej cz.1

o tym, co sprawia, że jesteśmy lepsi

Ostatnio robiłem podsumowanie roku kierowania projektem (pisałem o tym tutaj) i statystyki, które ujrzały moje oczy, były dużo lepsze niż się spodziewałem:)
Nie jestem jednak osobą, która długo cieszy się sukcesami. Większą radość odnajduję w kolejnych wyzwaniach, więc następnego dnia, po przedstawieniu zespołowi efektów naszej wspólnej pracy, zacząłem się zastanawiać, co dalej? Wychodzę z założenia, że pozostanie w tym samym miejscu jest równoznaczne z cofaniem się do tyłu, tak więc jedynie kolejne ulepszenia wchodzą w grę:)

SOLIDny kod cz. 2 - Single responsibility principle

w czym rzecz

Jak już ostatnio pisałem, Single responsibility principle (SRP), czyli zasada jednej odpowiedzialności, mówi o tym, że klasa nie powinna mieć więcej niż jednego powodu do modyfikacji.
Często spotykam się z tym, że programiści twierdzą, że takie myślenie prowadzi jedynie do niepotrzebnego rozbijania każdej klasy na kilka bądź więcej elementów składowych. Co za tym idzie? Potrzeby zarządzania wieloma klasami. A to wszystko tylko po to, żeby zrobić coś naprawdę prostego.

Cóż, można na to spojrzeć w ten sposób. Jednak jest kilka ale...

SOLIDny kod cz. 1 - wstęp

SOLIDnie, czyli jak?

Skoro podstawy programowania obiektowego mamy już za sobą (dla tych, którzy przegapili - spis treści jest tutaj), to pora zająć się jakimiś poważniejszymi tematami związanymi z OOP :)

Na początek chciałbym rozszyfrować akronim SOLID.
Co się za nim kryje? Zbiór pięciu podstawowych zasad dotyczących programowania obiektowego:

• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

interfejs + unsupported method? WTF ?!

przesada jest twoim wrogiem

Żaden z nas nie posiadł całej wiedzy, którą posiada obecnie, wraz z pierwszym kontaktem z programowaniem obiektowym. To oczywiste, że wszystkiego trzeba się nauczyć. Trwa to dłużej lub krócej, uczymy się na własnych błędach, doświadczeniu innych itp.

Czasami odkrywamy "coś", co na zawsze zmienia nasz sposób postrzegania kodu. Zdarza się, że danego rozwiązania, konstrukcji etc. używaliśmy wcześniej, ale dopiero w pewnym momencie odkrywamy wszystkie tajemnice stojące za danym zagadnieniem, ich piękno i wartości. A przynajmniej tak nam się wydaje:)

co się dzieje, gdy deklaracje są podobne...

what's the problem?

Czasami zdarza nam się zauważyć w kodzie metody, które posiadają takie same deklaracje. Jest to nieuniknione, dziesiątki, setki i więcej tysięcy linii kodu sprawia, że niekiedy "powtórzenia" tego typu się zdarzają.
Dlaczego "powtórzenia" w cudzysłowie? Ponieważ nie jest to wynik duplikacji logiki, a jedynie użycia języka w celu opisania danej funkcjonalności. Tylko czy rzeczywiście nie jest?

czy wystarczy klasa, czy już czas na interfejs?

w czym problem?

Czasami są sytuacje, kiedy poważnie się zastanawiamy nad tym, czy interfejs jest nam rzeczywiście potrzebny, czy może jego stworzenie byłoby po prostu generowaniem zbędnego kodu, mającego na celu tylko i wyłącznie dodanie kolejnego elementu do, już i tak dość skomplikowanej, struktury.

Kiedy, więc klasa już nam nie wystarcza i niezbędne staje się wprowadzenie interfejsu?

baza danych nie istnieje

o problemi słów kilka

Zdarzyło mi się kilka (lub trochę więcej:) razy, że przy prezentowaniu projektu aplikacji programistom, padało pytanie: 'a gdzie jest baza danych?'.
No właśnie, gdzie ona jest?
Skoro prezentuje działanie aplikacji, jej logikę, to pojawiaja się przecież jakaś reprezentacja danych (modele), ale gdzie ja je trzymam, skądś muszę je odczytać, jakoś zapisać, zaktualizować. Gdzie? Kiedy? Jak? I dlaczego nie ma tego wszystkiego w projekcie?

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?

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.

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