Najpierw trochę tła. Piszę odnośnik z Wiek -> Stawka. Istnieje 7 przedziałów wiekowych, więc tabela przeglądowa składa się z 3 kolumn (od | do | stawki) z 7 wierszami. Wartości rzadko się zmieniają - są to stawki legislacyjne (pierwsza i trzecia kolumna), które pozostają takie same od 3 lat. Doszedłem do wniosku, że najłatwiejszym sposobem przechowywania tej tabeli bez zakodowania na stałe jest w bazie danych w globalnej tabeli konfiguracji, jako pojedyncza wartość tekstowa zawierająca CSV (więc „65,69,0.05,70,74,0.06” to poziomy 65-69 i 70-74 będą przechowywane). Stosunkowo łatwy do przeanalizowania, a następnie użycia.
Potem zdałem sobie sprawę, że aby to zaimplementować, będę musiał utworzyć nową tabelę, repozytorium do owijania go, testy warstwy danych dla repo, testy jednostkowe wokół kodu, który rozpakowuje CSV do tabeli, i testy wokół samego wyszukiwania. Jedyną zaletą całej tej pracy jest unikanie twardego kodowania tabeli odnośników.
W rozmowie z użytkownikami (którzy obecnie korzystają bezpośrednio z tabeli odnośników - patrząc na papierową wersję) istnieje opinia, że „stawki nigdy się nie zmieniają”. Oczywiście to nie jest poprawne - stawki zostały utworzone dopiero trzy lata temu, a w przeszłości rzeczy, które „nigdy się nie zmieniają” miały nawyk zmiany - więc dla mnie, aby programować defensywnie, zdecydowanie nie powinienem przechowywać tabeli odnośników w Aplikacja.
Z wyjątkiem sytuacji, gdy myślę YAGNI . Wdrożona przeze mnie funkcja nie określa zmian stawek. Jeśli stawki się zmieniają, nadal będą się zmieniać tak rzadko, że konserwacja nawet nie jest brana pod uwagę, a funkcja nie jest tak naprawdę na tyle ważna, że wszystko zmieniłoby się, gdyby nastąpiło opóźnienie między zmianą stawki a zaktualizowaną aplikacją.
Prawie zdecydowałem, że nic wartościowego nie zostanie utracone, jeśli zaprogramuję wyszukiwanie na stałe i nie martwię się zbytnio moim podejściem do tej konkretnej funkcji. Moje pytanie brzmi: czy jako profesjonalista właściwie uzasadniłem tę decyzję? Wartości na sztywno to zły projekt, ale problem z usunięciem wartości z aplikacji wydaje się naruszać zasadę YAGNI.
EDYCJA Aby wyjaśnić pytanie, nie martwię się o faktyczną implementację. Obawiam się, że mogę albo zrobić szybką, złą rzecz, i uzasadnić to, mówiąc YAGNI, albo też przyjąć bardziej defensywne, wymagające dużo wysiłku podejście, które nawet w najlepszym przypadku ostatecznie przynosi niewielkie korzyści. Czy jako profesjonalny programista moja decyzja o wdrożeniu projektu, który według mnie jest wadliwy, sprowadza się po prostu do analizy kosztów i korzyści?
EDYCJA Podczas gdy wszystkie odpowiedzi były bardzo interesujące, ponieważ myślę, że sprowadza się to do indywidualnych wyborów projektowych, myślę, że najlepsze odpowiedzi to @ Corbin i @EZ Hart, ponieważ poruszają rzeczy, których nie rozważałem w pytaniu:
- fałszywa dychotomia „prawidłowego usuwania zakodowanych wartości” poprzez przeniesienie jej do bazy danych w porównaniu z „wydajnym zastosowaniem YAGNI” przy użyciu zakodowania na stałe. Istniała trzecia opcja umieszczenia tabeli odnośników w konfiguracji aplikacji, która nie wiąże się z koniecznością poprawnego działania i bez wydajności YAGNI. Zasadniczo nie ograniczamy się do decyzji / decyzji, a sprowadza się to do decyzji o kosztach / korzyściach.
- generowanie kodu może zmniejszyć obciążenie związane z przenoszeniem zakodowanych wartości do bazy danych, a także w sposób, który usuwa również moją nadmiernie inżynierską decyzję o przetwarzaniu pliku CSV do tabeli. Potencjalnie powoduje to również problem z długoterminową konserwacją wygenerowanego kodu, jeśli podstawowe wymagania zmienią się dla metody wyszukiwania. Wszystko to wpływa tylko na analizę kosztów i korzyści i jest prawdopodobne, że gdybym miał dostęp do tej automatyzacji, nie rozważyłbym nawet takiego kodowania na sztywno.
Zaznaczam odpowiedź @ Corbina jako poprawną, ponieważ zmienia ona moje założenia dotyczące kosztów rozwoju i prawdopodobnie w najbliższej przyszłości dodam do mojego arsenału narzędzia do generowania kodu.