2008-11-20 15 views
5

Kiedy rozważasz uaktualnienie w narzędziu programistycznym, jak ważna jest dla Ciebie kompatybilność wsteczna? Czy nadal zakupiłbyś Visual Studio 2010, gdyby wymagał znaczących zmian w kodzie źródłowym? Gdzie jest punkt zwrotny dla Ciebie w zakresie handlu wsteczną kompatybilnością nowych funkcji?Jak ważna jest kompatybilność wsteczna?

+0

Czy możesz jako doświadczony facet wyjaśnić mi, dlaczego nie jest to post w społeczności? – badbadboy

+0

Ponieważ jest to uzasadnione pytanie? Społeczność Wiki nie ma zastosowania do wszystkiego i nie mam nic przeciwko temu, że nie chce się w to wtrącać. –

Odpowiedz

10

Podczas gdy zapytałeś o to z punktu widzenia programisty, myślę, że byłoby to bardziej interesujące pytanie w odniesieniu do oprogramowania, które tworzysz. Zamiast tego odpowiem na to pytanie. :)

Sprzęt i oprogramowanie kompatybilne wstecz (i, co ważniejsze, kompatybilne z przyszłością) zapewniają poczucie bezpieczeństwa użytkownikom, zwłaszcza przy zakupie lub modernizacji platform takich jak Windows. Jeśli nic więcej, Windows znany jest ze swojej skrupulatnej uwagi na kompatybilność wsteczną. Możesz uruchomić programy napisane ponad dziesięć lat temu w systemie Windows Vista z niewielkimi problemami, pod warunkiem, że są "dobrze napisane" (tzn. Nie używają nieudokumentowanych interfejsów API).

Z drugiej strony, ścisła dbałość o kompatybilność wsteczną może wiązać dłonie, gdy próbujesz wprowadzić nowe funkcje lub zrewolucjonizować platformę. Apple wiedział, że ma umierający system operacyjny i jednym z najbardziej odważnych ruchów, zakupił NeXT i postanowił zrobić NeXTSTEP nowym MacOS. Jedną z kluczowych rzeczy, które sprzedawały osoby na przejściu, była kompatybilna wstecz warstwa Classic. Ponownie, gdy Apple zdecydowało się przejść na chipy Intela, mechanizm uruchamiania aplikacji PowerPC na Intel o nazwie Rosetta, wraz z Universal Binaries, pozwolił ludziom swobodnie poruszać się pomiędzy PowerPC i Intelem bez obawy o utratę aplikacji.

Jedną z interesujących rzeczy jest to, że wraz z przejściem na Intel środowisko Classic zniknęło, ale nikt nie dba o to, ponieważ mieli poprzednie 5 lat na przejście z systemu Mac OS 9. Możliwe jest więc zrzucenie wsparcia dla starszych systemów. o ile masz łatwy sposób na przejście do nowego systemu i dajesz użytkownikom wystarczającą ilość czasu na zrobienie tego.

0

Zdefiniuj "istotne zmiany". Poszedłbym na całość, gdyby zmiany można było wprowadzić dzięki starannie opracowanemu "wyszukiwaniu", zastępującemu "nawet jeśli były obszerne.

Jednak zrobi to I. Każda firma, dla której pracowałem, będzie się opierała na jakichkolwiek zmianach w istniejącym kodzie.

1

Zależy to od tego, jakie środowiska są obsługiwane i jakie narzędzia stron trzecich są używane, ale mogą nie być kompatybilne.

Na przykład w miejscu, w którym pracuję, zaktualizowaliśmy wszystkich do VS2008 z VS2005, z wyjątkiem naszej grupy BI, ponieważ narzędzia BI do programu SQL Server nie były zgodne z VS2008. Po aktualizacji zaktualizowano ją do wersji VS2008.

Przyglądając się specyficznie VS, należy pamiętać, że VS2008 może kierować na .NET 2.0, .NET 3.0 i .NET 3.5. Sztuką jest uświadomienie sobie, że faktycznie jest skierowana na .NET 2.0 SP1 i .NET 3.0 SP1. W związku z tym aktualizacja środowiska IDE nie powinna wymagać wprowadzenia zmian w kodzie.

1

Ponieważ wiele zmian dzieje się w dziedzinie oprogramowania i sprzętu, myślę, że dobrze jest być otwartym na nowe zmiany i lepsze narzędzia podczas projektowania swojego rozwiązania. Na przykład w latach 90. nie mieliśmy procesorów wielordzeniowych i wysokiej klasy kart graficznych lub kart sieciowych, więc oczywiście cele optymalizacji kompilatorów i narzędzi były inne. Ale w tym samym czasie Visual Studio podobne narzędzia robią wszystko, aby dostosować się do starych frameworków i aplikacji.

Myślę, że jeśli nie możemy się doczekać lepszego świata, powinniśmy być otwarci na ciągłe zmiany, dopóki ta branża nie zostanie całkowicie dojrzała. (Może się to nie zdarzyć w naszym życiu :))

1

W wersji genitalnej, jeśli tworzysz platformę, która będzie stale używana przez wielu innych użytkowników do tworzenia własnych produktów, a Ty planujesz opracować aplikację dla przez długi czas to jest ważne. Zobacz PHP, Python, Eclipse i inne projekty open source, które przywiązują dużą wagę do kompatybilności wstecznej. Jest również ważna przy tworzeniu usług lub innych otwartych API używanych w architekturze n-warstwowej. Możesz mieć wszystkie aplikacje w przedsiębiorstwie, które łamią się cały czas, gdy zmieniasz swoje usługi.

Teraz, jeśli budujesz aplikację termokurczliwą lub aplikację biznesową, nie jest to tak ważne, ponieważ każda wersja jest oddzielona od poprzedników.

2

W przypadku projektów domowych zgodność wstecz naprawdę nie jest ważna. Dla biura/przedsiębiorstwa jest to absolutnie kluczowe.

3

W narzędziu programistycznym, jeśli nie zapewnia on całkowitej zgodności wstecznej z moim poprzednim kodem, nie będę go kupować i wątpię, by ktokolwiek to zrobił. Szczerze mówiąc, nie ma sensu. Jeśli mam już kompilator, który działa, aby zbudować mój kod źródłowy do kodu wykonywalnego, który będzie dla mnie działał, użyję go. Po co zmieniać mojego kodu, aby dostosować go do tego, co jest oczywiste dla twórcy narzędzi, a nie jako standard? Jeśli wymuszają zmiany kodu źródłowego z jednej wersji na drugą, dlaczego mieliby zadawać sobie trudu, aby kolejna wersja była kompatybilna?

Wymagana jest 100% kompatybilność wsteczna ze źródłem.Jedyną sytuacją, w której nie jest to całkowite wymaganie, jest sytuacja, gdy niekompatybilne bity są rozszerzeniami; tj. zmiany API, które są specyficzne dla narzędzia, takie jak wtyczki Eclipse itp. Nawet wtedy chciałbym kompatybilność, ale zdaję sobie sprawę, że nie można tego całkowicie oczekiwać. Ale jeśli udostępnisz interfejs API do podstawowej aplikacji/narzędzia i nie będziesz mieć kłopotów z utrzymaniem kompatybilności; cóż, z pewnością nie traktujesz poważnie swoich narzędzi, a ja nie zapłacę za nie poważnych pieniędzy.

+3

Podejrzewam, że nie masz na myśli tak absolutnie, jak to określasz. Na przykład C# 2 nie jest w 100% zgodny wstecz z C# 1. Jest blisko, ale nie jest w 100%. Zgodnie z twoją logiką nikt nie powinien był używać VS2005 lub VS2008. –

+0

Ja też się nie zgadzam. Pomogłem kilku osobom w migracji z eVC do Studio, a kod, który "działał" pod eVC, nie byłby kompilowany nawet w Studio, ponieważ kompilator jest znacznie lepszy. Podczas kompilacji nowsze środowiska wykonawcze również napotkały wiele problemów z kodem. Więc nawet po tygodniach pracy było warto. – ctacke

Powiązane problemy