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

16

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?

użytkownik 367035
źródło
2
To pytanie będzie zależeć od tego, czy te przełomowe zmiany przynoszą wystarczające korzyści (i zyski), które uzasadniają wysokie tempo zmian.
rwong
3
Jeśli ten numer wersji korzysta z Semver, a jeśli system ma bibliotekę lub inny interfejs API, od którego zależą inne zespoły lub organizacje, to ta duża liczba główna oznacza, że ​​wystąpiły problemy z zatwierdzeniem stabilnego, rozszerzalnego projektu interfejsu API. Oznacza to również, że jasne informowanie o niezgodnościach jest wysoko cenione, co jest dobrą rzeczą. W przypadku jakichkolwiek innych elementów (takich jak nazwy marketingowe, programy aplikacyjne, numery inne niż Semver…) liczba ta nie ma znaczenia i należy ją w dużej mierze pominąć. Zapytaj o to swoich współpracowników, aby lepiej poznać projekt.
amon
3
@amon System jest używany wewnętrznie z publicznymi klientami mobilnymi komunikującymi się z systemem za pośrednictwem interfejsu API typu REST. Wersjonowanie jest Semver, jak wspomniałem, a nie wersja marketingowa.
user367035,
Liczba nie ma znaczenia, ale zrobiłbym się podejrzliwy, gdyby identyfikator wersji zawierał ładny akronim, na przykład Windows NT lub Windows ME lub XP lub naprawdę Windows.
John Wu,
1
@JohnWu: pytanie dotyczy konkretnie liczby, więc tak, liczba ma znaczenie. Mówiąc dokładniej, chodzi o liczbę w kontekście SemVer, gdzie liczba nie tylko ma znaczenie, ale ma również ściśle określone znaczenie.
Jörg W Mittag

Odpowiedzi:

14

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?

Jörg W Mittag
źródło
5
Ta odpowiedź wydaje się bezpośrednio dotyczyć pytania. Niektóre inne odpowiedzi byłyby poprawne, gdyby nie założenie OP dotyczące wersji semantycznej.
joshp,
Warto również zauważyć, że przełomowe zmiany nie zawsze są poważne. Czasami są naprawdę bardzo małe (ale ważne). Dlatego mogą potrzebować bardzo niewielkiej zmiany dla użytkowników. Ponadto może wystąpić całkiem duży stopień przełamania zmian w zależności od sposobu użycia interfejsu API. Czasami przełomowa zmiana nie wpłynie na przykład na wszystkich użytkowników. Ponadto poprawki błędów mogą wprowadzać przełomowe zmiany, ale najlepiej jest je naprawić wcześniej niż później. A jeśli interfejs API jest wewnętrzny, łatwiej jest obsługiwać te niewielkie zmiany.
Kat
1

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

Leniwy Borsuk
źródło
7
OP stwierdził, że używają wersjonowania semantycznego; dlaczego to ignorujesz?
Jörg W Mittag
-3

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.

Hazzit
źródło
3
„W przypadku korzystania z wersji semantycznej nadal należy podjąć decyzję, które zmiany są uważane za„ poważne ”, a które„ niewielkie ”.” - Nie, nie ma; jest to dokładnie zdefiniowane w specyfikacji. „Istnieją różne powody, aby podnieść numer wersji lub go nie podbić”. - Nie, nie ma; jest dokładnie jeden powód, aby zwiększyć liczbę główną (o którą chodzi w tym pytaniu), i jest to dokładnie określone w specyfikacji.
Jörg W Mittag
1
@ JörgWMittag Albo źle to czytam, albo specyfikacja mówi konkretnie, kiedy MUSISZ podbić numery wersji, ale nie mówi nic o tym, kiedy MOŻESZ.
Hazzit,
-4

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

Martin Maat
źródło
6
Pytanie jest oznaczone wersją semantyczną , OP wspomina o wersji semantycznej w pytaniu i ponownie potwierdziło w komentarzach, że używa wersji semantycznej. Specyfikacja SemVer mówi bardzo wyraźnie, gdy zwiększane są główne wersje. Żadne z Twoich „innych powodów” nie mają zastosowania.
Jörg W Mittag