Kod ogólny lub kod łatwy do zrozumienia?

Struktury szablonów powinny być tworzone przy użyciu tych samych reguł, co podczas programowania. Zasadniczo oznacza to wyodrębnienie wspólnych elementów projektu do oddzielnych plików, aby uniknąć powielania, a tym samym uzyskać projekt, który można wielokrotnie wykorzystać. To jest reguła nr 1 ( DRY ), a metoda nazywa się refaktoryzacją w terminach programowania.

Druga zasada mówi, że powinieneś dążyć do prostota i przejrzystość. Powinno być łatwe do zrozumienia układu i miejsca, w którym należy się udać, kiedy trzeba coś zmienić.

Postępowanie zgodnie z pierwszą zasadą co do litery prowadzi do ciężkiego rozkładu twojego GUI na wiele, wiele małych fragmentów, co może utrudniać zrozumienie, jak tworzony jest układ. Musisz dużo polować, aby dowiedzieć się, gdzie są rzeczy. Narusza to drugą zasadę, więc musisz znaleźć równowagę między tymi dwoma przeciwieństwami.

Ale najlepszym podejściem jest znalezienie rozwiązania, które całkowicie pozwoli uniknąć tego problemu. Myślę, że w tym przypadku należy rozważyć w ogóle prostsze podejście . Zakładam, że to HTML i wspominasz o stanach „prostych i zaawansowanych” w GUI. Czy rozważałeś zawsze generowanie wszystkich pól, a następnie obsługę logiki GUI w JavaScript? Innymi słowy, napisz kod po stronie klienta, który ukrywa i wyświetla odpowiednie pola w locie, w zależności od tego, w jakim trybie (stanie) się znajduje?

Ma to również tę zaletę, że można przełączać tryb na żądanie bez angażowania serwera i nie musisz naruszać żadnej z zasad. Kolejną wspaniałą rzeczą jest to, że możesz pozwolić użytkownikom wprowadzać te zmiany bez konieczności angażowania programistów zaplecza, którzy zwykle nie są przesadnie zainteresowani spędzaniem czasu na poprawianiu i dopracowywaniu projektu i interakcji.

Komentarze

• Nie zgadzam się z tym, że JS jest prostszy, dlaczego? większość moich współpracowników nie ' nie zna coraz większej liczby frameworków internetowych JS i Java pozwala ignorować JS (Richfaces, GWT Prawie wszystkie firmy nie przejmują się JS (wydaje mi się, że zadano mi jedno pytanie JS we wszystkich firmach, w których kiedykolwiek rozmawiałem). Więc moi współpracownicy nie dotykaliby tego kodu i po prostu przepisywaliby go, gdyby mieli aby to zmienić. Twój pomysł jest dobry, ale nie jest realistyczny. Poza tym po co trzymać część swojej logiki w Javie, a część w JS? Myślę, że to jest powód, dla którego procedury składowane umarły (a ja ke je).
• @ 0101 Nie ' nie powiedziałem, że JS jest prostszy lub trudniejszy niż cokolwiek innego. To zależy od twoich umiejętności. Z kompetentnym koderem html nie byłoby to problemem. Powiedziałem, że odkładając problemy z GUI na warstwę GUI (gdzie należy), często kończy się o wiele prostszym rozwiązaniem. Dzieje się tak, ponieważ GUI są wysoce dynamiczne i interaktywne, do czego stworzony jest język taki jak JS. Tylko dlatego, że uważasz, że ” żadna firma nie przejmuje się JS „, nie ' nie sprawia, że mój punkt widzenia jest mniej ważny.
• Myślę, że tak jest, pytanie brzmi, co zrobić w mojej sytuacji, a Twoja odpowiedź brzmi: ” użyj procedur składowanych ” i to nie jest poprawne, ponieważ nikt go nie używa i trudno byłoby zrozumieć, dlaczego miałbym ich używać. Pytam ', który sposób jest lepszy na przyszłość, ponieważ ' nie jestem w 100% pewien, czy mój wybór jest najlepszy (teraz Najlepszym sposobem jest zignorowanie irytującego współpracownika).
• @ 0101: Praca z siecią i HTML mniej lub bardziej implikuje JavaScript (oraz HTTP, CSS i obrazy …), więc możesz ' Naprawdę winię mnie za założenie, że JavaScript jest opcją. ' nie tak, jak ja ' proszę Cię o napisanie tego w Swingu.
• ” Prawie wszystkie firmy nie przejmują się JS ” – czy naprawdę w to wierzysz? Bogate interfejsy w sieci od wielu lat podążają w kierunku klienta. Wydaje mi się, że brakuje Ci tej łodzi.

Nie widząc kodu, mogę tylko spekulować, ale zgaduję, że w tej chwili twój kod jest „na krawędzi”.

Dla 2 lub 3 trybów z ograniczoną liczbą zmian między tymi trybami, co masz teraz jest prawdopodobnie OK. Jednak gdyby było to bardziej skomplikowane, to brzmi, jakby należało zamienić je na osobne strony.

Osobiście wolę łatwy do zrozumienia kod – jest o wiele łatwiejszy w utrzymaniu, zarówno dla innych programistów, jak i dla ciebie, musisz to powtórzyć za 6 miesięcy.

Jednak nie ma sensu refaktoryzować kodu teraz w celu rozwiązania problemu, który może nie istnieć w przyszłości . Mówisz, że nie wiesz, jak bardzo zmienią się wymagania – i to obejmuje brak zmian – więc stosowanie YAGNI (You Ain „t Gonna Need It) nie rób nic teraz.

Oznacz kod jako wymagające uwagi w przyszłości, więc nie zapomnij o tym, ale nie zmieniaj (i potencjalnie psuj) tego teraz.

Komentarze

• + 1 – Jeśli masz wątpliwości, postaraj się to łatwo zrozumieć. Z tyłu głowy myślisz o tym, czy powinieneś traktować to jako rodzajowe, jest naturalny sposób na powiedzenie, że nie powinieneś ' t.

Zrobiłem prawie to samo. Uwierz mi, po zaimplementowaniu kilku różnych zachowań dla każdego trybu, „strona główna” staje się bałaganem prawie niemożliwym do odczytania. Zobaczysz wtedy tylko kilka bloków przepływu sterowania (wkrótce po nich pojawi się cyfrowy deszcz Matrix). Okazało się, że usuwam niektóre bloki tylko po to, aby uzyskać jasny obraz tego, co jest w określonym trybie.

Tak więc „oddzielne strony” to najlepszy sposób. Jednak kiedy to zrobisz, musisz ” fight „problem z powielaniem kodu. W tym miejscu twoja koleżanka może się mylić, sugerując fuzje. Niestety, ja też to zrobiłem. Zasadniczo działa, ale pochłania dużo cennego czasu i ostatecznie przez słabe scalanie „wspólny obszar” stron nie jest zsynchronizowany i scalanie staje się prawdziwym koszmarem. Masz więc rację, sprzeciwiając się scalaniu jako rozsądnemu rozwiązaniu.

Jak widać z wielu odpowiedzi, właściwym podejściem jest wyodrębnienie naprawdę „typowych” części do jednostek zewnętrznych (fragmenty stron JSP, fragmenty JSF, cokolwiek) i umieść je na tych stronach.

Komentarze

• prawdziwym problemem jest to, że wspólny kod to tylko kontrolki h: inputText + h: outputText dla jedno pole. Uważam, że nie warto z tym walczyć. plus ta strona może umrzeć, ponieważ nie jest naprawdę funkcjonalna, z powodu trybów i jest myląca nawet dla innych programistów (z punktu widzenia użytkownika).
• Tak więc problem naprawdę polega na tym, kiedy dokonać przejścia. Musisz ponownie rozważyć podział po każdej modyfikacji. Kiedy strona zacznie być nieuporządkowana – podziel ją. Myślę, że twój współpracownik również poczuje się bardziej komfortowo, jeśli uznasz jego pomysł za dobry, ale nie warto go jeszcze wdrażać.

To wygląda jak JSF. Każdy wyrenderowany = „…” zasadniczo oznacza, że w kodzie znajduje się if, co powoduje dodatkową złożoność.

Zrobiłem to samo, ponieważ „jest to ta sama strona, z kilkoma różnicami i tam „i mówiąc najprościej, nie działa na dłuższą metę, ponieważ nie jest” t ta sama strona i będziesz musiał wykonywać coraz bardziej wyszukane sztuczki, aby działała poprawnie, co spowoduje, że będzie niepotrzebnie trudna w utrzymaniu.

Jeśli używasz JSF z faceletami zamiast JSP (który jeśli możesz), możesz zbudować fragmenty XML odpowiadające blokowi strony, które możesz następnie dołączyć w razie potrzeby. To kupi modułowość i nadal umożliwi ponowne wykorzystanie treści na różnych stronach.

Posłuchaj swojego współpracownika. Ma rację.

Komentarze

• zobacz moją edycję
• @ 0101, podejrzewałem dokładnie to. Nie ' nie rób tego, to droga do szaleństwa – najprawdopodobniej dla ciebie – z pewnością dla przyszłych opiekunów.
• prawdziwy problem polega na tym, że moja droga jest najlepsza. gdybym zrobił 3 strony, ktoś mógłby zmienić tylko jedną z nich i nie myśleć o innych. Chciałbym moją wersję jako przyszłego opiekuna.
• Myślę, że mój kod sprawia, że przyszły opiekun myśli o innych przypadkach. Gdybyś był nowym programistą projektu i w debugerze stwierdziłeś, że musisz zmienić kod w baseFormBasic.xhtml, czy zmieniłbyś to również w baseFormAdv i baseFormSpec?
• @ 0101, po co pytać, co jest najlepsze, jeśli chcesz tylko potwierdzić swoją z góry przyjętą opinię?

Czy jest szansa na wygenerowanie strony używając kodu? W tym przypadku co powiesz na coś takiego:

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

A w kodzie renderowania strony

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

Lub w stylu OOP:

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

Komentarze

• nie, nie ma zmian . Gdybym to zrobił, zostałbym ukrzyżowany. plus stwarza dokładnie ten sam problem. if == renderowane.
• To nie jest dokładny problem, ponieważ wyodrębnia logikę strony. Robienie tylko jednego zadania zamiast dwóch.
• Może, ale czuję to samo. moim powodem jest to, że pokazywanie pól to tylko jedna rzecz, która się różni, jest też inne rozmieszczenie i czasami etykiety. plus to programowanie internetowe, więc mogę ' zrobić to w ten sposób.

kod modalny może się tylko pogorszyć . Sklasyfikuj i zdecyduj raz na początku i przejdź do czystych implementacji bez trybów.

Komentarze

• isn ' t? cały kod powinien być zawsze zsynchronizowany ze sobą (jeśli zmieniasz prostą, pamiętaj o zmianie z wyprzedzeniem, a co jeśli zapomnisz?)
• wyodrębnij wspólny kod w podprogramach, funkcjach, klasach pomocniczych / bazowych itp. ; w OOP kod modalny wskazuje na brakujące klasy …

Istota tego pytania wygląda na to, że: gdy masz trzy bardzo podobne strony internetowe z kilkoma drobnymi różnicami, lepiej jest powielić te trzy strony i zmodyfikować każdą w razie potrzeby, czy wbudować w jedną stronę logikę dynamicznego renderowania strony zgodnie z trybem „ jest oglądany.

Dla przypomnienia, jestem facetem od JSF i podoba mi się to i korzystam z renderowania warunkowego.

Jeśli zdecydujesz się na trzy strony, istnieje ryzyko, że po wprowadzeniu zmian opiekun może nie zastosować ich poprawnie do wszystkich trzech stron.

Jeśli zdecydujesz się na renderowanie warunkowe, rozwiązujesz ten problem, ale przeniosłeś na stronę pewną logikę biznesową, która może wymagać przemyślenia.

Osobiście nie miałbym problemu z użyciem renderowania warunkowego, ale naprawdę chciałbym, aby logika trybu została przeniesiona do komponentu bean, np .: zamiast:

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

Lubię:

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

Gdzie ziarno obsługuje logika i zwraca wartość true lub false, aby kontrolować renderowanie elementu.

Przyczyną jest to, że przeglądany tryb może wymagać kontrolowania więcej niż tylko tej jednej strony, może wymagać utrzymywania go nawet poza pojedynczą sesją użytkownika lub może być konieczna całkowita zmiana trybów w dół Droga.

Lub możesz zaakceptować, że którekolwiek z tych podejść ma potencjalne wady, a wszystkie wady wydają się dotyczyć łagodzenia bólu na drodze i zgodzić się martwić o to dalej, gdy jedna z tych rzeczy „w przyszłości” faktycznie pojawiają się, a następnie podejmują lepsze decyzje teraz, gdy faktycznie wiadomo więcej o tym, jak wymagania mogą się zmienić.