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

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
Not invented here
Większość z Was pewnie wie doskonale co oznaczają trzy słowa w tytule. Pozostałych odsyłam tutaj. Prawie każdy programista na pewnym etapie swojego rozwoju (o którym świetnie piszę Procent tu, tu i tu) cierpi na chorobę pisania wszystkiego od nowa. Wydaje mi się, że wynika to z ogromnej pychy, która jest niezbywalną cechą programistów - "przecież ja zrobiłbym to lepiej!". Łatwo potępiać takie postępowanie, kiedy patrzy się na nie z perspektywy wielu lat doświadczenia - że bez sensu, że szkoda czasu, że przecież są ludzie mądrzejsi.

Tu mała dygresja, żeby nie pozostawiać wątpliwości - szczerze nienawidzę syndromu "not invented here" w odniesieniu do inżynierii oprogramowania jako dziedziny przemysłu. NIH w firmach nie sprawdza się prawie nigdy.

Z drugiej strony jednak uważam, że podejście to ma swoje zalety i, odpowiednio zastosowane, może być wartościowe. Według mnie "not invented here" drzemiące gdzieś w zakamarkach duszy programisty zachęca go do podejmowania twórczych działań w celu zmiany otaczającego go świata. Być może delikwent taki nie napisze od postaw kolejnego framework-u Dependency Injection, ale zrobi coś, aby ten, którego używa był lepszy. A wszystko po to, aby uciszyć wyrzuty sumienia, w którym tkwi ziarno "not invented here".

Kolejną zaletą wymyślania koła na nowo jest fakt, że jest to świetna metoda nauki nowych technologii i koncepcji. Żadna książka i żadne szkolenie nie zastąpi zaimplementowania dobrze znanej funkcjonalności za pomocą nowej technologii.

I tym optymistycznym akcentem chciałbym zaanonsować nowy cykl notek na tym blogu: moja własna szyna usług. Temat ten został ostatnio spopularyzowany przez Ayende Rahien, który pogardził nServiceBus Udiego Dahana oraz MassTransit-em i podjął się budowy własnej szyny. Idąc więc za ciosem, ja również będę miał własną szynę. A co!?!:)

Opublikowane 5 lutego 2009 18:22 przez simon

Filed under:

Powiadamianie o komentarzach

Jeżeli chciałbyś otrzymywać email gdy ta wypowiedź zostanie zaktualizowana, to zarejestruj się tutaj

Subskrybuj komentarze za pomocą RSS

Komentarze:

# re: Not invented here @ 5 lutego 2009 18:51

O, i bardzo fajnie, będzie interesująca lektura:).

A do rywalizacji obrałeś sobie zaprawdę imponujące nazwiska.

Procent

# re: Not invented here @ 5 lutego 2009 20:44

Nie do końca się zgadzam, iż pycha gra tutaj główną rolę. Mnie się zdarzało wykonywać mniej lub bardziej zaawansowane rozwiązania ponieważ:

- Zamiast 200 klas, których działania nie do końca rozumiem mam 8 (przykładowo oczywiście);

- Lepiej poznaję mechanizmy, wzorce oraz pomysły rozwiązywania problemów;

- Lepiej czasem napisać własne rozwiązanie niż za miesięcy kilkanaście kiedy wejdzie nowa wersja systemu czy kolejny service pack zastanawiać się czemu nasz program przestał działać (przeżyłem to).

A propos szyny. Mając luźne powiązania pomiędzy klasami tego typu rozwiązanie jest bardzo przydatne. Dwa interfejsy i jedna klasa i oto mamy prosty rozsyłacz komunikatów. U mnie się to nazywa MessageDeliverer. Nie potrzebuję wątków, kolejek komunikatów i wielu innych jakże interesujących elementów. A ile frajdy przy takim tworzeniu ;- )

arkadiusz.wasniewski

# re: Not invented here @ 6 lutego 2009 09:17

"not invented here" jest dokładnie tym, co dzieje się w świecie linuxa. W efekcie mamy wolność wyboru i możemy wybrać spośród tysięcy programów robiących dokładnie to samo, tylko z innymi parametrami w commandline. Super sprawa, ale jakoś nie kojarzy mi się z rozwojem IT ;)

A jeżeli zacznę tam, gdzie inni skończyli - a nuż choć trochę pchnę świat do przodu.

Ale to może moje skrzywione podejście, wynikające z faktu, że własne "not invented here" miałem lekko licząc dwadzieścia lat temu ;)))

GT

# re: Not invented here @ 6 lutego 2009 09:50

Procent, nie jestem szalony i nie liczę, że moje rozwiązanie będzie konkurować z rozwiązaniami tych dwóch panów;) Może zdradzę odrobinę szczegółów, ale ja chcę tylko:

* poznać lepiej Service Broker-a

* zbudować lekką bibliotekę, której ilość klas jest rzędu 8-10, a nie 200;)

* przedstawić nieco inne podejście do tworzenia tego typu rozwiązań (inne nie znaczy lepsze/gorsze)

Więcej szczegółów w następnej notce...

Arku, jeśli chodzi o argument z ilością klas to trafiłeś w sedno. Mój pomysł wziął się z tego, że chciałem przeprowadzić szkolenie z Event Driven SOA (na podstawie Udiego), ale gdybym skorzystał z nServiceBus lub czegoś podobnego to całkowicie zaciemniłoby sens. Zamiast myśleć o biznesie ludzie myśleliby jak skonfigurować 56-tą wtyczkę.

Z drugiej strony chcę moją "szynę" wykorzystać do integracji wielu aplikacji ".NET + SQLServer" i wydaje mi się to najwygodniejsze rozwiązanie.

GT, ja moje "not invented here" zakończyłem (mam nadzieję, że na dobre) jakieś dwa lata temu;) Zakończyłem z mocnym postanowieniem, że nigdy więcej nie powiem "mógłbym to zrobić lepiej" zanim nie policzę kosztów (czasu, pieniędzy). Aktualnie mocno przeżywam fakt, że w mojej firmie zamiast kupić kontrolki ASP.NET z półki, buduje się własną bibliotekę webową, bo będzie "szybsza, lepsza, ładniejsza". Nie wierzę...

simon

Co o tym myślisz?

(wymagane) 
wymagane 
(wymagane) 

  
Wprowadź kod: (wymagane)