Jestem samoukiem, początkującym programistą, więc przepraszam, jeśli nie rozumiem żargonu programisty.
Pracuję nad projektem, w którym dostarczam stale aktualizowane dane programistom, którzy zasadniczo stworzą narzędzie do generowania raportów z zapytań dotyczących danych.
Wydaje się, że wszyscy zaangażowani myślą że muszą na stałe zakodować wartości danych (nie schemat, ale same domeny / wartości) w programie generującym raporty.
Na przykład załóżmy, że raportowaliśmy o personelu; raport zostałby podzielony na kategorie, z nagłówkiem dla każdego działu, a następnie pod każdym nagłówkiem będą podtytuły tytułów stanowisk, a pod każdym podtytułem będzie lista pracowników. Deweloperzy chcą zakodować na stałe działy i tytuły stanowisk. z drugiej strony, myślę, że mogą / mogliby odpytywać te rzeczy w czasie wykonywania, sortować rekordy według nich i generować nagłówki raportów dynamicznie na podstawie wartości es tam są.
Ponieważ lista potencjalnych wartości będzie się zmieniać w czasie (np. wydziały zostaną utworzone / zmienione, zostaną dodane nowe stanowiska), kod będzie wymagał ciągłej aktualizacji. Wydaje mi się, że moglibyśmy pominąć czynności związane z konserwacją kodu i dynamicznie organizować raporty.
Ponieważ nie jestem programistą, zastanawiam się, czego mi brakuje. Jakie korzyści może przynieść zakodowanie wartości na stałe w takim narzędziu? Czy zazwyczaj tak powstają programy?
Komentarze
- możliwy duplikat Usuwanie na stałe zakodowanych wartości i projekt obronny a YAGNI
- Czy w raporcie znajdują się karty krzyżowe, co oznacza, że wartości w wierszach powinny pojawiać się jako kolumny?
- @Brendan – Jeśli na stałe zakodujesz wartości w raporcie , ' będziesz musiał zmienić listę w DWÓCH miejscach (źródło danych i raport), natomiast jeśli raport jest dynamiczny, wystarczy zmienić go tylko w jednym miejscu (raporcie) .
- @Brendan dlaczego miałbyś skończyć z trzema lokalizacjami? Być może moje rozumienie jest niepoprawne, ale ' wyobrażam sobie zapytanie sql do pobrania danych z bazy danych, aplikacja będzie agregować / grupować zwrócone wartości, np. Według działu. Jeśli ' chcesz mieć narzut wielu zapytań dotyczących bazy danych, możesz wybrać różne działy / tytuły ról, jeśli naprawdę chcesz. W żadnym momencie dane nie istnieją w więcej niż jednej lokalizacji – raport jest oparty na danych.
- @Brendan Nie zgadzam się również z twoją definicją, że znajdują się w jednym miejscu – jak to opisujesz ' w wielu lokalizacjach, rozproszonych w kodzie źródłowym.
Odpowiedź
Wikipedia:
Trudne kodowanie (także kodowanie na stałe lub kodowanie na stałe) odnosi się do praktyki tworzenia oprogramowania polegającej na osadzaniu tego, co może, być może tylko z perspektywy czasu, być uważane za dane wejściowe lub konfiguracyjne bezpośrednio w kodzie źródłowym programu lub innego obiektu wykonywalnego, lub ustalone formatowanie danych, zamiast pobierać te dane ze źródeł zewnętrznych lub generować dane lub formatować w samym programie przy użyciu podanych danych wejściowych.
Twarde kodowanie jest uważane za antywzór .
Uważany za plik n Anty-wzorzec, sztywne kodowanie wymaga zmiany kodu źródłowego programu za każdym razem, gdy zmieniają się dane wejściowe lub żądany format, kiedy może być wygodniej dla użytkownika końcowego zmienić szczegóły w jakiś sposób poza programem.
Czasami nie można tego uniknąć, ale powinno to być tymczasowe.
Twarde kodowanie jest często wymagane. Programiści mogą nie mieć opracowanego rozwiązania dynamicznego interfejsu użytkownika dla użytkownika końcowego, ale nadal muszą dostarczyć funkcję lub wydać program. Zwykle jest to tymczasowe, ale w krótkim okresie rozwiązuje presję związaną z dostarczeniem kodu. Później wykonuje się softcoding, aby umożliwić użytkownikowi przekazywanie parametrów, które dają użytkownikowi końcowemu sposób na modyfikację wyników lub wyniku.
- Hardcoding wiadomości utrudnia umiędzynarodowienie programu.
- Hardkodowane ścieżki utrudniają dostosowanie do innej lokalizacji.
Jedyną zaletą kodowania na stałe wydaje się być szybkie dostarczanie kodu.
Komentarze
- OK , ale ” jedyna zaleta ” jest często niezwykle ważna. Decyzje projektowe w programowaniu często dotyczą kompromisu między zabezpieczeniem w przyszłości a szybką dostawą teraz, i jako takie, twarde kodowanie może być całkowicie akceptowalnym wyborem. Czasami nie twarde kodowanie jest złym wyborem projektowym.
- -1 Nie ' nie sądzę, że jest to pomocna odpowiedź. Zasadniczo stwierdza, że ' umieszczanie wartości w kodzie źródłowym w niewłaściwy sposób ' jest niewłaściwe. Myślę, że OP potrzebuje wskazówek, kiedy rzeczy mogą należeć do kodu źródłowego, a zatem wykraczać poza definicję Wikipedii.
- Twarde kodowanie powinno być istotną częścią twojego procesu i biorąc pod uwagę, że anty-wzorzec jest przestarzały w era mikrousług, z samouczkiem Angular Tour of Heroes będącym głośnym przykładem ogromnego software houseu, bezpośrednio umieszczającego lub nawet upoważniającego jako etap pośredni. Co więcej, kiedy przechodzisz do danych dynamicznych, nadal powinieneś zachować pewne zakodowane dane jako rozwiązanie awaryjne, być może kontrolowane przez zmienną środowiskową lub nawet logiczne przełączanie samego kodu, aby błędy i problemy z bezpieczeństwem można było odpowiednio odizolować linii.
Odpowiedź
Naprawdę? Brak możliwych prawidłowych przypadków użycia?
Chociaż zgadzam się, że na stałe kodowanie to generalnie anty-wzorzec lub przynajmniej bardzo zły zapach kodu , jest wiele przypadków, w których ma to sens. Oto kilka.
-
Prostota / YAGNI .
-
Rzeczywiste stałe, które w rzeczywistości nigdy się nie zmieniają.
tzn. stała reprezentuje naturalną lub biznesowa stała, albo przybliżona jedna. (np. 0, PI, …)
-
Ograniczenia środowiskowe dotyczące sprzętu lub oprogramowania
W oprogramowaniu wbudowanym przychodzą na myśl ograniczenia pamięci i alokacji.
-
Bezpieczne oprogramowanie
Te wartości nie są dostępne i / lub łatwe do odkodowania lub odtworzenia kodu źródłowego, np. tokeny kryptograficzne i sole. (Zwróć uwagę, że przechowywanie ich na stałe ma również oczywiste wady …)
-
Wygenerowany kod
Twój preprocesor lub generator jest konfigurowalny, ale wypluwa kod z wartościami zakodowanymi na stałe. Nie jest to niezwykłe w przypadku kodu, który opiera się na silnikach reguł lub jeśli masz architekturę opartą na modelach.
-
Kod o wysokiej wydajności
W pewnym sensie jest to ” wygenerowany ” kod , chociaż jeszcze bardziej wyspecjalizowany. na przykład z góry ustalona tabela przeglądowa / obliczeniowa z mało prawdopodobnymi zmianami. Na przykład nie jest to niczym niezwykłym w programowaniu grafiki.
-
Konfiguracja i rozwiązania awaryjne
Zarówno w Twoim rzeczywistym kodzie, jak iw plikach konfiguracyjnych, prawdopodobnie będziesz mieć wartości konfiguracyjne i błędy w kilku przypadkach (gdy konfiguracja jest niedostępna, gdy komponent nie odpowiada oczekiwane itp …). Mimo to ogólnie najlepiej jest trzymać go poza kodem i sprawdzać, ale mogą się zdarzyć przypadki, w których absolutnie chcesz mieć określoną wartość / reakcję na określone działanie / problem / sytuację.
-
I prawdopodobnie jeszcze kilka …
Nadal jest Anti-Pattern ? Więc Nadmierna inżynieria ! Chodzi o oczekiwaną żywotność twojego oprogramowania !!
Nie mówię o tym są wszystkie ważne powody i generalnie wzbraniałbym się przed wartościami zakodowanymi na stałe. Ale niektórzy mogą z łatwością dostać przepustkę z ważnych powodów.
I nie przeoczaj pierwszego, dotyczącego prostoty / YAGNI albo myśląc, że to „trywialne”: prawdopodobnie nie ma powodu, aby implementować szalony parser i sprawdzanie wartości dla prostego skryptu, który wykonuje jedno zadanie dla wąskiego przypadku użycia dobrze.
Trudno jest znaleźć bal ance. Czasami nie można przewidzieć, że oprogramowanie będzie rosło i przetrwało dłużej niż prosty skrypt, w którym się zaczęło. Jednak często jest odwrotnie: zbytnio opracowujemy elementy, a projekt jest odkładany na półkę szybciej niż Ty przeczytaj Pragmatic Programmer. Zmarnowałeś czas i wysiłek na rzeczy, których wczesny prototyp nie potrzebował.
To jest właśnie podłość w przypadku Anty-Wzorów: są one obecne w obu krańcach spektrum, a ich wygląd zależy od wrażliwość osoby przeglądającej Twój kod.
Osobiście starałbym się zawsze iść ogólną drogą, gdy tylko zobaczę, że coś może się zmienić lub gdybym Musiałem to zrobić więcej niż raz. Bardziej precyzyjnym podejściem byłoby jednak dokładne oszacowanie kosztów kodowania na stałe w porównaniu z generowaniem lub generowaniem kodu dla tej konkretnej sytuacji.To to samo, co określenie, czy zadanie jest warte automatyzacji, w przeciwieństwie do wykonywania go ręcznie. Weź pod uwagę czas i koszt.
Komentarze
- To ' jest zabawne, ponieważ sam to pilotowałem, a dynamiczna obsługa wartości była dla mnie znacznie łatwiejsza, szybsza i czystsza. Zrobiłem to w Python, podczas gdy uważam, że produkt końcowy zostanie zakodowany w Javie – jeśli to robi różnicę. Wydawało się, że jest to zbyt skomplikowane, kiedy na stałe koduję wartości, ponieważ każda przychodząca kolumna musiała być śledzona w wielu miejscach. / li>
- @Tom: ' mówisz, że zaimplementowanie (lub nawet ponowne użycie) biblioteki wyszukiwania konfiguracji było łatwiejsze i szybsze niż użycie wartości zakodowanej na stałe? dla Ciebie. Nie ' nie wiem, jak ostatnie zdanie pasuje do definicji nadmiernej inżynierii. węgorz oczywiście niechlujny i oczywiście jeśli ' jest na stałe zakodowany i zduplikowany ' jest jeszcze gorszy (co nie było celem twojego pytanie pytanie, prawdopodobnie źle zrozumiałem, ale wydawało mi się, że chodziło mi o to, że wartość nie została zakodowana na stałe w miejscu za każdym razem, ale w jednym punkcie programu).
- W każdym razie ' m tylko wskazując przypadki, w których ' d być poprawne. ' Zwracam również uwagę, że w moim ostatnim zdaniu ' może być kontrowersyjne. Możesz ' zadowolić wszystkich i zespoły, mając ludzi o różnych poziomach umiejętności.
- @Tom, don ' t sprzedaj się zbyt krótko. ' na pewno coś zrobisz. Łatwiej i mniej czasochłonnie wydaje się napisanie szybkiego algorytmu porządkującego dane na podstawie pól działu i stanowiska, w przeciwieństwie do sztywnego kodowania
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Dużo trudniej byłoby również utrzymać tablicę zakodowaną na stałe w przypadku wprowadzenia nowego działu lub tytułu. - Możesz mieć bardziej złożone rzeczy, które nadal nadają się do zakodowania na stałe. Przychodzi mi na myśl, o czym pisałem kilka lat temu, wszystkie możliwe permutacje zbioru wartości. Musiałem znaleźć losowy prawidłowy kierunek, wybierając losową permutację, a następnie wzięcie pierwszego prawidłowego wyniku było zdecydowanie najbardziej wydajnym rozwiązaniem, a ponieważ znajdował się w pętli O (N ^ 3), wydajność miała znaczenie.
Odpowiedź
Czasami zakodowanie wartości jest w porządku. Na przykład istnieją liczby, takie jak 0, jeden lub różne wartości n ^ 2-1 dla masek bitowych, które muszą być pewnymi wartościami do celów algorytmicznych. Dopuszczenie takich wartości do konfigurowalnych nie ma wartości i tylko otwiera możliwość problemów. Innymi słowy, jeśli zmiana wartości tylko zepsułaby rzeczy, prawdopodobnie powinno być zakodowane na stałe.
W podanym przez ciebie przykładzie nie widzę, gdzie kodowanie na stałe byłoby przydatne. Wszystko, o czym wspomnisz, będzie / powinno już znajdować się w bazie danych, w tym nagłówki. Nawet elementy sterujące prezentacją (takie jak porządek sortowania) mogą zostać dodane, jeśli ich tam nie ma.
Komentarze
- Dzięki. Kolejność sortowania została jedyny problem, jaki miałem. Jednak w naszym przypadku nie ' nie ma znaczenia, a ja nie ' nawet nie uważałem, że może to być dodana jako kolejna tabela w bazie danych.
- Powinienem zauważyć, że zarządzanie tym wszystkim w DB jest jedną z opcji. Możesz także użyć plików konfiguracyjnych lub innych rozwiązań, ale twarde kodowanie wydaje się być złym wyborem. Opcja jest często używana, ponieważ ' łatwo jest utworzyć interfejs umożliwiający użytkownikom zarządzanie opcjami. Istnieją również narzędzia takie jak this , które są specjalnie zaprojektowane do tego celu.
Odpowiedź
Wdrożenie solidnego rozwiązania, które pozwala na konfigurowanie wartości, które w innym przypadku mogłyby zostać zakodowane na stałe, zgodnie z wymaganiami użytkowników końcowych solidna walidacja tych wartości. Czy wstawili pusty sznurek? Czy wstawili coś nieliczbowego w miejscu, w którym powinna to być liczba? Czy robią wstrzyknięcia SQL? Itd.
Twarde kodowanie pozwala uniknąć wielu z tych zagrożeń.
Co nie znaczy, że twarde kodowanie jest zawsze, a nawet często, dobrym pomysłem. jeden z czynników, które należy wziąć pod uwagę.