2010-02-11 12 views
9

Jestem zainteresowany tym, jakie strategie wymyślili ludzie, aby oddzielić całą logikę crufty, niezbędną do zachowania zgodności wstecznej z głównym kodem aplikacji. Innymi słowy, strategie, które pozwalają ci zbliżyć się do tego, by twój kod wyglądał tak, jakby nie było żadnych zastrzeżeń dotyczących zgodności wstecznej, z wyjątkiem oddzielnych izolowanych plików źródłowych wyraźnie dla tego zadania.Jak czytelnie oddzielasz kod dla kompatybilności wstecznej z głównego kodu?

Na przykład, jeśli aplikacja odczytuje konkretny format pliku, zamiast jednej wielkiej parsującej funkcji honkera, możesz mieć swój pierwszy kod iterujący listę "dziwnych" wpisów/obiektów, gdzie każde dziwactwo sprawdza plik, aby zobaczyć jeśli jest to plik, do którego ma zastosowanie, a jeśli tak, wywołuje swoją własną logikę przetwarzania zamiast normalnej logiki.

Dziwactwa to strategia OK, ale musisz wykonać pracę, aby umieścić zakodowane sprawdzenia we wszystkich odpowiednich miejscach w aplikacji, a to, jak będą wyglądać kontrole, będzie różne dla różnych typów dziwactwa itp. Wydaje się prawie niemożliwe. tak, jak powinny istnieć biblioteki dedykowane do zestawu do tego zadania. Inną kwestią jest to, jak egzekwować, że dziwactwa nie są nadużywane jako haki ogólnego przeznaczenia w arbitralne fragmenty aplikacji.

Odpowiedz

10

Moja zwykła strategia to mieć coś oddzielnego, co przetłumaczy wejście kompatybilności wstecznej na nowe wejście implementacyjne, a następnie użyje nowego kodu implementacji z tymi przetłumaczonymi danymi.

+2

+1: To zwykle moje podejście. Prosty wrapper (dla kodu) i konwerter formatu (dla danych) zwykle wystarcza do stworzenia przyzwoitej warstwy kompatybilności. –

+1

Prawdopodobnie najczystsza strategia, choć byłoby to trudne, gdybyś dysponował ogromnymi danymi. Wtedy myślę, że będziesz chciał zaimplementować widoki adapterów, zamiast wykonywać rzeczywistą konwersję, a nakładanie warstw może być bolesne w języku bez refleksji jak w C++. –

0

Będzie to zależało od ram czasowych do momentu wycofania wspomnianych funkcji kompatybilności wstecznej. Jesteście pewni, że za kilka miesięcy wypuścicie kolejną wersję swojego oprogramowania, która nie będzie już musiała mieć tych dziwactw, możecie po prostu zachować stary kod, jeśli jesteś wystarczająco zdyscyplinowany, aby faktycznie usunąć wszystko w następnym cyklu rozwoju. Utrzymuję dwa oddzielne komponenty serwera zaplecza, w których pracuję i dopóki nie można ich uaktualnić w tym samym czasie, zwykle mogą one być w ciągu kilku tygodni. Oznacza to, że komunikacja między nimi musi być kompatybilna wstecz, ale tylko jedna wersja z powrotem, aw każdej wersji mogę usunąć stary kod, który zostawiłem ze względu na kompatybilność wsteczną w poprzedniej wersji.

Jeśli jednak warstwa kompatybilności pozostanie przez długi czas lub nawet w nieskończoność (pomyśl o formatach binarnych Worda), spróbuję zmienić kod w taki sposób, aby nowa funkcjonalność i stara funkcjonalność były równe warunki w nim. Myślę, że zarówno stary format (lub zachowanie), jak i nowy format są częścią wymagań systemu i nie ma powodu, aby stary format był obywatelem drugiej kategorii (poza tym, że jest stary, kalambur przeznaczony).

Powiązane problemy