Yleinen koodi tai koodi, joka on helppo ymmärtää?

Sinun tulisi jäsentää mallit käyttämällä samoja sääntöjä kuin ohjelmoinnissa. Tämä tarkoittaa lähinnä yhteisten suunnitteluelementtien purkamista erillisiksi tiedostoiksi päällekkäisyyksien välttämiseksi ja siten uudelleenkäytettävämmän suunnittelun saavuttamiseksi. Se on sääntö # 1 ( KUIVA ) ja menetelmää kutsutaan ohjelmointitarkoituksessa uudelleen.

Toinen sääntö on, että sinun tulisi pyrkiä yksinkertaisuus ja selkeys. Sen pitäisi olla helppo ymmärtää asettelua ja minne mennä, kun sinun on muutettava asioita.

Ensimmäisen kirjaimen säännön noudattaminen johtaa GUI: n voimakkaaseen hajoamiseen moniin pieniin katkelmiin, mikä voi vaikeuttaa asettelun luomisen ymmärtämistä. Sinun täytyy metsästää paljon löytääksesi missä asiat ovat. Tämä rikkoo toista sääntöä, joten sinun on löydettävä tasapaino näiden kahden vastakohdan välillä.

Mutta paras tapa on löytää ratkaisu, joka välttää tämän ongelman kokonaan. Mielestäni tässä tapauksessa sinun tulisi harkita yksinkertaisempaa lähestymistapaa kokonaan . Oletan, että tämä on HTML ja mainitset ”yksinkertaiset ja edistyneet” tilat käyttöliittymässä. Oletko harkinnut aina luoda kaikki kenttiä ja käsitellä sitten GUI-logiikkaa JavaScriptissä? Toisin sanoen, kirjoita asiakaspuolen koodi, joka piilottaa ja näyttää kyseiset kentät lennossa riippuen siitä, missä tilassa (tilassa) se on?

Tällä on myös se etu, että pystyt vaihtamaan tilaa tilauksesta ilman palvelinta, eikä sinun tarvitse tinkiä mihinkään sääntöihin. Toinen hieno asia on, että voit antaa käyttöliittymän kavereille tee nämä muutokset tarvitsematta ottaa mukaan taustajärjestäjiä, jotka eivät yleensä ole kovin innokkaita viettämään aikaa suunnittelun ja vuorovaikutuksen säätämisellä ja kiillottamisella.

Kommentit

• Olen eri mieltä siitä, että JS on yksinkertaisempi, miksi? Suurin osa työtoveristani ei tiedä JS: n ja Java-verkkokehyksiä yhä useammin, jotta voit jättää JS: n huomiotta (Richfaces, GWT ). Lähes kaikki yritykset eivät välitä JS: stä (luulen, että minulle esitettiin yksi JS-kysymys kaikissa yrityksissä, joissa olen koskaan haastattellut). Joten työtoverini eivät koskettaneet kyseistä koodia ja he vain kirjoittavat sen uudelleen, jos heillä olisi Ideasi on hyvä, mutta se ei ole realistinen. plus miksi pitää osa logiikastasi jaavassa ja osa JS: ssä? Luulen, että syy siihen, miksi tallennetut menettelyt olivat kuolleet (ja tein li ke ne).
• @ 0101 En sanonut ’ en sanonut, että JS on yksinkertaisempi tai vaikeampaa kuin mikään muu. Se riippuu taidoistasi. Pätevän html-kooderin kanssa tämä ei ole ongelma. Sanoin, että siirtämällä GUI-ongelmat GUI-tasolle (mihin se kuuluu) saat usein paljon yksinkertaisemman ratkaisun. Tämä johtuu siitä, että graafiset käyttöliittymät ovat erittäin dynaamisia ja vuorovaikutteisia, mihin JS: n kaltaisille kielille on tehty. Vain siksi, että luulet, että ” yksikään yritys ei välitä JS: stä ”, ’ ei tee minun mielipiteeni ei ole yhtä pätevä.
• Mielestäni sen tyyppinen asia on, kysymys on, mitä minun tilanteessani pitäisi tehdä, ja vastauksesi on kuin ” käytä tallennettuja menettelyjä ” ja se ei ole kelvollinen, koska kukaan ei käytä sitä, ja olisi vaikea ymmärtää, miksi olisin käyttänyt niitä. ’ kysyn, mikä tapa on parempi tulevaisuuden kannalta, koska en ’ en ole täysin varma, että valintani on paras (nyt paras tapa on sivuuttaa ärsyttävät työtoverit).
• @ 0101: Verkon ja HTML: n kanssa työskenteleminen edellyttää enemmän tai vähemmän JavaScriptiä (ja HTTP-, CSS- ja kuvia …), joten voit ’ t todella syyttää minua siitä, että oletin, että JavaScript oli vaihtoehto. ’ ei ole kuin minä ’ pyytäisin sinua kirjoittamaan se Swingiin.
• ” Lähes kaikki yritykset eivät välitä JS ” – uskotko vakavasti siihen? Rikkaat käyttöliittymät verkossa ovat liikkuneet asiakaspuolen suuntaan jo vuosia. Minusta tuntuu, että sinulta puuttuu vene tästä.

Näkymättä koodia voin vain spekuloida, mutta luulisin, että tällä hetkellä koodisi on ”reunalla”.

2 tai 3 tilassa, joissa on rajoitettu määrä muutoksia tilojen välillä, mitä sinulla on nyt on todennäköisesti OK. Jos sen pitäisi olla monimutkaisempi, kuulostaa siltä, että se olisi muunnettava erillisiksi sivuiksi.

Henkilökohtaisesti pidän mieluummin helposti ymmärrettävästä koodista – se on paljon ylläpidettävämpi sekä muille kehittäjille että itsellesi, kun sinun täytyy noutaa se uudelleen 6 kuukautta riviltä.

Koodia ei kuitenkaan ole syytä muokata nyt ratkaisemaan ongelma, jota ei ehkä ole tulevaisuudessa. . Sanot, ettet tiedä kuinka paljon vaatimukset muuttuvat – eikä siihen sisälly muutoksia – joten YAGNI: n (You Ain ”t Gonna Need It) soveltaminen ei tee mitään nyt.

Merkitse koodi vaatii huomiota tulevaisuudessa, joten älä unohda sitä, mutta älä muuta (ja mahdollisesti rikkoa) sitä nyt.

Kommentit

• + 1 – Jos olet epävarma, se on helppo ymmärtää. Hämmennyksesi mielessäsi siitä, pitäisikö sinun tehdä siitä yleinen, on luonnollinen tapa kertoa sinulle, että sinun ei pidä ’ t.

Olen tehnyt melkein saman asian. Uskokaa minua, kun muutama erilainen käyttäytyminen on toteutettu kullekin tilalle, ”pääsivusta” tulee melkein mahdotonta lukea. Näet sitten vain joukon ohjausvirtauslohkoja (pian Matrix-digitaalinen sade). Huomasin poistavan joitain lohkoja vain saadakseni selkeän kuvan siitä, mitä tietyssä tilassa on.

Joten ”erilliset sivut” on oikea tapa. Mutta kun teet niin, sinun on ” taistele ”koodin kopiointiongelma. Tässä kollegasi saattaa olla väärässä ehdottamalla sulautumisia. Valitettavasti olen myös tehnyt sen. Pohjimmiltaan se toimii, mutta se vie paljon kallisarvoista aikaa ja lopulta huonon sulautumisen vuoksi sivujen ”yhteinen alue” ei ole synkronoitu ja sulautumisesta tulee todellinen painajainen. Joten olet oikeassa vastustamalla yhdistämistä kohtuullisena ratkaisuna.

Kuten monista vastauksista näet, oikea tapa on purkaa todella ”yleisiä” osia ulkoisiin kokonaisuuksiin (JSP-sivupalat, JSF-katkelmat, mitä tahansa) ja sisällytä ne noille sivuille.

Kommentit

• todellinen ongelma, että yhteinen koodi on vain ohjaimet h: inputText + h: outputText yksi kenttä. Mielestäni ei ole syytä taistella sitä vastaan. plus tämä sivu saattaa kuolla, koska se ei ole oikeastaan toimiva, johtuen tiloista ja se hämmentää jopa muita kehittäjiä (käyttäjän näkökulmasta).
• Joten ongelma on oikeastaan milloin siirtyminen tapahtuu. Sinun on harkittava jakamista uudelleen jokaisen muokkauksen jälkeen. Kun sivu alkaa olla sotkuinen – jaa se. Mielestäni työtoverisi on myös mukavampi, jos pidät hänen ajatustaan hyvänä, mutta et vielä ole sen toteuttamisen arvoinen.

Tämä näyttää JSF: ltä. Jokainen renderoitu = ”…” tarkoittaa olennaisesti sitä, että koodissasi on if, mikä aiheuttaa monimutkaisuutta.

Olen tehnyt saman, koska ”se on sama sivu vain muutamalla erolla täällä ja siellä ”ja yksinkertaisesti sanottuna, se ei toimi pitkällä aikavälillä, koska se ei” t samalla sivulla, ja sinun on tehtävä enemmän ja monimutkaisempia temppuja, jotta se toimisi oikein, mikä aiheuttaa tarpeettoman vaikeaa ylläpitää.

Jos käytät JSF: tä fasettien kanssa JSP: n sijaan (jonka pitäisi, jos voisit), niin voit rakentaa XML-fragmentteja, jotka vastaavat sivulohkoa ja jotka voit sitten sisällyttää tarvittaessa. Tämä ostaa modulaarisuutta ja antaa sinun silti käyttää sisältöä uudelleen eri sivuilla.

Kuuntele työtoveriasi. Hän on oikeassa.

Kommentit

• katso muokkaustani
• @ 0101, epäilin täsmälleen tämä. Älä tee sitä, se on tie hulluuteen – luultavasti sinulle – ja varmasti tuleville ylläpitäjille.
• todellinen ongelma on, että matkani on paras tapa. Jos tein 3 sivua, joku voisi vaihtaa vain yhtä sivua eikä ajattele muita. Haluaisin versioni tulevana ylläpitäjänä.
• Luulen, että koodini saa tulevaisuuden ylläpitäjän miettimään muita tapauksia. Jos olisit projektin uusi ohjelmoija ja virheenkorjausohjelmassa havaitsisi, että sinun on vaihdettava koodi baseFormBasic.xhtml: ssä, muuttaisitko sen myös tiedostoissa baseFormAdv ja baseFormSpec?
• @ 0101, miksi kysytään mikä on parasta, jos haluat vain vahvistaa ennakkoluulosi?

Onko mahdollista luoda sivu käytät koodia? Entä täältä:

page1 = { showField1 = true; showField2 = false; showField3 = true; } page2 = { showField1 = true; showField2 = false; showField3 = false; } 

Ja sivun renderöintikoodissa

if page.showField1 then .... if page.showField2 then .... 

Tai OOP-tyylillä:

class Page1 { renderField1() { ...} renderField2() {} renderField2() { ...} } class Page2 { renderField1() { ...} renderField2() {} renderField2() {} } 

kommentit

• ei, muutosta ei ole . Minut ristiinnaulittaisiin, jos tekisin sen. plus se luo täsmälleen saman ongelman. if == renderoitu.
• Se ei ole tarkka ongelma, koska se poimii sivulogiikan. Suoritetaan vain yksi tehtävä kahden sijaan.
• ehkä, mutta minusta tuntuu samalta. syynäni on, että kenttien näyttäminen on vain yksi asia, joka on erilainen, on myös erilainen sijoitus ja joskus tarrat. plus sen verkko-ohjelmointi, joten en voi ’ tehdä sitä näin.

Tämän kysymyksen ydin näyttää olevan: kun sinulla on kolme hyvin samanlaista verkkosivua muutamalla pienellä erolla, onko parempi kopioida nämä kolme sivua ja muokata kutakin tarpeen mukaan, tai rakentaa yhdelle sivulle logiikka renderoida sivu dynaamisesti minkä ”tilan mukaan” ”tarkastellaan.

Tietenkin olen JSF-kaveri ja pidän siitä, ja käytän ehdollista hahmonnusta.

Jos päätät käyttää ehdollista hahmonnusta, ratkaiset ongelman, mutta olet siirtänyt sivullesi jonkin liikelogiikan, joka saattaa tarvita jonkin verran miettiä.

Minulla ei henkilökohtaisesti olisi mitään ongelmaa ehdollisen hahmonnuksen käytössä, mutta haluaisin todella nähdä tilalogiikan siirtyneen taustapapuun, esimerkiksi: sijasta:

<h:output rendered="mode=2" value="Name: " />

Pidän:

<h:output rendered="#{myBean.advancedMode}" value="Name: " />

Missä papu käsittelee logiikka ja palauttaa tosi tai epätosi ohjaamaan elementin hahmonnusta.

Syynä on, että katselemassa oleva tila saattaa joutua hallitsemaan muutakin kuin vain tätä yhtä sivua, sen on ehkä jatkettava sitä jopa käyttäjän yksittäisen istunnon jälkeen tai tilat on vaihdettava kokonaan alaspäin. tiellä.

Tai voit hyväksyä, että jommallakummalla lähestymistavalla on potentiaalisia haittapuolia, ja kaikki haittapuolet näyttävät liittyvän tuskien lievittämiseen tiellä, ja suostut huolehtimaan siitä edelleen, kun joku näistä ”tiellä” itse asiassa, ja sitten tehdä parempia päätöksiä nyt, kun tiedetään enemmän siitä, miten vaatimukset voivat muuttua.