Co zrobić, gdy krytyczna funkcjonalność zależności jest zepsuta i utrudnia rozwój?

Wczoraj pracowałem nad projektem API Rails 5, który wykorzystuje bibliotekę act-as-taggable-on, aby pozwolić na rzeczy z tagami (np. Pytania na SE). Rails 5 jest teraz obsługiwany w wersji alfa. Obecnie jest PR, aby naprawić błąd oczekujący na połączenie w master; błąd spowodował, że moja gałąź funkcji zatrzymała się w połowie ukończenia - nie mogłem zaimplementować żadnej funkcji biblioteki, ponieważ ładowanie zostało przerwane.

Jako szybką poprawkę po prostu sklonowałem repozytorium, naprawiłem problem z tym samym kodem, który miał PR, i skierowałem mój Gemfile (plik kontroli wersji zależności) do mojego własnego rozwidlenia Github, aż do momentu, gdy poprawka ostatecznie zostanie ponownie scalona z master.

Miałem szczęście, że poprawka była prosta ( i że ktoś już to zrobił ), więc mogłem obejść ten problem. Ale co, jeśli ta biblioteka miała kluczowe znaczenie dla rozwoju mojej aplikacji? Co jeśli poprawka, która zatrzymywała mój rozwój, nie była szeroko rozpowszechnionym problemem dla innych osób , więc poprawka nie pojawiła się tak szybko, jak tym razem?

Wyobraź sobie, że ta funkcja musiała zostać ukończona przed opracowaniem innych funkcji zależnych - co robisz w tej sytuacji? Co jeśli, dla mnie, tagowanie było absolutnie kluczowe dla następnej frazy rozwoju, gdzie wszystko inne na nim polegało - ale zależność tagowania jest błędna w mojej konfiguracji? Co zrobić, gdy krytyczna funkcjonalność zależności utrudnia rozwój funkcji (a)?

I z pewnością walki na miecze na krzesłach biurowych przez wiele godzin lub dni nie są opcją ...

To jeden z powodów, dla których używasz oprogramowania typu open source, prawda?

Mógłbyś wypowiedzieć ten sam argument za „co stanie się, jeśli moja bardzo droga, zastrzeżona biblioteka o zamkniętym źródle nagle się przewróci? Czy będzie ktoś w [dużej, monolitycznej firmie programistycznej], który to naprawi?” Dzięki oprogramowaniu typu open source masz przynajmniej szansę na samodzielne usunięcie tego błędu.

Jeśli oprogramowanie ma krytyczną zależność od biblioteki typu open source, istnieją trzy rzeczy, które możesz zrobić, aby zmniejszyć ryzyko:

1. Zapoznaj się z bazą kodu, być może nawet sam wnosząc wkład. To kolejny powód, dla którego wybrałeś oprogramowanie typu open source, prawda?

2. Miej bibliotekę rezerwową, jeśli pierwsza biblioteka upadnie. Właśnie dlatego programujesz interfejsy; żebyś mógł zmienić implementację, jeśli musisz, prawda?

3. Zrównoważyć swoje pragnienie najnowocześniejszych potrzeb z potrzebą stabilności (tj. Nie używaj oprogramowania alfa). Wiedziałeś, w co się pakujesz, prawda?

Rozwiązaniem do tworzenia aplikacji, w których błędy lub brak funkcji wiążą się z wysokim ryzykiem spowodowania zatrzymania pracy, jest nieużywanie bibliotek wysokiego ryzyka. Nudne i kulawe, wiem ..

Powiedziałeś, że to wersja alfa. Nie używaj wersji alfa do krytycznych projektów. To nie jest nawet wersja beta, a co dopiero 1.0, więc tego można się spodziewać. Celem tego etapu w projekcie jest znalezienie problemów i zahartowanie projektu.

Jeśli znajdziesz się w takiej sytuacji, zasadniczo musisz zrobić to, co zrobiłeś (zrobiliśmy dokładnie to samo). Napraw to i PR projektu.

Ale rozwiązaniem jest użycie bardziej stabilnych bibliotek ze zrozumiałą funkcjonalnością i interfejsami API lub przynajmniej utrzymanie zgodności wstecznej ze stabilną wersją. Powinieneś być ostrożny, polegając w 100% na czymś, nad czym nie masz kontroli i który chcesz osiągnąć.

Zazwyczaj zaleca się ukrywanie bibliotek stron trzecich za adapterami lub opakowaniami, które sam piszesz. Ma to dwojakie zalety:

• Możesz zamienić bibliotekę innej firmy na inną, nie zmieniając żadnego kodu
• Możesz zaprogramować resztę kodu na własnym interfejsie adaptera. W przypadku przejściowego problemu z biblioteką wystarczy podłączyć swój stub / fake lub uproszczoną wersję funkcji biblioteki. W ten sposób tworzenie i testowanie dalszych funkcji nie jest blokowane (nawet jeśli wdrożenie pełnego programu nadal jest).