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

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?

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.

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.

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.

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ę.