Czy są zalety kodowania wartości danych w programie na stałe?

13

Jestem samoukiem, początkującym programistą, więc przepraszam, jeśli nie przybijam żargonu programisty.

Pracuję nad projektem, w którym dostarczam dane, które będą stale aktualizowane, dla programistów, którzy zasadniczo utworzą narzędzie do generowania raportów z zapytań dotyczących danych.

Wygląda na to, że wszyscy zaangażowani uważają, że muszą zakodować wartości danych (nie schemat, ale same domeny / wartości) w programie do generowania raportów.

Załóżmy na przykład, że składamy raporty na temat personelu; raport zostałby podzielony na kategorie, z nagłówkiem dla każdego działu, a następnie pod każdym działem będą podtytuły tytułów pracy, a następnie pod każdym podtytułem będzie lista pracowników. Deweloperzy chcą na stałe zakodować działy i stanowiska pracy. Z drugiej strony wydaje mi się, że mogliby / zapytaliby o te rzeczy w czasie wykonywania, sortowali rekordy według nich i dynamicznie generowali nagłówki raportów na podstawie dostępnych wartości.

Ponieważ lista potencjalnych wartości zmienia się z czasem (np. Działy zostaną utworzone / zmienione nazwy, zostaną dodane nowe stanowiska pracy), kod będzie wymagał ciągłej aktualizacji. Wydaje mi się, że moglibyśmy pominąć kroki konserwacji kodu i dynamicznie organizować raporty.

Ponieważ nie jestem programistą, zastanawiam się, czego mi brakuje. Jakie mogą być zalety zapisania wartości na stałe w takim narzędziu? Czy zazwyczaj tak są zaprojektowane programy?

Tomek
źródło
Czy tabele krzyżowe raportu oznaczają, że wartości w wierszach powinny pojawiać się jako kolumny?
Tulains Córdova,
1
@Brendan - Jeśli wpisujesz wartości kodu w raporcie, musisz zmienić listę w DWÓCH miejscach (źródło danych i raport), natomiast jeśli raport jest dynamiczny, musisz go zmienić tylko w jednym miejscu (raport) .
kwah
1
@Brendan dlaczego miałbyś skończyć z trzema lokalizacjami? Być może moje rozumowanie jest niepoprawne, ale przewiduję zapytanie SQL w celu pobrania danych z bazy danych, aplikacja agreguje / grupuje zwrócone wartości, np. Przez dział. Jeśli chcesz mieć narzut związany z wieloma zapytaniami db, 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 napędzany przez dane.
kwah
1
@Brendan Nie zgadzam się również z twoją definicją bycia w jednym miejscu - tak jak to opisujesz, jest w wielu lokalizacjach, rozrzuconych po całym kodzie źródłowym.
kwah

Odpowiedzi:

9

Wikipedia:

Kodowanie twarde (także kodowanie stałe lub kodowanie stałe) odnosi się do praktyki tworzenia oprogramowania polegającej na osadzaniu tego, co może, być może tylko z perspektywy czasu, można uznać za dane wejściowe lub konfiguracyjne bezpośrednio w kodzie źródłowym programu lub innego obiektu wykonywalnego lub stałe formatowanie dane, zamiast uzyskiwać te dane ze źródeł zewnętrznych lub generować dane lub formatować w samym programie przy użyciu danych wejściowych.

Kodowanie jest uważane za antypattern.

Uważane za anty-wzorzec, kodowanie na stałe wymaga zmiany kodu źródłowego programu za każdym razem, gdy zmieniają się dane wejściowe lub pożądany format, gdy użytkownik końcowy może zmienić szczegóły w jakiś sposób poza programem.

Czasami nie można tego uniknąć, ale powinno to być tymczasowe.

Często wymagane jest kodowanie na stałe. Programiści mogą nie mieć opracowanego dynamicznego interfejsu użytkownika dla użytkownika końcowego, ale nadal muszą dostarczyć tę funkcję lub wydać program. Zazwyczaj jest to tymczasowe, ale w krótkim okresie rozwiązuje presję na dostarczenie kodu. Później wykonuje się kodowanie programowe, aby umożliwić użytkownikowi przekazywanie parametrów, które dają użytkownikowi końcowemu sposób modyfikacji wyników lub rezultatów.

  • Twarde kodowanie wiadomości utrudnia internacjonalizację programu.
  • Ścieżki kodowania utrudniają dostosowanie się do innej lokalizacji.

Jedyną zaletą kodowania wydaje się być szybkie dostarczanie kodu.

Tulains Córdova
źródło
5
OK, ale „jedyna zaleta” jest często niezwykle ważna. Decyzje dotyczące projektowania w programowaniu często dotyczą kompromisu między sprawdzaniem w przyszłości a szybką dostawą, a zatem kodowanie na stałe może być całkowicie akceptowalnym wyborem. Czasami nie kodowanie na stałe jest złym wyborem projektu.
-1 Nie sądzę, że jest to pomocna odpowiedź. Mówi w zasadzie, że „niewłaściwe osadzanie wartości w kodzie źródłowym” jest niewłaściwe. Myślę, że OP chce wskazówek, kiedy rzeczy mogą należeć do kodu źródłowego, a zatem nie mieszczą się w twojej definicji w Wikipedii.
Nathan Cooper
Twarde kodowanie powinno być istotną częścią twojego procesu, a biorąc pod uwagę, że anty-wzorzec jest przestarzały w erze mikro-usług, samouczek Angular Tour of Heroes jest głośnym przykładem ogromnego oprogramowania, które bezpośrednio szyfruje, a nawet nakazuje jako pośredni krok. Co więcej, kiedy przechodzisz na dane dynamiczne, powinieneś zachować pewne dane zakodowane na stałe jako rezerwowe, być może kontrolowane przez zmienną środowiskową lub nawet wartość logiczną na samym kodzie, aby błędy i problemy bezpieczeństwa mogły być odpowiednio odizolowane linia.
Co znajduje się w wyszukiwarce Google
24

Naprawdę? Brak możliwych prawidłowych przypadków użycia?

Chociaż zgadzam się, że kodowanie na ogół jest anty-wzorcem lub przynajmniej bardzo nieprzyjemnym zapachem kodu , istnieje wiele przypadków, w których ma to sens:

  • prostota ( YAGNI ),
  • dane wejściowe są w rzeczywistości stałe i nigdy się nie zmienią (tj. reprezentują stałą naturalną lub biznesową lub przybliżenie jednej. np. 0, PI, ...),
  • oprogramowanie wbudowane (przychodzą na myśl ograniczenia pamięci i alokacji),
  • bezpieczne oprogramowanie (te wartości nie są dostępne i / lub łatwe do odkodowania lub inżynierii wstecznej, np. tokeny kryptograficzne i sole),
  • wygenerowany kod (twój preprocesor lub generator jest konfigurowalny, ale wydziela kod z zakodowanymi wartościami),
  • i prawdopodobnie jeszcze kilka.

Wciąż anty-wzór ? Podobnie jest z nadmierną inżynierią ! Chodzi o długość życia twojego oprogramowania !!

Nie mówię, że istnieją wszystkie ważne powody, i generalnie nie zgadzam się na wartości zakodowane na stałe. Ale niektórzy mogą łatwo uzyskać przepustkę z ważnych powodów.

I nie nadzoruj pierwszego dotyczącego prostoty / YAGNI , myśląc, że jest to trywialne: prawdopodobnie nie ma powodu, aby wdrażać szalony parser i sprawdzanie wartości dla prostego skryptu, który bardzo dobrze wykonuje jedno zadanie dla wąskiego przypadku użycia.

Trudno jest znaleźć równowagę. Czasami nie przewidujesz, że oprogramowanie będzie rosło i działało dłużej niż prosty skrypt, który zaczął. Często jednak jest na odwrót: przerabiamy rzeczy, a projekt zostaje odłożony na półkę szybciej niż można przeczytać w Pragmatic Programmer. Marnujesz czas i wysiłek na rzeczy, których nie potrzebował wczesny prototyp.

To wredne rzeczy z Anti-Patterns: są obecne w obu krańcach spektrum, a ich wygląd zależy od wrażliwości osoby sprawdzającej twój kod.

Haylem
źródło
To zabawne, ponieważ sam to pilotowałem, a mi było znacznie łatwiej, szybciej i czystiej obsługiwać wartości dynamicznie. Zrobiłem to w Pythonie, ale wierzę, że produkt końcowy będzie kodowany w Javie - jeśli to robi różnicę. Czułem, że nadpisałem wartości, kiedy wpisałem wartości na stałe, ponieważ każdą przychodzącą kolumnę trzeba było śledzić w wielu miejscach.
Tom
@Tom: Mówisz, że łatwiej i szybciej wdrożyć (a nawet ponownie użyć) bibliotekę wyszukiwania konfiguracji niż użyć na stałe wartości? Świetnie dla ciebie. Nie rozumiem też, jak twoje ostatnie zdanie pasuje do definicji nadmiernej inżynierii. Wydawałoby się to oczywiście niechlujne, a oczywiście, jeśli jest zakodowane na stałe i zduplikowane, jest jeszcze gorzej (co nie było celem pytania, prawdopodobnie źle zrozumiałem, ale wydawało mi się, że miałeś na myśli, że wartość nie została zakodowana na stałe za każdym razem, ale w jednym punkcie programu).
haylem,
W każdym razie wskazuję tylko przypadki, w których byłoby to ważne. Zaznaczam również, że w moim ostatnim zdaniu byłoby to kontrowersyjne. Nie możesz zadowolić wszystkich, a drużyny mają ludzi o różnych poziomach umiejętności.
haylem,
1
@Tom, nie sprzedawaj się zbyt krótko. Zdecydowanie jesteś na czymś. Pisanie szybkiego algorytmu do porządkowania danych jest łatwiejsze i mniej czasochłonne, patrząc na pola Departamentu i stanowiska, a nie na sztywne kodowanie Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Znacznie trudniej byłoby utrzymać tablicę zakodowaną na stałe w przypadku wprowadzenia nowego działu lub tytułu.
Chris G
1
Możesz mieć bardziej złożone rzeczy, które nadal są rozsądne dla twardego kodu. Przypomina mi się, że kilka lat temu napisałem, że wszystkie możliwe kombinacje zestawu wartości. Musiałem znaleźć losowy prawidłowy kierunek, wybrać losową permutację, a następnie wziąć pierwszy prawidłowy wynik, to zdecydowanie najbardziej wydajne rozwiązanie, ponieważ miało to znaczenie w wydajności pętli O (N ^ 3).
Loren Pechtel,
4

Są chwile, w których wartości kodu są w porządku. Na przykład istnieją pewne liczby, takie jak 0, jedna 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 konfigurowalnego nie ma żadnej wartości i jedynie otwiera możliwość problemów. Innymi słowy, jeśli zmiana wartości tylko zepsułaby rzeczy, prawdopodobnie powinna być zakodowana na stałe.

W podanym przez ciebie przykładzie nie widzę miejsca, w którym kodowanie byłoby przydatne. Wszystko, co wspominasz, powinno / powinno już znajdować się w bazie danych, łącznie z nagłówkami. Nawet rzeczy, które napędzają prezentację (takie jak porządek sortowania) można dodać, jeśli ich nie ma.

JimmyJames
źródło
Dzięki. Jedyną kwestią, jaką miałem, była kolejność sortowania. Jednak w naszym przypadku nie ma to znaczenia i nawet nie pomyślałem, że można go dodać jako kolejną tabelę w bazie danych.
Tom
1
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 kodowanie wydaje się złym wyborem. Opcja DB jest często używana, ponieważ łatwo jest utworzyć interfejs, aby umożliwić zarządzanie opcjami przez użytkowników. Istnieją również narzędzia, takie jak to , które zostały zaprojektowane specjalnie do tego celu.
JimmyJames,
-1

Wdrożenie niezawodnego rozwiązania, które pozwala na skonfigurowanie wartości, które w innym przypadku byłyby zakodowane na stałe, aby mogły być konfigurowane przez użytkowników końcowych, wymaga solidnej weryfikacji tych wartości. Czy wprowadzili pusty ciąg? Czy wprowadzili coś nienumerycznego tam, gdzie powinna to być liczba? Czy robią iniekcję SQL? Itp.

Kodowanie na stałe pozwala uniknąć wielu z tych zagrożeń.

Co nie znaczy, że kodowanie na stałe jest zawsze, a nawet często dobrym pomysłem. To tylko jeden z czynników, które należy wziąć pod uwagę.

Topher Eliot
źródło