Általános kód vagy könnyen érthető kód?

A sablonokat ugyanazokkal a szabályokkal kell felépíteni, mint a programozáskor. Ez lényegében azt jelenti, hogy a közös tervezési elemeket külön fájlokba vonják ki, hogy elkerüljék a párhuzamosságot, és ezáltal többször felhasználható dizájnt érjenek el. Ez az 1. szabály ( SZÁRAZ) és a módszert programozási szempontból refaktorálásnak hívják.

A második szabály az, hogy törekednie kell egyszerűség és egyértelműség. Könnyen meg kell értenie az elrendezést és azt, hogy merre kell mennie, mikor kell változtatnia a dolgokon.

A betű első szabályának betartása a gui sok-sok apró részletre bomlásához vezet, ami megnehezíti az elrendezés létrehozásának megértését. Sokat kell vadászni a hely körül. Ez sérti a második szabályt, ezért meg kell találnia az egyensúlyt e két ellentét között.

De a legjobb megoldás az, ha olyan megoldást találunk, amely ezt a kérdést teljesen elkerüli. Úgy gondolom, hogy ebben az esetben teljesen egyszerűbb megközelítést kell fontolnia . Feltételezem, hogy ez HTML, és az “egyszerű és haladó” állapotokat említi a grafikus felhasználói felületen. Fontolgatta-e mindig az összes mezők létrehozását, majd a GUI logikájának kezelését a JavaScript-ben? Más szavakkal, írjon kliensoldali kódot, amely menet közben elrejti és megmutatja a releváns mezőket, attól függően, hogy melyik módban (állapotban) van?

Ennek az az előnye is van, hogy igény szerint módot válthat a szerver bevonása nélkül, és nem kell kompromittálnia egyik szabályt sem. Egy másik nagyszerű dolog, hogy hagyhatja a front-end srácokat hajtsa végre ezeket a változtatásokat anélkül, hogy be kellene vonni a háttér-programozókat, akik általában nem olyan szívesen töltenek időt a tervezés és az interakció finomításával és csiszolásával.

Megjegyzések

• Nem értek egyet azzal, hogy a JS egyszerűbb, miért? Munkatársam többsége nem tudja, hogy

A kód látása nélkül csak spekulálok, de feltételezhetem, hogy pillanatnyilag a kódod „szélén van”.

2 vagy 3 mód esetén, korlátozott számú változtatással a módok között, most valószínűleg rendben van. Ha mégis bonyolultabb lenne, akkor úgy hangzik, mintha külön oldalakra kellene átdolgozni.

Személy szerint inkább a könnyen érthető kódot szeretem – sokkal karbantarthatóbb, mind más fejlesztők, mind Ön számára, amikor 6 hónappal újra fel kell venned.

Azonban nincs értelme a kódot átdolgozni most egy olyan probléma megoldására, amely a jövőben esetleg nem is létezik . Azt mondod, hogy nem tudod, mennyire változnak a követelmények – és ez nem tartalmaz változást -, ezért a YAGNI (neked nem lesz szükséged) alkalmazása most semmit sem tesz.

Jelöld meg a kódot figyelmet igényel a jövőben, így nem felejti el, de most nem változtatja meg (és esetleg nem is törheti meg).

Megjegyzések

• + 1 – Ha kétségei merülnek fel, könnyen érthető. A fejed hátsó részén felmerülő nyaggatás arról, hogy generikussá tennéd-e, természetszerű módszer arra, hogy elmondd neked, hogy nem kell ‘ t.

Nagyjából ugyanazt tettem. Hidd el, miután az egyes módokhoz kevés különböző viselkedést alkalmaztak, a “főoldal” szinte lehetetlenné válik. Ekkor csak egy csomó vezérlő áramlási blokkot lát (rövid időn belül Matrix digitális eső követi). Rájöttem, hogy eltávolítok néhány blokkot csak azért, hogy tiszta képet kapjak arról, hogy mi van egy bizonyos módban.

Tehát a „külön oldalak” a helyes út. Azonban amikor ezt megteszed, akkor küzdelem “kódduplikációs probléma. Ebben az esetben lehet, hogy munkatársa téved, mert egyesítéseket javasol. Sajnos, én is ezt tettem. Alapvetően működik, de sok drága időt emészt fel, és végül az oldalak “közös területe” gyenge összeolvadása miatt nincs szinkronban, és az összevonás igazi rémálommá válik. Tehát igazad van, ha ésszerű megoldásként kifogásolod az egyesítést.

Mint sok válaszból kiderül, a helyes megközelítés az, hogy valóban „közös” részeket vonszol ki külső entitásokból (JSP oldaltöredékek, JSF-kivonatok, bármi), és vegye fel azokat az oldalakra.

Megjegyzések

• az igazi probléma, hogy a közös kód csak a h: inputText + h: outputText for egyetlen mező. Úgy érzem, nem éri meg küzdeni ellene. plusz ez az oldal meghalhat, mivel nem igazán működik, a módok miatt, és még a többi fejlesztőt is zavaró (felhasználói szempontból).
• Tehát valóban az a probléma, hogy mikor kell elvégezni az átállást. Minden módosítás után meg kell fontolni a felosztást. Amikor az oldal rendetlen lesz – ossza szét. Úgy gondolom, hogy munkatársa is kényelmesebb lesz, ha ötletét jónak tartja, de még nem érdemes megvalósítani.

A kód másolása gyakorlatilag soha nem jó dolog. Ennek ellenére egy kis mennyiség, amely nem több, mint kétszer többszörözhető, elfogadható a való életben – jobb, ha gyakorlati, mint vallásos. A te esetedben nagyobb mennyiségű kódnak és 3 helynek tűnik, tehát kissé meghaladja a személyes küszöböt. Így az általános verzió felé hajlok.Mindenesetre, ha most működik, akkor csak elméleti okokból nincs szükség hozzá.

OTOH, amikor azt állítja, hogy a jövőben több különbség lehet az oldalak között, ez azt jelentheti, hogy egy bizonyos ponton gazdaságosabbá válik a különálló oldalakra váltás (miközben arra törekszünk, hogy a közösségek minél szélesebb körű kitermelésével minimalizáljuk a köztük lévő duplikációt). Ezért értékelje át a helyzetet minden jövőbeli változás előtt.

Ez JSF-nek tűnik. Mindegyik renderelt = “…” lényegében azt jelenti, hogy van egy if-je a kódban, ami további összetettséget okoz.

Ugyanezt tettem, mert “ugyanaz az oldal, itt csak néhány különbség van. és ott “és nagyon egyszerűen fogalmazva: hosszú távon nem működik , mert nem” t ugyanazon az oldalon, és egyre bonyolultabb trükköket kell végrehajtania annak megfelelő működéséhez, ami feleslegesen nehéz fenntartani.

Ha a JSF-t facelettel használja a JSP helyett (amit Ön ha lehet), akkor az oldal blokkjának megfelelő XML-töredékeket készíthet, amelyeket szükség esetén felvehet. Ez modularitást jelent, és továbbra is lehetővé teszi a tartalom újrafelhasználását az oldalakon. Hallgassa meg munkatársát. Igaza van.

Megjegyzések

• kérem, olvassa el a szerkesztésemet.
• @ 0101, gyanítottam pontosan ezt. Don ‘ ne csináld, ez az őrülethez vezető út – valószínűleg neked – és minden bizonnyal a jövőbeli fenntartók számára.
• az igazi probléma az, hogy az én utam a legjobb. ha 3 oldalt csináltam, akkor valaki csak az egyik oldalt megváltoztathatta, és nem a többire gondolt. Szeretném, ha jövőbeni karbantartóként használnám a verziómat.
• Úgy gondolom, hogy a kódom más esetekre készteti a jövőbeni karbantartást. Ha Ön új programozó lenne a projektben, és a hibakeresőben azt találná, hogy módosítania kell a kódot az baseFormBasic.xhtml fájlban, akkor a baseFormAdv és a baseFormSpec fájlokban is módosítaná?
• @ 0101, miért kérdezné meg, mi a legjobb, ha csak meg akarja erősíteni az előzetes véleményét?

Van-e esély az oldal létrehozására kódot használ? Ebben az esetben mi a helyzet a következőkkel:

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

És az oldalmegjelenítő kódban

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

Vagy OOP stílusban:

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

megjegyzések

• nem, nincs változás . Keresztre feszítenék, ha megtenném. plusz pontosan ugyanezt a problémát hozza létre. if == renderelt.
• Ez nem a pontos probléma, mivel kivonja az oldallogikát. Két feladat helyett csak egy feladatot végez.
• lehet, de én is ugyanezt érzem. az okom az, hogy a mezők megjelenítése csak egy dolog, amely különbözik, eltérő elhelyezés és néha címkék is vannak. plusz a webes programozás, így ‘ nem tudom így csinálni.

A kérdés lényege Úgy tűnik: ha három nagyon hasonló weboldalad van, néhány kisebb különbséggel, akkor jobb-e ezt a három oldalt lemásolni és szükség szerint módosítani mindegyiket, vagy egyetlen oldalba építeni a logikát az oldal dinamikus megjelenítéséhez az adott “mód” szerint “megtekintése folyamatban van.

Megjegyzendő, hogy JSF srác vagyok, és tetszik, és feltételes megjelenítést alkalmazok.

Ha három oldalt választ, akkor fennáll annak a veszélye, hogy a változások következtében a karbantartó ezt nem alkalmazhatja helyesen mindhárom oldalon.

Ha a feltételes megjelenítés mellett dönt, akkor megoldja ezt a problémát, de az üzleti logikát áthelyezte az oldalára, amelyet elgondolkodásra lehet szükség.

Nekem személy szerint nem lenne problémám a feltételes megjelenítés használatával, de nagyon szeretném, ha a módlogika egy háttérbabra kerülne, például: helyett:

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

Tetszik:

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

Ahol a bab kezeli logika, és igaz vagy hamis értéket ad vissza az elem megjelenítésének vezérléséhez.

Ennek oka az lehet, hogy a megtekintett módnak nem csak ezt az egy oldalt kell irányítania, akár a felhasználó egyetlen munkamenetén túl is fenn kell tartania, vagy teljesen módosítania kell a módokat a út.

Vagy elfogadhatja, hogy bármelyik megközelítésnek vannak hátrányai, és úgy tűnik, hogy az összes hátrány az út mentén jelentkező fájdalmak enyhítésére vonatkozik, és beleegyezik abba, hogy tovább aggódjon, ha az egyik ilyen „úton van” valójában előjönnek, majd jobb döntéseket hoznak most, amikor többet tudnak arról, hogyan változhatnak a követelmények.