Obecný kód nebo kód snadno srozumitelný?

Šablony byste měli strukturovat podle stejných pravidel jako při programování. To v podstatě znamená extrahování běžných návrhových prvků do samostatných souborů, aby nedocházelo k duplikaci, a tím bylo dosaženo opětovně použitelného designu. To je pravidlo č. 1 ( DRY ) a metoda se v programovacím smyslu nazývá refaktoring.

Druhým pravidlem je, že byste se měli snažit jednoduchost a srozumitelnost. Mělo by být snadné pochopit rozložení a kam jít, když potřebujete změnit věci.

Dodržování prvního pravidla do písmene vede k těžkému rozkladu vašeho GUI na spoustu a mnoho malých úryvků, což ztěžuje pochopení toho, jak je rozložení vytvořeno. Musíte hodně lovit, abyste zjistili, kde jsou věci. To porušuje druhé pravidlo, takže musíte najít rovnováhu mezi těmito dvěma protiklady.

Ale nejlepším přístupem je najít řešení, které se tomuto problému úplně vyhne. Myslím, že v tomto případě byste měli zvážit úplně jednodušší přístup . Předpokládám, že se jedná o HTML a v GUI zmiňujete stavy „jednoduché a pokročilé“. Zvažovali jste, že vždy vygenerujete všechna pole a poté zpracováte logiku GUI v JavaScriptu? Jinými slovy, napište kód na straně klienta, který se za běhu skryje a zobrazí příslušná pole podle toho, v jakém režimu (stavu) se nachází?

To má také tu výhodu, že je možné přepnout režim na vyžádání bez zapojení serveru a nemusíte kompromitovat žádné z pravidel. Další skvělá věc je, že můžete nechat front-endové lidi proveďte tyto změny, aniž byste museli zapojovat back-end programátory, kteří obvykle nemají příliš velkou chuť trávit čas laděním a leštěním designu a interakce.

Komentáře

• Nesouhlasím s tím, že JS je jednodušší, proč? Většina mých spolupracovníků nezná ‚ čím dál víc webové rozhraní JS a Java, které vám umožňují ignorovat JS (Richfaces, GWT ). Téměř všechny společnosti se o JS nestarají (myslím, že mi byla položena jedna otázka JS ve všech společnostech, ve kterých jsem kdy pohovořil). Takže moji spolupracovníci by se tohoto kódu nedotkli a prostě by jej přepsali, kdyby měli změnit to. Váš nápad je dobrý, ale není realistický. plus proč ponechat část vaší logiky v java a část v JS? Myslím, že to je důvod, proč uložené procedury zemřely (a já jsem ke jim).
• @ 0101 Neřekl jsem ‚, že JS je jednodušší nebo těžší než cokoli jiného. Záleží na vašich dovednostech. S kompetentním html kodérem by to nebyl problém. Řekl jsem, že odložením problémů s grafickým uživatelským rozhraním na vrstvu grafického uživatelského rozhraní (tam, kam patří), často skončíte s mnohem jednodušším řešením. Je to proto, že GUI jsou vysoce dynamické a interaktivní, pro které je jazyk jako JS určen. Jen proto, že si myslíte, že “ žádné společnosti se nestarají o JS „, nedělá ‚ můj názor je méně platný.
• Myslím, že to tak je, otázkou je, co dělat v mé situaci, a vaše odpověď zní jako “ použít uložené procedury “ a to není platné, protože ho nikdo nepoužívá a bylo by těžké pochopit, proč bych je použil. ‚ ptám se, který způsob je pro budoucnost lepší, protože si ‚ nejsem 100% jistý, že moje volba je nejlepší (nyní nejlepší způsob je ignorovat otravného spolupracovníka).
• @ 0101: Práce s webem a HTML víceméně implikuje JavaScript (a HTTP a CSS a obrázky …), takže můžete ‚ Opravdu mě neobviňuji z toho, že jsem předpokládal, že existuje možnost JavaScript. ‚ se mi nelíbí ‚ žádám vás, abyste to napsali ve Swingu.
• “ Téměř všechny společnosti se nestarají o JS “ – vážně tomu věříte? Bohatá rozhraní na webu se již mnoho let pohybují na straně klienta. Cítím, že vám na této lodi chybí loď.

Bez vidění kódu mohu pouze spekulujte, ale domnívám se, že v tuto chvíli je váš kód „na hraně“.

Pro 2 nebo 3 režimy s omezeným počtem změn mezi těmito režimy máte to, co máte nyní je pravděpodobně v pořádku. Pokud by to však mělo být složitější, pak to zní, jako by to mělo být přepracováno na samostatné stránky.

Osobně dávám přednost snadno srozumitelnému kódu – je mnohem udržovatelnější, a to jak pro ostatní vývojáře, tak i pro vás, když musíte to vyzvednout znovu 6 měsíců dolů.

Nemá však smysl refaktorovat kód nyní , abyste vyřešili problém, který v budoucnu nemusí existovat . Říkáte, že nevíte, jak moc se požadavky změní – a to zahrnuje žádnou změnu – takže použití YAGNI (nebudete to potřebovat) teď nic nedělá.

Označte kód jako v budoucnu vyžadující pozornost, abyste na to nezapomněli, ale nyní to neměňte (a potenciálně nezlomte).

Komentáře

• + 1 – Pokud máte pochybnosti, snadno pochopíte. Nag v zadní části vaší mysli o tom, zda byste to měli učinit obecným, je přirozený způsob, jak vám říct, že byste neměli ‚ t.

Udělal jsem skoro totéž. Věřte mi, že po implementaci několika různých způsobů chování pro každý režim se „hlavní stránka“ stane téměř nečitelným nepořádkem. Pak byste viděli jen spoustu bloků řízení toku (krátce následovaný Matrixovým digitálním deštěm). Zjistil jsem, že odstraňuji některé bloky, abych získal jasný přehled o tom, co je v určitém režimu.

Takže „samostatné stránky“ jsou způsob, jak jít. Když to však uděláte, musíte “ boj „problém s duplikací kódu. To je místo, kde se váš kolega může mýlit, když navrhne sloučení. Bohužel jsem to také udělal.“ V podstatě to funguje, ale spotřebuje to hodně drahocenného času a nakonec špatným sloučením je „společný prostor“ stránek nesynchronizovaný a sloučení se stává skutečnou noční můrou. Máte tedy pravdu, když namítáte sloučení jako rozumné řešení.

Jak vidíte z mnoha odpovědí, správným přístupem je extrakce skutečně „běžných“ částí do externích entit (fragmenty stránky JSP, fragmenty JSF, cokoli) a zahrnout je na tyto stránky.

Komentáře

• skutečný problém, že běžným kódem jsou jen ovládací prvky h: inputText + h: outputText pro jedno pole. Cítím, že nemá cenu s tím bojovat. plus tato stránka může zemřít, protože není opravdu funkční, kvůli režimům a matoucí i pro ostatní vývojáře (z pohledu uživatele).
• Takže problém je ve skutečnosti, kdy provést přechod. Po každé změně musíte rozdělení znovu zvážit. Když začne být stránka špinavá – rozdělte ji. Myslím, že váš spolupracovník bude také pohodlnější, pokud považujete jeho nápad za dobrý, ale zatím se ho neoplatí realizovat.

Duplikace kódu není nikdy dobrá věc. To znamená, že v reálném životě je přijatelné malé množství duplikovaných ne více než dvakrát – je lepší být o tom pragmatický než náboženský. Ve vašem případě to zní jako větší množství kódu a 3 místa, takže je to mírně nad mým osobním prahem. Proto se opírám o obecnou verzi.A v každém případě, pokud to nyní funguje, není třeba se jej dotýkat pouze z teoretických důvodů.

OTOH, když říkáte, že v budoucnu může mezi stránkami existovat více rozdílů, mohlo by to znamenat, že v určitém okamžiku se stává ekonomičtější přejít na samostatné stránky (přičemž se snažíme minimalizovat duplikaci mezi nimi tím, že budeme co nejvíce extrahovat společné prvky). Před každou budoucí změnou tedy přehodnoťte situaci.

Vypadá to jako JSF. Každé vykreslení = „…“ v podstatě znamená, že máte v kódu if, což způsobuje další složitost.

Udělal jsem totéž, protože „je to stejná stránka, ale s několika rozdíly zde a tam „a jednoduše řečeno, z dlouhodobého hlediska nefunguje , protože není stejnou stránku a budete muset dělat stále komplikovanější triky, aby to fungovalo správně, což bude zbytečně těžké udržovat.

Pokud používáte JSF s facelety místo JSP (které Pokud byste mohli), můžete vytvořit XML fragmenty odpovídající bloku stránky, které pak můžete v případě potřeby zahrnout. Tím získáte modularitu a stále vám umožní znovu použít obsah napříč stránkami.

Poslouchejte svého spolupracovníka. Má pravdu.

Komentáře

• viz moje úprava
• @ 0101, měl jsem podezření přesně tohle. Nedělejte to, je to cesta k šílenství – s největší pravděpodobností pro vás – a Určitě pro budoucí správce.
• Skutečným problémem je, že moje cesta je nejlepší. kdybych udělal 3 stránky, mohl by někdo změnit jen jednu ze stránek a nemyslet na ostatní. Chtěl bych svou verzi jako budoucího správce.
• Myslím, že můj kód nutí budoucí správce myslet na další případy. Pokud jste byli novým programátorem projektu a v debuggeru zjistili, že potřebujete změnit kód v baseFormBasic.xhtml, změnili byste jej také v baseFormAdv a baseFormSpec?
• @ 0101, proč se ptát, co je nejlepší, chcete-li pouze potvrdit svůj předem vytvořený názor?

Existuje šance vygenerovat stránku pomocí kódu? V tomto případě, co třeba něco jako:

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

A v kódu pro vykreslení stránky

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

Nebo ve stylu OOP:

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

Komentáře

• ne, nedojde ke změně . Kdybych to udělal, byl bych ukřižován. plus to vytváří naprosto stejný problém. if == vykreslen.
• Nejedná se o přesný problém, protože extrahuje logiku stránky. Dělat jen jeden úkol, místo dvou.
• Možná, ale cítím to samé. můj důvod je, že zobrazování polí je jen jedna věc, která se liší, existuje také jiné umístění a někdy popisky. plus jeho programování webu, takže ‚ to nedělám takto.

modální kód se může jen zhoršit . Klasifikujte a rozhodněte se hned na začátku a rozdělte se na čištění implementací bez režimů.

Komentáře

• isn ‚ t duplikace kódu nejhorší? celý kód by měl být vždy synchronizován navzájem (pokud měníte jednoduché, nezapomeňte změnit předem a co když zapomenete?)
• izolovat běžný kód v podprogramech, funkcích, pomocných / základních třídách atd. ; v OOP je modální kód známkou chybějících tříd …

Podstata této otázky Zdá se, že: pokud máte tři velmi podobné webové stránky s několika malými rozdíly, je lepší tyto tři stránky duplikovat a podle potřeby je upravit, nebo integrovat do jedné stránky logiku pro dynamické vykreslení stránky podle toho, jaký režim „je prohlíženo.

Pro záznam, jsem člověk JSF a líbí se mi to a využívám podmíněné vykreslování.

Pokud se rozhodnete mít tři stránky, existuje riziko, že v důsledku změn nemusí správce tuto stránku správně použít na všechny tři stránky.

Pokud se rozhodnete pro použití podmíněného vykreslování, vyřešíte tento problém, ale na svou stránku jste přesunuli nějakou obchodní logiku, která by mohla vyžadovat určité zamyšlení.

Osobně bych neměl problém s použitím podmíněného vykreslování, ale opravdu bych si přál, aby se logika režimu přesunula na doprovodnou fazoli, např .: místo:

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

Líbí se mi:

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

Kde fazole zpracovává logika a vrátí hodnotu true nebo false k ovládání vykreslení prvku.

Důvodem je, že zobrazovaný režim může vyžadovat ovládání více než jen této jedné stránky, může být nutné jej přetrvávat i nad jedinou relací uživatele, nebo budete muset režimy zcela změnit silnice.

Nebo můžete připustit, že oba přístupy mají potenciální nevýhody, a zdá se, že všechny tyto nevýhody se týkají zmírnění bolesti po silnici, a souhlasíte s tím, že si s tím budete dělat starosti, když jedna z těch věcí „po silnici“ ve skutečnosti přijít a poté učinit lepší rozhodnutí, když už je známo více o tom, jak se mohou požadavky změnit.