J2EE-projektin vaarat!

Erilaisina kehittäjänä, vanhempana kehittäjänä ja arkkitehtina toimimiseni aikana olen nähnyt hyviä, huonoja ja rumajarvia yritys Java -projekteissa! Kun kysyn itseltäni, mikä saa yhden projektin onnistumaan ja toisen epäonnistumaan, on vaikea löytää täydellistä vastausta, koska menestys osoittautuu vaikeaksi määritellä kaikki ohjelmistoprojektit. J2EE-projektit eivät ole poikkeus. Sen sijaan projektit onnistuvat tai epäonnistuvat vaihtelevasti. Tässä artikkelissa pyrin ottamaan kymmenen suurinta vaaraa, jotka vaikuttavat yrityksen Java-projektin menestykseen, ja esittelemään ne sinulle, lukijalle.

Jotkut näistä vaaroista yksinkertaisesti hidastavat projektia, jotkut ovat vääriä polkuja, ja toiset taas voivat pilata suoranaiset mahdollisuudet menestyä. Kaikki voidaan kuitenkin välttää hyvällä valmistelulla, tietämyksellä tulevasta matkasta ja maastoa tuntevista paikallisoppaista.

Tämä artikkeli on rakenteeltaan yksinkertainen; Käsittelen jokaisen vaaran seuraavasti:

• Vaaran nimi: Yksi linja, jossa kuvataan vaara
• Projektivaihe: Projektivaihe, jossa vaara esiintyy
• Projektivaihe (t) vaikuttaa: Monissa tapauksissa vaaroilla voi olla vaikutusta hankkeen myöhempiin vaiheisiin
• Oireet: Tähän vaaraan liittyvät oireet
• Ratkaisu: Tapoja välttää vaara kokonaan ja miten minimoida sen vaikutukset projektiisi
• Huomautuksia: Pisteet, jotka haluan antaa, jotka liittyvät vaaraan, mutta eivät sovi edellisiin luokkiin

Kuten edellä todettiin, tarkastelemme kutakin vaaraa yrityksen Java-projektin yhteydessä ja sen tärkeät vaiheet. Hankkeen vaiheet kattavat:

• Toimittajan valinta: Parhaan mahdollisen työkaluseoksen valitseminen ennen J2EE-projektin aloittamista - sovelluspalvelimesta kahvimerkkiin asti.
• Design: Tiukan vesiputousmenetelmän ja "koodaa ja näe" -lähestymistavan välissä on mielestäni muotoilu: Teen tarpeeksi suunnittelua voidakseni siirtyä mukavasti kehitystyöhön. Pidän suunnitteluvaihettani loppuun, kun tiedän tarkalleen, mitä rakennan ja miten rakennan sen. Lisäksi käytän suunnittelumalleja varmistaakseni, että olen kysynyt itseltäni ja ehdotetusta ratkaisustani kaikki oikeat kysymykset ennen siirtymistä kehitystyöhön. En kuitenkaan pelkää koodaamista tässä vaiheessa; joskus se on ainoa tapa vastata kysymykseen sanalla, suorituskyvyllä tai modulaarisuudella.
• Kehitys: Projektivaihe, jossa aiemmissa vaiheissa tehdyn työn määrä näkyy. Hyvä työkaluvalikoima ja hyvä muotoilu eivät aina tarkoita erittäin sujuvaa kehitystä, mutta se auttaa varmasti!
• Vakautus- / kuormitustestaus: Tässä vaiheessa järjestelmäarkkitehti ja projektipäällikkö asettavat ominaisuuksien jäädyttämisen ja keskittyvät rakennuksen laatuun sekä varmistavat, että järjestelmän tärkeät tilastot - samanaikaisten käyttäjien lukumäärä, vikasietotilanteet ja niin edelleen - voidaan täyttää. Laatua ja suorituskykyä ei kuitenkaan pidä jättää huomiotta vasta tässä vaiheessa. Et todellakaan voi kirjoittaa huonolaatuista tai hidasta koodia ja jättää sitä vakautukseen korjaamiseksi.
• Elää: Tämä ei ole oikeastaan ​​projektivaihe, se on kiveen asetettu päivämäärä. Tässä vaiheessa on kyse valmistelusta. Siellä menneiden virheiden haamut palaavat takaisin projektiisi, huonosta suunnittelusta ja kehityksestä huonoon myyjävalintaan.

Kuva 1 havainnollistaa projektivaiheita, joihin eri syyt (ja erityisesti jatkuvaikutukset) vaikuttavat eniten.

Sitten sukelkaamme suoraan 10 parhaan joukkoon ilman lisäsyöttöä!

Vaara 1: Ei ymmärrä Java, ei ymmärrä EJB, ei ymmärrä J2EE

Aivan, aion jakaa tämän kolmeen alaryhmään analyysin helpottamiseksi.

Kuvaus: Ei ymmärrä Javaa

Projektivaihe:

Kehitys

Projektivaihe (t) vaikuttaa:

Suunnittelu, vakauttaminen, live

Järjestelmän ominaisuudet, joihin vaikuttaa:

Ylläpidettävyys, skaalautuvuus, suorituskyky

Oireet:

• JDK: n ydinsovellusliittymien jo sisältämien toimintojen ja luokkien uudistaminen
• En tiedä mitä kaikki tai kaikki seuraavista ovat ja mitä he tekevät (tämä luettelo edustaa vain otosta aiheista):
  • Roskakeräin (juna, sukupolvi, inkrementaalinen, synkroninen, asynkroninen)
  • Kun esineitä voidaan kerätä roskiin - riippuvia viitteitä
  • Perinnemekanismit (ja niiden kompromissit) käytettiin Javassa
  • Menetelmä yli-ratsastus ja ylikuormitus
  • Miksi java.lang.String (korvaa suosikkiluokkasi täällä!) osoittautuu huonoksi suoritukselle
  • Java-ohikulkusemantiikka (verrattuna EJB: n pass-pass-semantiikkaan)
  • Käyttämällä == verrattuna on yhtä suuri () menetelmä ei-primitiivisille
  • Kuinka Java aikatauluttaa ketjut eri alustoille (esimerkiksi ennaltaehkäisevästi tai ei)
  • Vihreät langat vs. alkuperäiset langat
  • Hotspot (ja miksi vanhat suorituskyvyn viritystekniikat kumoavat Hotspot-optimoinnit)
  • Yhteinen tutkintaryhmä ja kun hyvät tutkintaryhmät menevät pieleen (määrittelemätön JAVA_COMPILER ja koodisi toimii hienosti jne.)
  • Collections-sovellusliittymä
  • RMI

Ratkaisu:

Sinun on parannettava Java-tietämystäsi, erityisesti sen vahvuuksia ja heikkouksia. Java on paljon kielen ulkopuolella. Yhtä tärkeää on ymmärtää alustaa (JDK ja työkalut). Konkreettisesti sinun tulee tulla sertifioiduksi Java-ohjelmoijaksi, jos et vielä ole - hämmästyt, kuinka paljon et tiennyt. Vielä parempi, tee se osana ryhmää ja työnnä toisiaan. Se on myös hauskempaa tällä tavalla. Määritä edelleen Java-tekniikalle omistettu postituslista ja jatka sitä! (Jokaisella yrityksellä, jonka kanssa olen työskennellyt, on nämä luettelot, joista suurin osa on elatusapua passiivisuuden vuoksi.) Opi vertaiskehittäjiltäsi - ne ovat paras resurssi.

Huomautuksia:

Jos sinä tai muut tiimisi jäsenet eivät ymmärrä ohjelmointikieltä ja alustaa, kuinka voit toivoa onnistuneen yritys Java-sovelluksen rakentamista? Vahvat Java-ohjelmoijat vievät EJB: lle ja J2EE: n kuin ankat veteen. Sitä vastoin huono tai kokematon ohjelmoija rakentaa heikkolaatuisia J2EE-sovelluksia.

Kuvaus: Ei ymmärrä EJB: tä

Projektivaihe:

Design

Projektivaihe (t) vaikuttaa:

Kehitys, vakauttaminen

Järjestelmän ominaisuudet, joihin vaikuttaa:

Huolto

Oireet:

• EJB: t, jotka toimivat, kun heidät kutsutaan ensimmäisen kerran, mutta eivät koskaan sen jälkeen (varsinkin valtiottomat istuntopavut, jotka palautetaan valmiiseen altaaseen)
• Uudelleenkäytettävät EJB: t
• Tietämättä siitä, mitä kehittäjä on vastuussa verrattuna siihen, mitä säilö tarjoaa
• EJB: t, jotka eivät vastaa määrityksiä (paloketjut, lataa alkuperäiset kirjastot, yritä suorittaa I / O ja niin edelleen)

Ratkaisu:

Paranna EJB-tietämystäsi viettämällä viikonloppu ja lukemalla EJB-määrittely (1.1-versio on 314 sivua). Lue sitten 2.0-eritelmä (524 sivua!) Saadaksesi tuntuman siitä, mitä 1.1-määritys ei käsitellyt ja mihin 2.0-määritys vie sinut. Keskity spesifikaation niihin osiin, jotka kertovat sinulle, sovelluskehittäjälle, mitkä ovat oikeudelliset toimet EJB: ssä. Kohdat 18.1 ja 18.2 ovat hyviä paikkoja aloittaa.

Huomautuksia:

Älä katso EJB-maailmaa myyjän silmillä. Varmista, että tiedät eron EJB-mallin perustana olevien spesifikaatioiden ja niiden erityisen otteen välillä. Tämä varmistaa myös, että voit siirtää taitosi muille toimittajille (tai versioille) tarpeen mukaan.

Kuvaus: Ei ymmärrä J2EE: tä

Projektivaihe:

Design

Projektivaihe (t) vaikuttaa:

Kehitys

Järjestelmän ominaisuudet, joihin vaikuttaa:

Huolto, skaalautuvuus, suorituskyky

Oireet:

• "Kaikki on EJB" -malli
• Manuaalinen tapahtumien hallinta kontin tarjoamien mekanismien käyttämisen sijaan
• Mukautetut tietoturvatoteutukset - J2EE-alustalla on luultavasti kattavin ja integroitu tietoturvaarkkitehtuuri yrityslaskennassa esityksestä aina loppupäähän; sitä käytetään harvoin täysimääräisesti

Ratkaisu:

Opi J2EE: n tärkeimmät komponentit ja mitä etuja ja haittoja kukin komponentti tuo pöydälle. Kattaa jokainen palvelu vuorotellen; tieto on tässä yhtä voimaa.

Huomautuksia:

Vain tieto voi korjata nämä ongelmat. Hyvät Java-kehittäjät tekevät hyviä EJB-kehittäjiä, joista puolestaan ​​on ihanteellinen asema tulla J2EE-guruiksi. Mitä enemmän Java- ja J2EE-tietoja sinulla on, sitä paremmin osaat suunnitella ja toteuttaa. Asiat alkavat sijoittua paikalleen suunnitteluhetkellä.

Vaara 2: ylisuunnittelu (EJB: lle vai ei EJB: lle)

Projektivaihe:

Design

Projektivaihe (t) vaikuttaa:

Kehitys

Vaikuttavat järjestelmän ominaisuudet:

Huolto, skaalautuvuus, suorituskyky

Oireet:

• Ylisuuret EJB: t
• Kehittäjät, jotka eivät osaa selittää, mitä heidän EJB: nsä tekevät ja keskinäisiä suhteita
• Uudelleenkäytettävät EJB: t, komponentit tai palvelut silloin, kun niiden pitäisi olla
• EJB: t aloittavat uusia tapahtumia, kun olemassa oleva liiketoimi tapahtuu
• Tietojen eristystasot asetettu liian korkeiksi (yrittäessä olla turvallisia)

Ratkaisu:

Ratkaisu ylisuunnittelulle tulee suoraan äärimmäisen ohjelmoinnin (XP) metodologiasta: Suunnittele ja koodaa vähimmäismäärä vastaamaan kattavuuden vaatimuksia, ei mitään muuta. Vaikka sinun on oltava tietoinen tulevista vaatimuksista, esimerkiksi tulevista keskimääräisistä kuormitusvaatimuksista tai järjestelmän käyttäytymisestä ruuhka-aikoina, älä yritä arvata, miltä järjestelmän tulee näyttää tulevaisuudessa. Lisäksi J2EE-alusta määrittelee ominaisuudet, kuten skaalautuvuuden ja vikasietoisuuden, tehtävinä, jotka palvelininfrastruktuurin tulisi käsitellä sinulle.

Vähäisillä järjestelmillä, jotka koostuvat pienistä komponenteista, jotka on suunniteltu tekemään yksi asia ja tekemään se hyvin, uudelleenkäyttötaso paranee, samoin kuin järjestelmän vakaus. Lisäksi järjestelmän ylläpidettävyys vahvistaa ja tulevat vaatimukset voidaan lisätä paljon helpommin.

Huomautuksia:

Käytä yllä lueteltujen ratkaisujen lisäksi suunnittelumalleja - ne parantavat merkittävästi järjestelmän suunnittelua. EJB-malli itse käyttää suunnittelumalleja laajasti. Esimerkiksi

Koti

jokaisen EJB: n käyttöliittymä on esimerkki Finder- ja Factory-kuvioista. EJB: n etärajapinta toimii välityspalvelimena varsinaiselle pavun toteutukselle ja on keskeinen säiliön kyvyssä siepata puheluja ja tarjota palveluja, kuten läpinäkyvä kuormituksen tasaus. Ohita suunnittelumallien arvo vaarallasi.

Toinen vaara, jota varoitan jatkuvasti: EJB: n käyttö sen vuoksi. Paitsi että jotkin sovelluksesi osat voidaan mallintaa EJB-tiedostoiksi, kun niiden ei pitäisi olla, sinun koko sovellus saattaa käyttää EJB: itä ilman mitattavaa voittoa. Tämä on ylisuunnittelua äärirajoille, mutta olen nähnyt aivan hyviä servlet- ja JavaBean-sovelluksia repeytyneinä, uudelleen suunnitelluiksi ja toteutetuiksi EJB: n avulla ilman hyviä teknisiä syitä.

Vaara 3: Ei erota esityslogiikkaa liiketoimintalogiikasta

Projektivaihe:

Design

Projektivaihe (t) vaikuttaa:

Kehitys

Järjestelmän ominaisuudet, joihin vaikuttaa:

Ylläpidettävyys, laajennettavuus, suorituskyky

Oireet:

• Suuret ja raskas JSP: t
• Löydät itsesi muokkaamalla JSP: itä, kun liiketoimintalogiikka muuttuu
• Näyttövaatimusten muutos pakottaa muokkaamaan ja asentamaan EJB: itä ja muita taustakomponentteja

Ratkaisu:

J2EE-alusta antaa sinulle mahdollisuuden erottaa esityslogiikka navigoinnista ja hallinnasta sekä lopuksi liikelogiikasta. Sitä kutsutaan Model 2 -arkkitehtuuriksi (katso hyvän artikkelin lähteet). Jos olet jo pudonnut tähän ansaan, tarvitaan jäykkä annos refaktorointia. Sinulla tulisi olla ainakin ohuita pystysuoria viipaleita, jotka ovat suurimmaksi osaksi itsenäisiä (ts. Kuinka widgetiä tilaan, on erillinen osa käyttäjänimen tai salasanan vaihtamisesta). Käytä tätä järjestelmän implisiittistä organisaatiota refaktoriksi vaiheittain.

Huomautuksia:

Yhdenmukaisen suunnittelun käyttö käyttöliittymäkehyksen kanssa (esimerkiksi taglibit) auttaa myös varmistamaan, että vältät logiikan erottamisongelmat projektissasi. Älä vaivaudu rakentamaan toista GUI-kehystä omiin tarpeisiisi, hyviä toteutuksia on helposti saatavilla. Arvioi jokainen vuorotellen ja hyväksy kehys, joka parhaiten sopii tarpeisiisi.

Vaara 4: Älä sijoita kehityspisteitäsi

Projektivaihe:

Kehitys

Projektivaihe (t) vaikuttaa:

Vakautus, rinnakkainen, elävä

Vaikuttavat järjestelmän ominaisuudet:

Järkesi

Oireet:

• Usean päivän tai viikon pituiset siirtymät eläviin järjestelmiin
• Suoraan lähetykseen liittyvä riski on huomattava, monia tuntemattomia ja tärkeimpiä käyttöskenaarioita ei ole testattu
• Tiedot reaaliaikaisissa järjestelmissä eivät ole samoja kuin kehitys- tai stabilointiasetuksissa
• Kyvyttömyys ajaa perustuu kehittäjien koneisiin
• Sovelluskäyttäytyminen ei ole sama kehitys-, stabilointi- ja tuotantoympäristöissä

Ratkaisu:

Danger 4: n ratkaisu alkaa kopioida tuotantoympäristö uskollisesti kehitysympäristösi kanssa. Kehitä täsmälleen samalla asetuksella kuin missä aiot lähteä elämään - älä kehitä JDK 1.3: lla ja Red Hat Linuxilla, kun aiot siirtyä JDK 1.2.2: een ja Solaris 7: een. yhdellä sovelluspalvelimella ja julkaista toisella. Hanki myös tilannekuva tiedoista tuotantotietokannasta ja käytä sitä testaamiseen, älä luota keinotekoisesti luotuihin tietoihin. Jos tuotantotiedot ovat arkaluontoisia, poista niiden herkkyys ja lataa ne. Odottamattomat tuotantotiedot rikkoutuvat:

• Tietojen validointisäännöt
• Testattu järjestelmän käyttäytyminen
• Järjestelmäkomponenttien väliset sopimukset (erityisesti EJB-EJB ja EJB-tietokanta)

Pahinta on, että jokainen näistä johtaa poikkeuksiin, nollaviitteisiin ja käyttäytymiseen, joita et ole koskaan ennen nähnyt.

Huomautuksia:

Kehittäjät jättävät tietoturvan usein vakautumiseen asti ("Joo, näytöt toimivat, lisätään nyt käyttäjien validointitavarat."). Vältä tätä ansaa osoittamalla turvallisuuden toteuttamiseen yhtä paljon aikaa kuin liiketoimintalogiikalle.