Artykuł

freeimages.com freeimages.com
kwi 02 2017
0

W pogoni za stabilnym stosem technologicznym

W programowaniu często mówi się o tym, że trudno jest napisać idealny kod. Wielu (w tym ja) uważa, że jest to niemożliwe, a na pewno nie za pierwszym razem. Zawsze powinniśmy być przygotowani na refaktoring i nie powinniśmy go traktować jako coś złego, tylko jako naturalny element procesu. Nie mniej jednak jeśli weźmiemy pod uwagę mnemonik SOLID i dokładnie zapoznamy się z jego regułami, to szybko okaże się, że tak naprawdę pole do zmian jest częściowo ograniczone.

Jeszcze inaczej sprawa ma się jeśli spojrzymy na języki programowania, bądź też znane frameworki. Czy w takiej sytuacji zmiana jest dozwolona? Czy powinniśmy zachowywać kompatybilność wsteczną? Temat jest trudny, a zachowanie dużych graczy pokazuje, że nie boją się oni często poważnych zmian. O ile refaktoryzacja własnego projektu dotknąć może stosunkowo nieduże grono odbiorców, o tyle zmiany w języku/technologii, mogą dotknąć setki tysięcy programistów, w zależności od popularności analizowanego rozwiązania. Taka sytuacja rodzi wiele pytań, na które trudno znaleźć jednoznaczne odpowiedzi, ale spójrzcie na kilka poniższych przypadków, by uzmysłowić sobie skalę problemu.

.Net Core od Microsoftu

.Net Core to stosunkowo nowe rozwiązanie Microsoftu, które docelowo ma stać się wiodącą technologią do tworzenia stron WWW w świecie giganta z Redmond. Z założenia .Net Core jest szybki, lekki i multiplatformowy. W ubiegłym roku doczekaliśmy się wersji stabilnej tego rozwiązania, którego rozwój był bardzo burzliwy. Jednym istotnym problemem, z którym Microsoft długo nie mógł dojść do ładu, była kwestia organizacji projektów.

Przez długie lata w użyciu był bardzo złożony plik csproj używany przez MSBuild. Przy okazji prac wstępnych nad .Net Core oraz .Net Standard Library pojawił się project.json, który jednak nie wytrwał zbyt długo. Nie doczekał on nawet do stabilnej wersji .Net Core, ponieważ niedługo przed wydaniem został zastąpiony, nowym, uproszczonym plikiem csproj... Historia zatoczyła koło.

Rozwiązania mobilne od Microsoftu

Kolejny przykład, również ze stajni Microsoftu, to rozwiązania mobilne tego giganta. Sporo mówi się na ten temat w kontekście porażki, którą firma z Redmond ewidentnie poniosła na rynku mobilnym. Powodów takiego stanu rzeczy jest wiele. Jednym z nich jest zbyt późne wejście na rynek mobilny, ale sporo mówi się też o samej technologi. Gdy Windows Phone pojawiał się na rynku w wersji 7, do tworzenia aplikacji wykorzystywany był Silverlight. Ten przetrwał przez kilka mniejszych wersji, aż do 8.1 gdy w świecie MS zaczęły pojawiać się tzw. aplikacje uniwersalne. Te również nie wytrzymały zbyt długo, ponieważ w wyniku mutacji w Windows 10 zostały przetransformowane na Universal Windows Platform.

Pomiędzy tymi wszystkimi wariacjami było trochę elementów wspólnych, jednak mimo wszystko przy każdej kolejnej wersji programiści musieli się uczyć sporej ilości nowych elementów co przy niskim udziale w rynku jeszcze bardziej zniechęcało programistów do tworzenia aplikacji na ten system i Microsoft wpadał w błędne koło.

Kolejne wersje języka Swift od Apple

W świecie Apple również lubią zmiany. Jakiś czas temu w Cuppertino wprowadzili język programowania Swift, który z założenia ma być alternatywą dla bardziej złożonego Objective-C. I tak w istocie jest, aczkolwiek również w tym przypadku programiści nie mają łatwo. Swift 2 wprowadził sporą ilość nowych funkcji. Swift 3 wyprostował nazewnictwo klas (z wielu miejsc poznikały prefiksy NS) oraz dodał kolejne nowości. Największe zamieszanie wprowadziła wersja 3, zwłaszcza dla osób, które miały napisany kod w poprzedniej wersji języka, ponieważ nie było w tym przypadku mowy o kompatybilności wstecznej. Na szczęście pewne możliwości refaktoryzacji zostały zapewnione przez XCode.

Czy i kiedy zmieniać?

Wszystkie powyższe przypadki oraz wiele innych o których tutaj nie wspomniano, rodzą dwa zasadnicze pytania - czy i kiedy zmieniać technologię. Tak naprawdę jeśli mamy do czynienia z firmą wytwarzającą oprogramowanie oraz jej produktami, to odpowiedź jest dużo bardziej skomplikowana. Dla takiej firmy adaptacja technologi/rozwiązania, które w wersji stabilnej dostępne jest dopiero od kilku miesięcy, może być bardzo niebezpieczna i kosztowna. Dlatego takie zmiany najczęściej wprowadzane są w sytuacji kiedy wymusza to rynek (np. nowa wersja języka wspiera nową wersję systemu mobilnego), lub w sytuacji gdy technologia jest już dobrze wygrzana tzn. została zaadaptowana i sprawdzona przez early adopters.

I choć programiści zawsze chętnie zainstalowali by najnowszą wersję, to z biegiem lat osobiście zaczynam dostrzegać tą drugą stronę medalu, która poszukuje stabilności, a tą nie zawsze idzie znaleźć w pierwszych miesiącach, a czasem nawet dłużej...

Podoba Ci się ten wpis? Powiedz o tym innym!

Send to Kindle

Komentarze

blog comments powered by Disqus