Jak zdecydujesz, kiedy uaktualnić bibliotekę w projekcie?

Question

Pracuję nad projektem wykorzystującym wiele bibliotek Java o otwartym kodzie źródłowym. Kiedy aktualizacje do tych bibliotek wyjdzie, mamy tendencję do naśladowania konserwatywną strategię:

1. jeśli coś nie jest zepsute, nie naprawiaj go
2. jeśli nie posiada nowe funkcje chcemy zignorować

Stosujemy tę strategię, ponieważ zazwyczaj nie mamy czasu, aby umieścić nową bibliotekę i dokładnie przetestować ogólną aplikację. (Podobnie jak wiele innych zespołów programistycznych, jesteśmy zawsze w tyle za harmonogramem funkcji, które obiecaliśmy kilka miesięcy temu.)

Ale czasami zastanawiam się, czy ta strategia jest mądra, biorąc pod uwagę, że niektóre ulepszenia wydajności i duża liczba poprawek zazwyczaj pochodzą z biblioteki aktualizacje. ("Kto wie, może rzeczy będą działać lepiej w sposób, jakiego nie przewidujemy ...")

Jakich kryteriów używasz przy podejmowaniu tego typu decyzji w swoim projekcie?

Answer 1

Nauczyłem się wystarczająco dużo lekcji do zrobienia następujące:

1. lista kontrolna zmienić biblioteki. Co naprawili? Czy się przejmuję? Jeśli nie ma listy zmian, biblioteka nie jest używana w moim projekcie.
2. Co ludzie publikują na forum Biblioteki? Czy pojawienie się wpisów zaczyna się krótko po wydaniu, wskazując na oczywiste problemy?
3. W tym samym duchu, co numer 2, nie aktualizuj natychmiast. KAŻDY ma złe wydanie. Nie zamierzam być pierwszym, który dostanie trochę z tym małym błędem. (to już jest). To nie znaczy, że trzeba też poczekać 6 miesięcy. W ciągu pierwszego miesiąca od wydania powinieneś znać wady.
4. Kiedy decyduję się na ulepszenie; test, test testowy. Tutaj automatyczne testowanie jest niezwykle ważne.

EDIT: chciałem dodać jeszcze jeden element, który jest co najmniej równie ważne, a może bardziej, niż inni.

• Jakie zmiany zostały przełamane w tym wydaniu? Innymi słowy, czy biblioteka idzie w innym kierunku? Jeśli biblioteka jest przestarzała lub zastępuje funkcjonalność, będziesz chciał być na bieżąco.

Answer 2

Ważne: Należy unikać Technical Debt.

"Jeśli nie jest zepsuty, nie aktualizuj" to szalona polityka, która prowadzi do tak zepsutego oprogramowania, że ​​nikt nie może go naprawić.

Wysypka, nietestowane zmiany są złym pomysłem, ale nie tak źle, jak kumulowanie technicznego długu, ponieważ w krótkim okresie wydaje się tańsze.

Wykonaj "nocną kompilację", dzięki czemu możesz nieustannie testować wszystkie zmiany - swoje i pakiety, od których zależy.

Do czasu ciągłego procesu integracji można wykonywać kwartalne wydania główne, które obejmują aktualizacje infrastruktury.

Unikaj długu technicznego.

Answer 3

kilka ważnych pytań:

• Jak powszechnie stosowane jest biblioteka? (Jeśli jest szeroko stosowany, błędy zostaną znalezione i szybciej usunięte)
• Jak aktywnie to jest?
• Czy dokumentacja jest bardzo jasna?
• Czy nastąpiły poważne zmiany, pomniejsze zmiany lub tylko wewnętrzne zmiany?
• Czy aktualizacja narusza zgodność wsteczną? (Czy będziesz musiał zmienić dowolny kod?)

Jeśli aktualizacja nie wygląda źle zgodnie z powyższymi kryteriami, lepiej z nią iść, a jeśli masz jakiekolwiek problemy, przywróć starą wersję.

Answer 4

Jednym ze sposobów jest udostępnienie bibliotek open source, z których korzystasz pod kontrolą własnego kodu źródłowego. Następnie okresowo scalaj zmiany w górę do następnej gałęzi wydania, lub wcześniej, jeśli są to poprawki zabezpieczeń i uruchom automatyczne testy.

Innymi słowy, należy użyć tych samych kryteriów, aby zdecydować, czy zastosować zmiany w sieci wstępnej, tak jak w przypadku cykli zwalniania kodu zapisywanego w domu. Rozważ twórców oprogramowania open source, aby byli częścią wirtualnego zespołu programistycznego. Tak naprawdę tak jest, to tylko kwestia tego, czy zdecydujesz się rozpoznać to jako część twoich praktyk programistycznych.

Answer 5

Chociaż nie chcesz aktualizować tylko dlatego, że jest nowa wersja, jest jeszcze jedna uwaga, która jest dostępna w starej wersji. Wpadłem na ten problem, próbując budować projekty open source.

Answer 6

Zazwyczaj zakładam, że zignorowanie nowej wersji biblioteki (coz "nie ma żadnych interesujących funkcji lub ulepszeń) jest błędem, ponieważ pewnego dnia dowiesz się, że ta wersja jest konieczna do migracji do następna wersja, do której możesz chcieć dokonać aktualizacji.

Moja rada to zatem uważne sprawdzenie, co zmieniło się w nowej wersji i rozważenie, czy zmiany wymagają wielu testów, czy niewiele.

Jeśli wymaganych jest wiele testów, najlepiej jest uaktualnić do nowszej biblioteki w następnym wydaniu (wersja główna) oprogramowania (np. W przypadku przejścia z wersji 8.0 do wersji 8.5). Kiedy tak się dzieje, domyślam się, że są też inne główne modyfikacje, więc wiele testów zostało wykonanych.

Answer 7

Wolę, aby wersje nie pozostawały zbyt daleko w tyle w bibliotekach zależnych. Aż do roku jest w porządku dla większości bibliotek, chyba że znane są problemy z bezpieczeństwem lub wydajnością. Biblioteki ze znanymi problemami bezpieczeństwa są niezbędne do odświeżenia.

Okresowo pobieraję najnowszą wersję każdej biblioteki i uruchamiam testy jednostek aplikacji za ich pomocą. Jeśli przejdą, używam ich w naszych środowiskach programistycznych i integracyjnych przez pewien czas i popycham do kontroli jakości, gdy jestem zadowolony, że nie są do bani.

Powyższa procedura zakłada, że ​​interfejs API nie zmienił się znacząco. Wszystkie zakłady są wyłączone, jeśli muszę zmienić istniejący kod tylko po to, aby użyć nowszej wersji biblioteki. (np. Axis 1x vs. 2x) Następnie musiałbym zaangażować kierownictwo, aby podjąć decyzję o alokacji zasobów. Taka zmiana byłaby zazwyczaj różna, dopóki nie zaplanowano poważnej zmiany dotychczasowego kodu.