31 mar 2009

To zależy...

Rozwijanie oprogramowania to zajęcie inheretnie intelektualne. Taki truizm mi się nasunął :)
Ale zdaje mi się, że wielu programistów o tym zapomina. Myślę, że są ku temu dwa powody - przyzwyczajenia i błędne założenia.
Klasyczny wodospadowy model produkcji oprogramowania zakłada, że najpierw tworzona jest architektura i projekt oprogramowania (i tu jest myślenie - od tego jest Architekt i Projektant, którzy za pomocą Drogiego Narzędzia CASE/UML tworzą Architekturę) a potem trzeba to po prostu zakodować. Tak jak z budynkiem, tylko cegły się ciężej układa, więc przydadzą się studia. I programiści w jakimś stopniu to kupują i programują tak jak im się akurat przydarzy.
Ale w wielu firmach, szczególnie mniejszych software house'ach nie ma działu architektury. Tam ludzie przyzwyczajeni są - jeszcze może z czasów studiów - że myśli to się o algorytmach, o drzewach czerwono-czarnych, o ray-tracingu, może nawet o szeregowaniu zadań w systemie operacyjnym, ale przecież nie w aplikacji webowej. Tę każdy wie jak napisać - tu nie ma o czym myśleć.
Programiści oczekują gotowych rozwiązań. Że książka, blog, prezentacja dadzą im konkretne odpowiedzi. Że zasugerowane w czasie wykładu, rozmowy wzorce będą dobre na każdą sytuację.

Ale oprogramowanie to nie budynki (choć nic nie wiem o tym, może tam też trzeba myśleć...) Tu odpowiedzi są ogólne i niepewne. Bez drobiazgowej znajomości wymagań i reszty aplikacji nie sposób dać stu procentowej odpowiedzi. Nad każdym szczegółem, najdrobniejszym detalem powinno się posiedzieć. Przemyśleć. Zbadać siły działające w tej sytuacji. Przemyśleć jak dany kod będzie wykorzystywany. Ani reguły SOLID ani wzorce GoF ani jakieś cechy języka nie zastąpią myślenia.
Czasem trzeba brać pod uwagę kwestie merytoryczne - wydajność jakiegoś rozwiązania, bezpieczeństwo, itp. Czasem percepcyjne - jak zorganizowany kod jest czytelniejszy, co łatwiej jest zrozumieć. Czasem w końcu organizacyjno-psychologiczne - że baza danych zależna jest od kogo innego i często się zmienia, że większość zespołu woli jakiś inny sposób formatowania, itp.
Dlatego właśnie Big Design Up Front nie może dać dobrej aplikacji (tzn. może się komuś uda, ale generalnie...) Bo nie da się bez kodu i zespołu przemyśleć tego wszystkiego odpowiednio dokładnie.

Zapytał mnie niedawno kolega z pracy jakie rozwiązanie jest lepsze (zainspirowany moim ostatnim wpisem) - mieć oddzielne DAO czy metody operacji na danych bezpośrednio w encjach (Active Record). I nie ma tu dobrej odpowiedzi. W jakimś stopniu jest to kwestia estetyki, w jakimś designu reszty aplikacji. Może tez wchodzić w grę doświadczenie programistów, wybór technologii do przechowywania danych itp. itd.
Czasem używanie tych samych obiektów jako dziedziny (wraz z zachowaniami) i reprezentantów bazy danych (ORM, DTO) jest ok, a czasem (no dobra, częściej) warto trzymać swoje obiekty oddzielnie i nie wystawiać wszystkich ich pól do publicznego dostępu (w ten sposób wiążąc implementacje innych elementów kodu z wyłącznie naszą implementacją dziedziny) a dla Hibernate'a wystawiać DTO (inna reprezentacja danych w bazie a inna w dziedzinie, zmieniająca się struktura bazy, itp.)

Na wiele pytań nie ma jednoznacznych odpowiedzi na samym początku. Na wiele nie ma ich też później, dlatego robimy oprogramowanie tak, by na bieżąco dostosowywać je (refaktoryzować) do zmieniających się warunków (a przecież warunki się ciągle zmieniają w czasie developmentu, bo dodawane są kolejne funkcjonalności). Oprogramowanie nie jest z kamienia ani żelbetu, tylko jest realizacją naszych (elastycznych) myśli.
Tylko od Ciebie zależy jak je budujesz.

1 komentarz:

Tomasz Nazar pisze...

Piszesz: ..."Ale oprogramowanie to nie budynki (choć nic nie wiem o tym, może tam też trzeba myśleć...) Tu odpowiedzi są ogólne i niepewne. Bez drobiazgowej znajomości wymagań i reszty aplikacji nie sposób dać stu procentowej odpowiedzi. Nad każdym szczegółem, najdrobniejszym detalem powinno się posiedzieć. Przemyśleć. Zbadać siły działające w tej sytuacji. Przemyśleć jak dany kod będzie wykorzy"...


Wiec Pawle, pierwsza czesc wniosku jest prawdziwa; Jest "ogolnie" i "niepewnie".
Druga mozesz zastosowac wlasciwie i do oprogramowania i budynkow.
Dlatego trzeba pierwszy wniosek pociagnac: oprogramowanie to nie budynek, bo budynek ma stac, sie nie ruszac, wybierasz projekt i pozamiatane. Nic nie zmienisz, machina ruszyla.

Oprogramowanie ma i bedzie sie zmieniac w czasie. Wymagania klienta sie zmieniaja. Trzeba dojsc do tego, czego klient potrzebuje i to juz bedzie sukces. A odbywa sie to ciagle, przez proces ciaglego "dostrajania" i odkrywania wymagan.

Ostatnio wlasnie w tej sprawie pokazano mi ciekawe 2 obrazki porownójące sytuacje: Strzelanie-do-celu.
Do budynku: celujesz, celujesz, strzelasz! Gotowe.
Do oprogramowania: strzelasz, przecelowujesz, przecelowujesz, ... i wroc i powtorz.

Mysle, ze prosty przyklad, a daje do myslenia i sporo uswiadamia :)

SCM pozdrawia SCP ;)