Czy szybka wersja główna jest dowodem złego projektu?

Kilka miesięcy temu podjąłem pracę jako młodszy programista. System, nad którym pracujemy, jest produkowany od około 2 lat. Nie brałem udziału w tworzeniu systemu i projektowaniu.

Zauważyłem tylko, że główna wersja systemu ma już 11. YZ Z mojego doświadczenia w pracy z innymi systemami i bibliotekami, nie przypominam sobie, żeby produkt szybko wpadał na główną wersję. Istnieją produkty, które od lat są w wersji 1.XY i wciąż otrzymują funkcje i poprawki błędów.

Zakładając, że wersja semantyczna jest używana właściwie, czy to oznacza, że ​​system jest źle zaprojektowany, ponieważ wprowadza poważne przełomowe zmiany prawie co cztery miesiące?

Zakładając, że wersja semantyczna jest używana właściwie, czy to oznacza, że ​​system jest źle zaprojektowany, ponieważ wprowadza poważne przełomowe zmiany prawie co cztery miesiące?

Niekoniecznie.

W komentarzach wspomniałeś, że jest to wewnętrzny interfejs API. Złamanie interfejsu API jest złe, ponieważ łamiesz kod każdego użytkownika. Ale w przypadku wewnętrznego interfejsu API „wszyscy” to tylko „ty” i jesteś w stanie doskonale koordynować takie zmiany interfejsu API ze sobą, więc ból, który zwykle wiąże się ze zmianami interfejsu API, jest znacznie mniejszy.

Ponadto średnia może być bardzo myląca: może mieli 11 przełomowych zmian API w ciągu pierwszych kilku dni wczesnego rozwoju i od tego czasu są stabilni przez 4 lata? SemVer pozwala na dokonywanie przełomowych zmian bez zwiększania liczby głównej, jeśli liczba główna wynosi 0, ale nie zmusza cię do tego. Może zaczęli używać SemVer od 0, nawet podczas fazy prototypowania / eksploracji?

Krótka odpowiedź

Nie

Długa odpowiedź

„Czasami liczba jest tylko liczbą”

Zapomnij o „wersjonowaniu semantycznym”, „racjonalności”, „logice” w obecnym szalonym świecie

Dlaczego Chrome tak szybko pożera numery wersji?

numery „wersji” są używane jako kamienie milowe dla punktów oddziałów, a nie w głównych wydaniach, aby oczarować publiczność tak, jak używają ich inni programiści. Jest to ciągły rozwój, z funkcjami gotowymi lub niegotowymi, a nie okazjonalnym wydarzeniem łączącym wiele nowych funkcji w celu stworzenia dużego wydarzenia

Korzystając z wersji semantycznej, nadal należy podjąć decyzję, które zmiany są uważane za „poważne”, a które „niewielkie”. Istnieje wiele powodów, aby podnieść numer wersji lub go nie podbić.

Systemy z obietnicami zgodności z poprzednimi wersjami mogą w przypadku większości aktualizacji wysadzić główny numer wersji tylko dlatego, że w niektórych mniej lub bardziej ezoterycznych przypadkach narożnych występuje przerwa w kompatybilności wstecznej. Te same systemy mogą pozostać przy 1.xy prawie bez końca, ponieważ wiele wysiłku wkłada się w kompatybilność wsteczną, starając się nigdy nie złamać żadnego zależnego systemu. Oba podejścia do numeracji wersji można uznać za „konserwatywne”, ale oba mogą być również oznaką głębokiego podstawowego problemu.

Innym razem faktycznie masz harmonogram wydań (pomyśl o kwartalnych aktualizacyjnych płytach CD wysyłanych do klientów), w których sensowna jest zmiana głównego numeru wersji, aby zamiast „wersji 3.4 / 16 października” było to tylko „wersja 11.0”. W dzisiejszych czasach coraz więcej oprogramowania jest wypuszczane w krótkich odstępach czasu, co sprawia, że ​​harmonogramy wydań nie są powodem do trzymania się określonego schematu kontroli wersji. Widziałem to w dużych systemach magazynowych, które pozwalają wewnętrznemu IT tylko jeden dzień przestoju na kwartał (zwykle w niedzielę). Ten dzień jest dniem wdrożenia i za każdym razem jest oznaczany nową wersją główną.

Niektóre programy mają zewnętrzne zależności, które są niezwykle ważne, ponieważ użytkownik będzie musiał zaktualizować oba jednocześnie. Jeśli masz dodatek do programu Word, który działa tylko z programem Word 2010 i inny dla programu Word 2013, możesz zsynchronizować główne numery wersji z numerami MS-Word. Tutaj duże liczby są bardzo ważne, ponieważ niektórzy użytkownicy będą „opóźniać” się w normalnym harmonogramie aktualizacji, ponieważ nie zaktualizowali się do najnowszej wersji programu Word (lub cokolwiek innego, na czym polegasz: SAP, Dynamics, itp).

Czasami inne czynniki zewnętrzne decydują o numerach wersji. Jeśli masz oprogramowanie fiskalne, mogą istnieć coroczne aktualizacje odpowiadające prawu podatkowemu (które zwykle obowiązują od 1 stycznia). Takie systemy będą miały główne wersje zmieniające się dokładnie raz w roku - nie dlatego, że taki jest harmonogram aktualizacji, ale dlatego, że ma to inne znaczenie dla klienta: jeśli pobierasz podatki w 2016 roku, lepiej mieć program, który jest aktualizowany do prawa podatkowego 2016.

Ostatecznie numery wersji zależą od tak wielu czynników - często specyficznych dla jednej domeny - że sama liczba nie mówi nic o stanie twojej bazy kodu. Jest to znacznie lepsze podejście do patrzenia na to, kiedy, dlaczego i jak mają miejsce wdrożenia - i jak płynnie. Jeśli możesz wprowadzić poważną aktualizację do 10.000 klientów i mieć kilka połączeń telefonicznych - prawdopodobnie nic ci nie jest. Jeśli wprowadzisz drobną łatkę dla 10 klientów i będziesz musiał z tego powodu pracować w nadgodzinach, prawdopodobnie coś jest nie tak.

Koncentracja na znaczeniu numerów wersji jest rzeczywiście ważna. Drobna.wersja.numer_budowy

Jeśli major pójdzie szybko w górę, być może deweloper ma te wszystkie nowe pomysły i ciężko pracuje.

Jednak w świecie biznesu mogą istnieć inne powody, by zwiększać główny numer wersji. Lubić

• Sprzedaż spadła, klienci / użytkownicy czekają na kolejne duże wydanie przed aktualizacją.

• Umowa mówi, że klienci mają prawo do drobnych aktualizacji. Sprzedawca nie może naliczać ich za te, więc niektóre drobne ulepszenia są sprzedawane jako główne ulepszenia produktu.

• Konkurent X jest w grze nieco dłużej, więc ich główny numer wersji jest po prostu wyższy niż twój. To sprawia, że ​​wygląda na to, że pozostajesz w tyle, musisz „nadrobić zaległości”.