Jak radzisz sobie ze zmianami frameworków open source, których używasz do swoich projektów?

To może być moje osobiste dziwactwo, ale lubię aktualizować kod w żywych projektach - w tym bibliotekach / frameworkach, których używają. Częściowo dlatego, że uważam, że aplikacja internetowa jest bezpieczniejsza, jeśli jest w pełni łatana i aktualna. Częściowo jest to po prostu dotyk obsesyjnej kompulsywności z mojej strony.

W ciągu ostatnich siedmiu miesięcy dokonaliśmy gruntownej przeróbki naszego oprogramowania. Porzuciliśmy platformę Xaraya, która była powolna i zasadniczo martwa jako produkt, i przekonwertowaliśmy na Cake PHP. (Wybraliśmy Cake, ponieważ dało nam to możliwość bardzo szybkiego przepisania naszego oprogramowania i dostatecznego zwiększenia wydajności w stosunku do Xaraya, aby było warto.)

Wdrożyliśmy testy jednostkowe za pomocą SimpleTest i przestrzegaliśmy wszystkich konwencji nazewnictwa plików i baz danych itp.

Ciasto jest teraz aktualizowane do wersji 2.0. Wydaje się, że nie ma realnej ścieżki migracji do aktualizacji. Konwencje nazewnictwa plików zmieniły się radykalnie i porzuciły SimpleTest na rzecz PHPUnit.

Zmusi nas to do pozostania w gałęzi 1.3, ponieważ, chyba że istnieje jakieś narzędzie do konwersji, nie będzie możliwe aktualizowanie Cake, a następnie stopniowe ulepszanie naszego starszego kodu, aby czerpać korzyści z nowej struktury Cake . Tak więc, jak zwykle, skończymy ze starym frameworkiem w naszym repozytorium Subversion i po prostu załatamy go w razie potrzeby.

I to mnie za każdym razem dostaje. Tak wiele produktów o otwartym kodzie źródłowym nie ułatwia aktualizacji projektów na ich podstawie. Kiedy deweloperzy zaczną bawić się nową błyszczącą zabawką, na starszych gałęziach zostanie wprowadzonych kilka krytycznych poprawek, ale większość ich uwagi skupi się na nowej podstawie kodu.

Jak radzisz sobie z radykalnymi zmianami w projektach open source, których używasz? A jeśli opracowujesz produkt typu open source, czy pamiętasz o ścieżkach aktualizacji podczas opracowywania nowych wersji?

Problem nie dotyczy wyłącznie oprogramowania typu open source. Te same problemy występują w przypadku projektów komercyjnych. Może nawet bardziej, ponieważ nie masz źródła, możesz utrzymać się, jeśli firma przestanie wspierać.

Projekty typu open source typu końcowego użytkownika mają szybkie cykle aktualizacji, a stare wersje bardzo szybko tracą wsparcie. Z drugiej strony projekty, które zostały zaprojektowane tak, aby użytkownicy włożyli znaczny wysiłek w kodowanie, mają zwykle długie cykle wsparcia starej gałęzi po dużej aktualizacji. Wystarczająco długo, abyś nie spieszył się, czekając, aż ustabilizuje się i dojrzeje, a następnie migrując i gruntownie testując własny kod.

Oparcie się pokusie posiadania najnowszych i najlepszych może być trudne, ale należy pamiętać, że w oprogramowaniu istnieje fundamentalny kompromis między stabilnością a nowymi funkcjami. Nie możesz mieć jednego bez poświęcenia drugiego. Właśnie dlatego istnieją gałęzie naprawiające błędy, dzięki czemu możesz wybrać, która strona spektrum najlepiej odpowiada Twoim potrzebom.

Rozwiązaliśmy ten problem, modulując nasz kod.

Nasza podstawowa strona internetowa została zbudowana około osiem lat temu i mieliśmy szczęście, że została zbudowana przez jednego z pierwszych współpracowników Spring Framework, więc była to całkiem dobrze zbudowana podstawa. Ale niestety mieliśmy również pecha, że ​​ten programista postanowił rozwidlić Springa po sporze o kierunek, w którym się on zmierza, więc ta podstawa kodu utknęła teraz w nieobsługiwanym rozwidleniu Spring 1.1.4 (lub coś w tym stylu).

Próbowaliśmy przepisać kod, aby przejść do nowych wersji Springa, ale okazało się to niezwykle trudne. Dlatego naszym rozwiązaniem było rozpoczęcie budowy nowych funkcji witryny jako modułów w całkowicie oddzielnej aplikacji, przy użyciu najnowszych platform, takich jak Spring 3.x, Hibernate 3.6 itp.

Teraz mamy dwie aplikacje internetowe działające pod tym samym podstawowym adresem URL i używamy modułu mod_proxy Apache do przydzielania każdej ścieżki do odpowiedniej aplikacji. Na przykład „/ członkowie” przechodzą do starej aplikacji, a „/ katalogi” do nowej aplikacji. Jednak odwiedzający witrynę nie miałby pojęcia, że ​​korzysta z różnych aplikacji; wyglądają dokładnie tak samo dla użytkownika.

Dwie aplikacje muszą się komunikować, na przykład gdy członek loguje się na stronie (za pomocą naszej nowej aplikacji), musimy powiadomić starą aplikację, że są teraz zalogowani. Robimy to za pomocą prostej usługi internetowej, narażonej tylko na działanie Lokalny Gospodarz. Wymagana integracja obu aplikacji okazała się minimalna.

Ważną częścią tej pracy było zidentyfikowanie i spakowanie wspólnych zasobów. Tak więc cały tekst statyczny, grafika, arkusze stylów, JavaScript i szablony zostały przeniesione z oryginalnej aplikacji do osobnego - trzeciego projektu, z którego korzystają zarówno nowe, jak i stare aplikacje. Zapewnia to, że obie aplikacje internetowe wyglądają i działają w ten sam sposób, nawet jeśli są całkowicie oddzielne.

Wyobrażam sobie, że z czasem będziemy zamieniać coraz więcej oryginalnej aplikacji, aż w końcu będzie zupełnie niepotrzebna. Zaletą tej techniki jest to, że możemy to robić powoli poprzez serię niewielkich zmian o niskim ryzyku - nie ma potrzeby masowego i ryzykownego nagłego przejścia na nowy system.

Nie zawsze to robię. Wiele projektów typu open source ma aktywne gałęzie obsługi dla poprzednich głównych wydań. Czasami są one utrzymywane przez ludzi, którzy potrzebują tej wersji do utrzymania. Wiele projektów pozostaje w fazie głównej, dopóki same nie będą gotowe do wydania głównego.

I to mnie za każdym razem dostaje.

Za każdym razem? Musisz dokonywać wyjątkowo złych wyborów. Musi być jeden przykład, w którym tak się nie stało.

Gdy deweloperzy zaczną bawić się nową błyszczącą zabawką

To wskazówka. Unikaj błyszczących nowych zabawek podczas korzystania z projektów open source. Unikaj wydania 1.0.

Jak radzisz sobie z radykalnymi zmianami w projektach open source, których używasz?

Krok 1. Wybierz projekty open source bardzo, bardzo ostrożnie. Zawsze porównuj dwa lub więcej konkurujących projektów.

Krok 2. Porównując dwa konkurujące ze sobą projekty, spróbuj zrozumieć „istotną” oferowaną funkcję i sposób, w jaki oba do niej podchodzą. Unikaj „poślubiania” jednego konkretnego interfejsu API zbyt wcześnie.

Krok 3. Zastosuj zasady projektowania „Late Binding” i „Loose Coupling”. Spróbuj odizolować się od zmian w projektach typu open source.

Krok 4. Wyraźnie porównaj koszty / korzyści między projektami typu open source a „rozwijaniem własnych”. Od czasu do czasu tworzenie własnego rozwiązania może być lepsze niż radzenie sobie z rozwiązaniem typu open source.

Zmiana nazw plików nie powinna być zbyt trudna. Tak, to duży, brzydki scenariusz. Tak, należy go uruchomić przez kilka tygodni podczas konwersji. Ale to skończony koszt.

Jeśli tak się stanie za każdym razem, opracuj lepsze strategie radzenia sobie. Ponieważ twoja obserwacja prawdziwego świata jest taka, że ​​zawsze tak się stanie, to nadzieja na prawdziwy świat naprawdę niewiele pomoże. Masz trochę trudnego doświadczenia w zmianie. Wykorzystaj to. Potraktuj to jak infekcję i wykształć własną odpowiedź immunologiczną.