Interpretuję tę sytuację jako mającą dwa podstawowe problemy, być może trzy.
- Niepożądane uaktualnienie zestawu SDK dostało się do źródła, gdzie może negatywnie wpłynąć na produkt.
- Z pytania: osoba, która wykonała niechciane uaktualnienie, nie wiedziała o poprzedniej, konkretnej decyzji o odmowie uaktualnienia.
Pierwszy z nich jest moim zdaniem najpoważniejszy. Jeśli niechciane uaktualnienie zestawu SDK może dostać się do kodu, mogą to oznaczać inne problemy.
Ktoś zasugerował dodanie przypadku testu jednostkowego, który zakończy się niepowodzeniem, jeśli wykryje aktualizację. Chociaż zapobiegnie to aktualizacji, uważam, że jest to niebezpieczna ścieżka, która z czasem prowadzi do przepływu lawy . Wydaje się nieuniknione, że w pewnym momencie w przyszłości SDK zostanie zaktualizowany, aby wprowadzić nowe funkcje lub poprawki błędów, lub ponieważ stara wersja nie jest już obsługiwana. Wyobraź sobie porysowanie głowy, a może nawet argumenty, które pojawią się, gdy taki test jednostkowy nie powiedzie się.
Myślę, że najbardziej ogólnym rozwiązaniem jest dostosowanie procesu rozwoju. W przypadku git użyj procesu żądania ściągania . W przypadku Subversion i starszych narzędzi użyj gałęzi i diff. Ale mają pewien proces, który pozwala starszym programistom wychwycić tego rodzaju problemy, zanim wejdą do bazy kodu i wpłyną na innych programistów.
Gdyby w Twojej sytuacji wykorzystano proces żądania ściągnięcia i jeśli każde żądanie ściągnięcia jest wąskie i specyficzne, nie zmarnuje się dużo czasu. Prośba o pobranie aktualizacji SDK zostałaby przesłana i odrzucona z komentarzem, że aktualizacja nie jest pożądana. Nie wpłynęłoby to na nikogo innego i nie byłoby już potrzeby cofania aktualizacji SDK.
Jednak, aby bezpośrednio odpowiedzieć na pierwotne pytanie, zgadzam się z innymi, że oczekiwanie od wszystkich programistów pełnego przeczytania całej historii zmian w kodzie, informacji o wydaniu itp. Dla takich powiadomień jest stratą cennego czasu. Co jest nie tak z krótkim e-mailem zespołu?
Możliwy trzeci problem: dlaczego uaktualnienie nie jest w ogóle potrzebne? Najwyraźniej przynajmniej jeden programista pomyślał, że aktualizacja będzie dobrą rzeczą. Istnieje wiele dobrych powodów, aby opóźniać aktualizację, ale także wiele złych. Uważaj, aby nie dopuścić do przepływu lawy (niepotrzebnego kodu kompatybilności wstecznej) i kultu ładunku („nie możemy tego uaktualnić, ale nie wiem dlaczego”) anty-wzorów!