Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
[PL] Having The Infrastructure vs having an infrastructure
Pod tym angielsko brzmiącym tytułem kryje się jak najbardziej polska notka. Po prostu nie udało mi się znaleźć dobrego polskiego tłumaczenia (pewnie z powodu braku article-i).

Do napisania zainspirował mnie tym razem Ayende, a szczególnie jeden z diagramów zamieszczony w tym poście. Bardzo częstym błędem większości początkujących architektów (a do takich chciałbym się zaliczać) jest kładzenie nacisku na Infrastrukturę. Wciąż pokutuje myślenie iż technologia jest lekarstwem na wszelkie problemy związane z tworzeniem oprogramowania. Nie czuje się kompetentny, aby oskarżać jakąś konkretną metodykę o doprowadzenie do tak silnej pozycji Infrastruktury, jednak mam niejasne przekonanie, że jest to związane z wodospadowym modelem tworzenia oprogramowania. Koncepcja Infrastruktury, na której można potem budować biznes oprogramowania przypomina bowiem bardzo koncepcję wszechwładnej analizy, po której zakończeniu można budować projekt, po czym implementację i tak dalej...

Tak więc zastępy młodych adeptów sztuki programowania chcący wybić się ponad szarość codziennej pracy programistycznej budują Infrastrukturę zupełnie jakby budowali katedrę. Podobnie jak katedry, Infrastruktura bardzo rzadko bywa ukończona w ramach planowanego budżetu, a często (także wzorem katedr) nie udaje się jej zbudować nigdy - po prostu Infrastruktura jest tak ambitnym projektem, że nie niemożliwym jest wykonanie go skończonym czasie.

Skąd to wszystko wiem? Ano z własnego doświadczenia. Nie raz chciałem budować takie katedry. Nie raz też budowałem. Jedną z nich, konkretnie NetMX, wciąż buduje. Cegiełka po cegiełce, dzień po dniu, w nadziei, że projekt kiedyś udowodni ostatecznie swoją przydatność. W tym wypadku na swoje usprawiedliwienie mam jedynie to, iż NetMX nie był planowany jako Infrastruktura, na której będziemy budować. Miało być to jedynie narzędzie rozwiązujące pewien problem. I i tak wciaż uważam, że na platformie .NET nie ma bezpośredniej konkurencji:-)

Ale wracając do głównego tematu... Moja rada na dzis to: nie warto budować Infrastruktury! Warto natomiast mieć infrastrukturę. Zadaniem infrastruktury przez małe "i" jest wymuszenie koncepcji architektonicznych. Ponieważ dobra architektura to taka, której jest jak najmniej, infrastruktury też powinno być niewiele.

Przykład z mojego aktualnego podwórka. Problem do rozwiązania to, opisywana przeze mnie wcześniej, synchronizacja dwóch odległych modeli oraz utrzymywanie (z możliwością odtworzenia) historii zmian owychm modeli. Rozwiązaniem mogłoby być zbudowanie (zanim oczywiście rozpoczniemy jakąkolwiek implementacje klas biznesowych) Infrastruktury synchronizacyjnej oraz Infrastruktury przechowywania historii. Dwie ogromne i zaawansowane biblioteki to smaczny kąsek dla każdego szanującego się geeka. Warto jednak na chwilę przystopować i zastanowić się nad naszym ostatecznym celem.

Czy klient zapłaci nam za Infrastrukturę? Czy klienta w ogóle interesuje, w jaki sposób dane są synchronizowane? Oczywiście, że nie. Idąc dalej: czy jeśli będziemy mieć w naszej firmie Wielką Bibliotekę Do Synchronizacji oraz Wielką Bibliotekę Do Historii to da nam to przewagę nad konkurencją? Oczywiście, że nie. W dzisiejszych czasach tego typu rozwiązania można albo znaleźć w sieci albo kupić za cenę jednej maszyny deweloperskiej.

To, co tak naprawdę się liczy, to funkcjonalność biznesowa. Kod biznesowy generuje zyski dla naszego klienta, a zadowolony klient to najlepsze, czego może sobie życzyć firma produkująca oprogramowanie.

Wracając do mojego problemu: oba szczytne i ambitne cele mogą być rozwiązane dzięki zastosowaniu jednego wzorca Command. Infrastruktura (przez małe "i") dla tego rozwiązania mieści się w dwóch klasach i jednym interfejsie, których cały kod mieści się na jednym ekranie. "Moduł Historii", ktory wykorzystuje te klasy ma jakieś 50 linii kodu dosyć luźno napisanego i potrafi odtworzyć obraz dowolnego obiektu modelu w dowolnym punkcie w czasie.

Czy w następnym projekcie będę chciał wykorzystać ten kod? Oczywiscie, że nie. Mogłoby to bowiem przesłonić mi drogę do rozwiązania problemu w inny sposób, który w tamtym projekcie może być dużo lepszy. Nawiązując do świetnego posta Udiego, nie widzę już zysku w reużywaniu kodu. Widzę natomiast zysk, i to ogromny, w reużywaniu myśli, idei. Idea wzorca Command, stworzona przez Bandę Czworga, użyta przeze mnie w moim projekcie może potencjalnie (pożyjemy, zobaczymy...) zaoszczędzić bardzo dużo czasu, a co za tym idzie pieniędzy. Decyzja o budowie dwóch skomplikowanych bibliotek już na dzień dobry pochłonęłaby całkiem sporo zasobów, nie dając przy tym żadnej gwarancji zwrotu inwestycji.

Rozważcie jeszcze jedno: myślenie jest o wiele mniej kosztowne od pisania kodu, a nie potrzeba do niego absolutnie żadnych narzędzi. No może poza jednym, ale w nie jesteśmy wszyscy wyposażeni przez matkę naturę.

Opublikowane 22 lipca 2009 23:58 przez simon

Filed under:

Komentarze:

# re: [PL] Having The Infrasctructure vs having a infrastructure @ 23 lipca 2009 07:56

@Simon: A nie winno być "an infrastructure"?

brejk

# re: [PL] Having The Infrasctructure vs having a infrastructure @ 23 lipca 2009 08:05

Dzięki:)

simon

# re: [PL] Having The Infrastructure vs having a infrastructure @ 23 lipca 2009 08:26

Dokładnie, najpierw napisać coś prostego wykonującego dane zadanie i nic więcej, bez zakładania "to będzie rozwiązanie na wszystkie moje kolejne projekty"; potem z tego korzystać; potem w razie potrzeby rozwinąć na tyle, na ile zmieniają się AKTUALNE wymagania.

Procent

# Simon says... : [PL] Having The Infrastructure vs having an infrastructure @ 23 lipca 2009 10:05

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

dotnetomaniak.pl

# re: [PL] Having The Infrastructure vs having an infrastructure @ 23 lipca 2009 13:32

Podpisuję się wszystkimi mackami. Można robić biznes na Infrastrukturze - projektujesz jakieś super biblioteki i sprzedajesz je programistom. Tyle że to kiepski biznes bo programiści to wybredni klienci którzy nie chcą się rozstawać z pieniędzmi. Lepiej już wziąć te super biblioteki i tak je posklejać aby powstało Oprogramowanie - czyli coś co ładnie wygląda i robi jakieś użyteczne rzeczy. Ma się rozumieć użyteczne dla ludzi z pieniędzmi, nie programistów.

nightwatch

# re: [PL] Having The Infrastructure vs having an infrastructure @ 24 lipca 2009 10:11

YAGNI się kłania. Sam często produkuje niepotrzebnie skomplikowany (zbyt abstrakcyjny) kod infrastrukturalny. Moim zdaniem jednym z lepszych rozwiązań na tego typu problemy jest praca w parze lub częste rewizje kodu w zespole, które szybko są w stanie wychwycić tego typu kod. Oczywiście również wskazana (wręcz wymagana) jest dyskusja i modelowanie na bieżąco architektury.

Roman Jendrusz

# re: [PL] Having The Infrastructure vs having an infrastructure @ 27 lipca 2009 16:02

@Nightwatch

A propos super bibliotek - szykuje już kolejnego posta który rozprawi się z superbibliotekami;)

@Roman

Masz rację, jeśli chodzi o rewizje. Problem z nimi polega jednak na tym, że działają na poziomie kodu i programistów. Dużo ciężej jest poradzić sobie z problemem, jeśli Infrastruktura przez duże "I" jest wprowadzana "z góry" przez architekta. Pół biedy, jeśli można mu zarzucić, że coś jest "overarchitected" (za dużo skomplikowanego kodu). Dużo trudniej udowodnić, że biblioteka (która jest sprawdzona i mam ją za darmo) także większa stopień skomplikowania w kodzie i także należy jej unikać, jeśli to tylko możliwe.

simon

Komentarze anonimowe wyłączone