Zagrożenia związane z projektem J2EE!

Na różnych stanowiskach programisty, starszego programisty i architekta widziałem dobre, złe i brzydkie projekty w języku Java dla przedsiębiorstw! Kiedy zadaję sobie pytanie, co sprawia, że ​​jeden projekt się udaje, a inny kończy się niepowodzeniem, trudno jest znaleźć idealną odpowiedź, ponieważ sukces okazuje się trudny do zdefiniowania dla wszystkich projektów oprogramowania. Projekty J2EE nie są wyjątkiem. Zamiast tego projekty kończą się sukcesem lub porażką w różnym stopniu. W tym artykule staram się wskazać 10 najważniejszych zagrożeń, które mają wpływ na sukces projektu w języku Java w przedsiębiorstwie, i przedstawić je czytelnikowi.

Niektóre z tych niebezpieczeństw po prostu spowalniają projekt, niektóre są fałszywymi ścieżkami, a jeszcze inne mogą całkowicie zrujnować wszelkie szanse powodzenia. Wszystkich można jednak uniknąć dzięki odpowiedniemu przygotowaniu, wiedzy o planowanej podróży i miejscowym przewodnikom znającym teren.

Ten artykuł ma prostą strukturę; Każde zagrożenie omówię w następujący sposób:

  • Nazwa niebezpieczeństwa: Jedna linijka określająca zagrożenie
  • Faza projektu: faza projektu, w której występuje zagrożenie
  • Etap (y) projektu, na które ma wpływ: w wielu przypadkach zagrożenia mogą mieć efekt domina na późniejszych etapach projektu
  • Objawy: Objawy związane z tym zagrożeniem
  • Rozwiązanie: Sposoby całkowitego uniknięcia zagrożenia i zminimalizowania jego wpływu na projekt
  • Uwagi: Punkty, które chcę przekazać, odnoszą się do zagrożenia, ale nie pasują do poprzednich kategorii

Jak wspomniano powyżej, zbadamy każde zagrożenie w kontekście korporacyjnego projektu Java, wraz z jego ważnymi fazami. Fazy ​​projektu obejmują:

  • Wybór dostawcy: proces wybierania najlepszej możliwej kombinacji narzędzi przed rozpoczęciem projektu J2EE - od serwera aplikacji po markę kawy.
  • Projekt: Pomiędzy rygorystyczną metodologią kaskadową a podejściem „zakoduj i zobacz”, leży moje podejście do projektowania: wykonuję wystarczająco dużo projektów, aby móc swobodnie przejść do rozwoju. Uważam swoją fazę projektowania za zakończoną, kiedy dokładnie wiem, co buduję i jak to zbuduję. Ponadto korzystam z szablonów projektowych, aby upewnić się, że zadałem wszystkie właściwe pytania dotyczące siebie i proponowanego przeze mnie rozwiązania przed przejściem do programowania. Jednak nie boję się kodować w tej fazie; czasami jest to jedyny sposób, aby odpowiedzieć na pytanie dotyczące powiedzmy, wydajności lub modułowości.
  • Rozwój: faza projektu, w której pokaże się ilość pracy wykonanej we wcześniejszych fazach. Dobry wybór narzędzi w połączeniu z dobrym projektem nie zawsze oznacza super płynny rozwój, ale z pewnością pomaga!
  • Stabilizacja / testowanie obciążenia: W tej fazie architekt systemu i kierownik projektu narzucą zamrożenie funkcji i skupią się na jakości kompilacji, a także zapewnią, że istotne statystyki systemu - liczba jednoczesnych użytkowników, scenariusze przełączania awaryjnego itd. - może być napotkany. Jednak do tej fazy nie należy ignorować jakości i wydajności. Rzeczywiście, nie możesz pisać słabego lub wolnego kodu i pozostawić go do czasu ustabilizowania się, aby naprawić.
  • Na żywo: To nie jest tak naprawdę faza projektu, to data osadzona w kamieniu. Ta faza dotyczy przygotowań. To tam powrócą duchy błędów przeszłości, które będą nawiedzać Twój projekt, od złego projektu i rozwoju po kiepski wybór dostawców.

Rysunek 1 ilustruje fazy projektu, na które mają największy wpływ różne przyczyny (w szczególności efekt domina).

Cóż, bez zbędnych ceregieli, przejdźmy od razu do pierwszej dziesiątki!

Niebezpieczeństwo 1: brak zrozumienia języka Java, brak zrozumienia EJB, brak zrozumienia J2EE

Racja, podzielę ten na trzy podelementy dla łatwiejszej analizy.

Opis: brak znajomości języka Java

Faza projektu:

Rozwój

Etap (y) projektu, na które ma wpływ:

Projekt, stabilizacja, na żywo

Wpływ na charakterystykę systemu:

Konserwowalność, skalowalność, wydajność

Objawy:

  • Ponowna implementacja funkcjonalności i klas już zawartych w podstawowych interfejsach API JDK
  • Nie wiedząc, jakie są niektóre lub wszystkie z poniższych i czym się zajmują (ta lista stanowi tylko przykładowe tematy):
    • Garbage collector (pociąg, generacyjny, przyrostowy, synchroniczny, asynchroniczny)
    • Kiedy obiekty mogą być zbierane jako śmieci - wiszące referencje
    • Zastosowane mechanizmy dziedziczenia (i ich kompromisy) w Javie
    • Metoda przeciążenia i przeciążenia
    • Dlaczego java.lang.String(zastąp tutaj swoje ulubione zajęcia!) Źle wpływa na wyniki
    • Semantyka przekazywania przez odwołanie w Javie (w porównaniu z semantyką przekazywanej wartości w EJB)
    • Używanie ==a implementowanie equals()metody dla elementów innych niż pierwotne
    • Jak Java planuje wątki na różnych platformach (na przykład z wywłaszczaniem lub nie)
    • Zielone wątki a natywne wątki
    • Hotspot (i dlaczego stare techniki dostrajania wydajności negują optymalizacje Hotspot)
    • JIT i kiedy dobre JIT zepsują się (nieskonfigurowane, JAVA_COMPILERa Twój kod działa dobrze itp.)
    • Kolekcje API
    • RMI

Rozwiązanie:

Musisz pogłębić swoją znajomość języka Java, zwłaszcza jego mocnych i słabych stron. Java to nie tylko język. Równie ważne jest zrozumienie platformy (JDK i narzędzi). Konkretnie, powinieneś uzyskać certyfikat programisty Java, jeśli jeszcze nim nie jesteś - będziesz zaskoczony, jak wiele nie wiedziałeś. Jeszcze lepiej, zrób to jako część grupy i popychaj się nawzajem. W ten sposób jest też fajniej. Co więcej, załóż listę mailingową poświęconą technologii Java i kontynuuj! (Każda firma, z którą pracowałem, ma te listy, z których większość dotyczy aparatów podtrzymujących życie z powodu braku aktywności). Ucz się od innych programistów - to najlepsze źródło informacji.

Uwagi:

Jeśli Ty lub inni członkowie Twojego zespołu nie rozumiesz języka programowania i platformy, jak możesz mieć nadzieję na zbudowanie udanej aplikacji Java dla przedsiębiorstw? Silni programiści Java podchodzą do EJB i J2EE jak kaczki do wody. Z kolei słabi lub niedoświadczeni programiści będą konstruować aplikacje J2EE o niskiej jakości.

Opis: Brak zrozumienia EJB

Faza projektu:

Projekt

Etap (y) projektu, na które ma wpływ:

Rozwój, stabilizacja

Wpływ na charakterystykę systemu:

Konserwacja

Objawy:

  • EJB, które działają, gdy są wywoływane po raz pierwszy, ale nigdy później (szczególnie bezstanowe komponenty bean sesji, które są zwracane do gotowej puli)
  • Jednorazowe EJB
  • Brak wiedzy za co odpowiada programista w porównaniu z tym, co zapewnia kontener
  • Komponenty EJB, które nie są zgodne ze specyfikacją (uruchamianie wątków, ładowanie bibliotek rodzimych, próby wykonywania operacji we / wy itd.)

Rozwiązanie:

Aby poprawić swoją wiedzę na temat EJB, poświęć weekend i przeczytaj specyfikację EJB (wersja 1.1 ma 314 stron). Następnie przeczytaj specyfikację 2.0 (524 strony!), Aby dowiedzieć się, czego nie dotyczy specyfikacja 1.1 i dokąd zaprowadzi Cię specyfikacja 2.0. Skoncentruj się na częściach specyfikacji, które informują twórcę aplikacji, jakie są działania prawne w EJB. Sekcje 18.1 i 18.2 to dobre miejsca na rozpoczęcie.

Uwagi:

Nie patrz na świat EJB oczami sprzedawcy. Upewnij się, że znasz różnicę między specyfikacjami, na których opiera się model EJB, a ich konkretnym podejściem. Zapewni to również możliwość przeniesienia swoich umiejętności do innych dostawców (lub wersji) w razie potrzeby.

Opis: Brak zrozumienia J2EE

Faza projektu:

Projekt

Etap (y) projektu, na które ma wpływ:

Rozwój

Wpływ na charakterystykę systemu:

Utrzymanie, skalowalność, wydajność

Objawy:

  • Projekt „Wszystko jest EJB”
  • Ręczne zarządzanie transakcjami zamiast korzystania z mechanizmów udostępnianych przez kontener
  • Niestandardowe implementacje zabezpieczeń - platforma J2EE ma prawdopodobnie najbardziej kompletną i zintegrowaną architekturę zabezpieczeń w komputerach korporacyjnych, od prezentacji po zaplecze; rzadko jest używany w pełni

Rozwiązanie:

Poznaj kluczowe komponenty J2EE oraz jakie zalety i wady wnosi każdy z nich do stołu. Pokryj po kolei każdą usługę; wiedza jest tutaj mocą.

Uwagi:

Tylko wiedza może rozwiązać te problemy. Dobrzy programiści Java są dobrymi programistami EJB, którzy z kolei mają idealną pozycję, aby zostać guru J2EE. Im więcej posiadasz wiedzy o Javie i J2EE, tym lepiej będziesz projektować i wdrażać. Wszystko zacznie się układać na swoim miejscu w czasie projektowania.

Niebezpieczeństwo 2: nadmierna inżynieria (do EJB lub nie do EJB)

Faza projektu:

Projekt

Etap (y) projektu, na które ma wpływ:

Rozwój

Wpływ na charakterystykę systemu:

Utrzymanie, skalowalność, wydajność

Objawy:

  • Ponadgabarytowe EJB
  • Programiści, którzy nie potrafią wyjaśnić, co robią ich EJB i relacje między nimi
  • Jednorazowe komponenty EJB, komponenty lub usługi, gdy powinny
  • EJB rozpoczynające nowe transakcje, gdy zrobi to istniejąca transakcja
  • Poziomy izolacji danych ustawione na zbyt wysoki (w celu zapewnienia bezpieczeństwa)

Rozwiązanie:

Rozwiązanie dla nadmiernej inżynierii pochodzi bezpośrednio z metodologii programowania ekstremalnego (XP): zaprojektuj i zakoduj absolutne minimum, aby spełnić wymagania określania zakresu, nic więcej. Chociaż musisz być świadomy przyszłych wymagań, na przykład przyszłych średnich wymagań dotyczących obciążenia lub zachowania systemu w szczytowych czasach ładowania, nie próbuj zastanawiać się, jak system będzie musiał wyglądać w przyszłości. Ponadto platforma J2EE definiuje cechy, takie jak skalowalność i przełączanie awaryjne, jako zadania, które infrastruktura serwerowa powinna wykonywać za Ciebie.

Przy minimalnej liczbie systemów składających się z małych komponentów zaprojektowanych do robienia jednej rzeczy i wykonujących ją dobrze, poziom ponownego wykorzystania wzrasta, podobnie jak stabilność systemu. Ponadto zwiększa się łatwość konserwacji systemu, a przyszłe wymagania można znacznie łatwiej dodać.

Uwagi:

Oprócz rozwiązań wymienionych powyżej zastosuj wzorce projektowe - znacznie usprawnią one projekt Twojego systemu. Sam model EJB szeroko wykorzystuje wzorce projektowe. Na przykład

Home

interfejs każdego EJB jest przykładem wzorca Finder i Factory. Zdalny interfejs EJB działa jako serwer proxy dla rzeczywistej implementacji komponentu bean i ma kluczowe znaczenie dla zdolności kontenera do przechwytywania połączeń i świadczenia usług, takich jak przejrzyste równoważenie obciążenia. Zignoruj ​​wartość wzorców projektowych na własne ryzyko.

Kolejne niebezpieczeństwo, przed którym nieustannie ostrzegam: używanie EJB ze względu na to. Nie tylko niektóre części aplikacji mogą być modelowane jako EJB, kiedy nie powinny, ale cała aplikacja może korzystać z EJB bez mierzalnego zysku. Jest to nadmierna inżynieria doprowadzona do skrajności, ale widziałem doskonale dobre aplikacje serwletowe i JavaBean, które zostały rozerwane, przeprojektowane i zaimplementowane przy użyciu EJB bez dobrych powodów technicznych.

Niebezpieczeństwo 3: Brak oddzielenia logiki prezentacji od logiki biznesowej

Faza projektu:

Projekt

Etap (y) projektu, na które ma wpływ:

Rozwój

Wpływ na charakterystykę systemu:

Konserwowalność, rozszerzalność, wydajność

Objawy:

  • Duże i nieporęczne strony JSP
  • Edycja stron JSP następuje po zmianie logiki biznesowej
  • Zmiana wymagań dotyczących wyświetlania wymusza edycję i ponowne wdrażanie EJB i innych komponentów zaplecza

Rozwiązanie:

Platforma J2EE daje możliwość oddzielenia logiki prezentacji od nawigacji i sterowania, a wreszcie od logiki biznesowej. Nazywa się to architekturą Modelu 2 (zobacz Zasoby dla dobrego artykułu). Jeśli już wpadłeś w tę pułapkę, potrzebna jest sztywna dawka refaktoryzacji. Powinieneś przynajmniej mieć cienkie pionowe plasterki, które są w większości samodzielne (to znaczy sposób zamawiania widżetu jest oddzielny od tego, jak zmieniam nazwę użytkownika lub hasło). Użyj tej niejawnej organizacji systemu, aby refaktoryzować etapami.

Uwagi:

Korzystanie ze spójnego projektu w połączeniu ze strukturą interfejsu użytkownika (na przykład taglibs) pomoże również uniknąć problemów z separacją logiczną w projekcie. Nie kłopocz się budowaniem innego frameworka GUI dla własnych potrzeb, jest zbyt wiele łatwo dostępnych dobrych implementacji. Oceń każdy z nich po kolei i zastosuj ramy, które najlepiej odpowiadają Twoim potrzebom.

Niebezpieczeństwo 4: Brak wdrożenia w miejscu, w którym się rozwijasz

Faza projektu:

Rozwój

Etap (y) projektu, na które ma wpływ:

Stabilizacja, równoległe, na żywo

Wpływ na charakterystykę systemu:

Twój zdrowy rozsądek

Objawy:

  • Wielodniowe lub tygodniowe przejścia na systemy na żywo
  • Ryzyko związane z uruchomieniem jest znaczne, a wiele niewiadomych i głównych scenariuszy użytkowania nie zostało przetestowanych
  • Dane w aktywnych systemach to nie to samo, co dane w konfiguracjach programistycznych lub stabilizacji
  • Brak możliwości uruchamiania kompilacji na komputerach deweloperskich
  • Zachowanie aplikacji nie jest takie samo w środowiskach programistycznych, stabilizacji i produkcyjnych

Rozwiązanie:

Rozwiązanie problemu Danger 4 zaczyna się od wiernego skopiowania środowiska produkcyjnego w środowisku programistycznym. Twórz dokładnie na tej samej konfiguracji, na której planujesz rozpocząć życie - nie twórz na JDK 1.3 i Red Hat Linux, jeśli planujesz rozpocząć na JDK 1.2.2 i Solaris 7. Dalej, nie rozwijaj na jednym serwerze aplikacji, a na innym. Uzyskaj również migawkę danych z produkcyjnej bazy danych i użyj jej do testowania, nie polegaj na sztucznie utworzonych danych. Jeśli dane produkcyjne są wrażliwe, odczul je i załaduj. Nieoczekiwane dane produkcyjne się zepsują:

  • Zasady walidacji danych
  • Testowane zachowanie systemu
  • Umowy między komponentami systemu (w szczególności EJB-EJB i baza danych EJB)

Co najgorsze, każdy z nich spowoduje wyjątki, zerowe wskaźniki i zachowanie, którego nigdy wcześniej nie widziałeś.

Uwagi:

Programiści często zostawiają zabezpieczenia do czasu stabilizacji („Tak, ekrany działają, teraz dodajmy elementy związane z walidacją użytkowników”). Uniknij tej pułapki, poświęcając tyle samo czasu na wdrażanie zabezpieczeń, co na logikę biznesową.