Zaklej sobie plastrem
Rozbawiła i jednocześnie zasmuciła mnie pewna sytuacja, której byłem świadkiem. Znajomy zainstalował sobie publiczną betę iOS 9. Podkreślmy to słowo – betę. Ów śmiałek zauważył podczas naszego spotkania, że jeden z widgetów, nie wyświetla się tak, jak powinien, czytaj – jak wyświetlał się na iOS 8.4. Fakt, widget się rozsypywał. Ot, pierwszy problem pierwszego świata. Z Konradem była wówczas jego narzeczona, która słysząc narzekania zagorzałego macusera, podsumowała go w epickich słowach: „Jak Ci się nie podoba, Konradzie, to sobie zaklej plastrem”.
Tajemnicze wersje
W tym artykule spróbuję rozwiać wątpliwości osób, które nie do końca wiedzą, o co chodzi z tym całym nazewnictwem. Dlaczego coś jest alfa, kiedy coś jest betą i co w ogóle znaczy jakieś RC. Zacznijmy więc od wyjaśnienia sobie, że każdy program komputerowy, a więc też każda aplikacja, którą instalujesz na swoim iUrządzeniu, przechodzi z pewnością przez pięć faz. Jest ich więcej, ale skupię się na tych, o których zapewne co najmniej raz słyszeliście. Postaram się też opisać je jak najprościej, a naszą aplikację przyrównam do budowli, którą wznosimy.
Pre-Alfa — do tej wersji dostęp ma wyłącznie software house, czyli de facto zespół tworzący daną aplikację. Jest to tzw. repozytorium kodu — w skrócie, to taki wielki koszyk, do którego deweloperzy wkładają materiały/części, z których będą budowali aplikację. Od czegoś trzeba zacząć. Gdy w koszyku znajduje się już wystarczająco materiałów, rozpoczyna się budowa: algorytmu (zasady działania aplikacji, jej logiki), interfejsu (najczęściej jeszcze makietowego, czyli pozbawionego finalnej, graficznej warstwy UI), niektórych funkcji, integrowane są serwery usług.
Alfa — w tym momencie budowla jest już przykryta dachem, ściany pobielone, można ją komuś pokazać i ten ktoś nie powinien mieć problemu z rozpoznaniem, że to aplikacja, jaka aplikacja i do czego może służyć. Deweloperzy doprowadzają w tym momencie do tego, że program działa. Co prawda zazwyczaj w ograniczonym zakresie i z bardzo licznymi błędami, ale działa. Do wersji alfa zapraszani są także testerzy z zewnątrz, choć praktyka ta dotyczy zazwyczaj dużych projektów, jak np. Affinity, i raczej nie dotyczy rynku mobile.
Beta — ta faza interesuje nas najbardziej. Jest najistotniejsza z punktu widzenia procesu tworzenia aplikacji i jednocześnie najbardziej niezrozumiana. Po kolei. Beta to moment, gdy budowla jest już prawie w pełni wyposażona, jednakże niektóre prace są wykonywane często w pośpiechu. Wiele rzeczy do siebie nie pasuje, inne sobie wzajemnie przeszkadzają, utrudniając codzienne życie. Sami często nie widzimy, że można coś uprościć, przestawić, wyeliminować. Dlatego do gmachu znajdującego się w tej fazie, zaprasza się gości: beta testerów wewnętrznych i zewnętrznych (publicznych) czy klientów, licząc, że w zamian za gościnę, podzielą się z nami swoimi uwagami. Dokładnie to robi Apple, Microsoft i każda inna firma, która zatrudnia testerów po to, by wyłapywali problemy wieku dziecięcego w trzech, kluczowych aspektach. Pierwszym są nieoczekiwane crashe, czyli momenty, gdy sufit wali nam się na głowę – aplikacja samoczynnie się wyłącza; po prostu przestaje działać. Czasami dzieje się tak za każdym razem, gdy wykonamy jakiś ruch, innym razem winna jest jedna, źle włożona cegła. Druga kwestia to zgodność projektu z planem. Chyba nikt nie chciałby, by na środku jego łazienki nagle stał filar, którego tam nie miało być. Wymagania do projektów aplikacji mobilnych to naprawdę nie są dwie strony A4. Często to dziesiątki, nawet setki takich stron. Tabeli, wykresów, przypadków logicznych. Architekt tworząc plan budowy, bierze pod uwagę przede wszystkim jej funkcjonalność i trwałość. Ponieważ w procesie dewelopmentu nie sposób od razu stworzyć produkt w 100% zgodny z wymaganiami klienta czy zespołu, beta-testerzy są właśnie tymi osobami, które nie mogą, a mają pytać: „A dlaczego to działa tak, skoro to bez sensu? A dlaczego to wyświetla informację taką samą jak tamto?” itd. Trzecia sprawa to wystrój naszej budowli, czyli UI/ UX. Nie jest to najistotniejsza faza, ale w przypadku iOS – jak uczą nas wydarzenia związane z Apple Music – okazuje się niekiedy newralgiczna. Zgodność aplikacji z projektem, a samego projektu z wymaganiami, jakie Apple, Google czy Microsoft stawiają przed software house’ami, czyli tzw. guidelines. Definiują one dopuszczalne proporcje i styl poszczególnych elementów graficznych iOS i Material Design Androida. Nagrody i uznanie branży mobilnej zazwyczaj przypada tym twórcom, którzy potrafią połączyć przydatność i funkcjonalność tak, by zamknęły się one w pięknym interfejsie. To naprawdę trudne wyzwanie. Podobnie jak fakt, że wprowadzenie jednego ulepszenia, często generuje w tej fazie budowy nowy problem. To tzw. regresje. Je również należy wyeliminować i tak do skutku. Do momentu, gdy całość będzie stabilna i użyteczna.
Ilość wersji beta danej aplikacji jest zazwyczaj dwucyfrowa. Warto nadmienić, że nie każde wydanie trafia np. do publicznej bety czy deweloperów. To firma decyduje, które z nich oddać w ręce testerów.
Dlaczego faza beta jest tak istotna? Ponieważ działa w niej prosta zasada. Im więcej niedoskonałości znajdą testerzy, tym lepszy debiut czeka produkt. Aby tak się stało, potrzeba jednak jeszcze jednego czynnika: zaangażowania. O nim oraz o tym, dlaczego warto je mieć, powiem Wam w dalszej części tekstu.
RC — to moment, w którym nasza budowla przeszła już konieczne zmiany, jest bezpieczna, stabilna, a jej użytkownikom nie zagraża niespodziewane niebezpieczeństwo. Jest też zgodna z ostatecznym planem uwzględniającym sugestie z fazy beta. Gdy znajdujemy jakieś drobne odstępstwo od założeń, nie skutkuje to koniecznością wprowadzania radykalnych zmian, a jedynie szukania powodu, przez który to odstępstwo się pojawiło i jego eliminacji.
RTM — to czas, gdy wszystko jest dopięte na ostatni guzik. Produkcja jest uznana za skończoną zarówno przez jej wykonawców, jak i klienta. To ta sama wersja, która trafi na rynek, którą będą odwiedzali użytkownicy i która trafia do akceptacji przez Apple czy Google.
Niekonsekwencja katalizatorem marudzenia
Wróćmy do fazy beta, czyli corocznego momentu siania paniki przez użytkowników wersji beta iOS czy OS X. Przeważnie publicznych wersji beta. Apple po lipcowych przypadkach komentowania (a właściwie wylewania nieświadomych frustracji) aplikacji w App Store, które nie działały pod betą iOS 9 – wyłączyło taką możliwość. Teraz gdy decydujemy się być beta-testerami, nie możemy komentować aplikacji w sklepie. I bardzo dobrze. Przykro jednak czytać co roku te same komentarze, w których osoby świadomie – przynajmniej w teorii – decydujące się pomóc w rozwoju niegotowego produktu, psioczą na niego, jakby podejmowały się testów ideału. Mam wrażenie, że kultura beki przenosi się niestety także tutaj. Każdy jest alfą i omegą, każdy wszystko wie, zawsze to złe Apple, zły Microsoft czy złe Google wszystko psuje. Sposób, aby to zmienić? Wyśmiać. Nie tędy droga.
Wersje beta, a już zwłaszcza publiczne bety, zalecam instalować w dwóch przypadkach. Pierwszy: chcesz to zrobić dla dobra ogółu, w tym siebie, po to, by wersja finalna była jak najbardziej stabilna. Nie, żeby pobawić się nowymi funkcjami, które mają prawo nie do końca działać. Drugi: bierzesz na siebie odpowiedzialność, czyli korzystasz z systemów wysyłania twoich opinii do firmy — w skrócie: raportujesz znalezione błędy. Dopiero potem piszesz o nich na Twitterze i wylewasz smutki. W przypadku Apple do raportowania służy aplikacja Feedback (zarówno iOS, jak i OS X). Niektóre firmy implementują w samych aplikacjach tzw. raportowanie błędów, które polega na tym, że jeżeli aplikacja nagle się wyłączy (tj. zaliczy crash), to po ponownym jej wywołaniu będziemy mogli wysłać deweloperowi raport dotyczący danego błędu. To znacznie ułatwi mu jego zlokalizowanie w kodzie i naprawę. Dlatego proszę Was, wysyłajcie te raporty.
Niezgłaszanie jakichkolwiek błędów, niewysyłanie raportów do deweloperów, bez względu na to, czy znajdziemy błąd w wersjach beta, RC czy nawet RTM, jest działaniem na szkodę ogółu, a więc i naszą.
Idealna aplikacja nie istnieje
Nie istnieje coś takiego jak idealny kod. I bardzo dobrze, bo często błędy wyłapywane przez społeczność i użytkowników nadają lepszy kierunek danemu projektowi. Pamiętajmy o tym, z jednej strony narzekając na zamknięte ekosystemy, w których użytkownik nie ma nic do powiedzenia, a z drugiej nie chce tych swoich racji zgłaszać. Nikt też nie zmusi nikogo do bycia testerem jakiegoś systemu czy aplikacji. Zwłaszcza w przypadku publicznych wersji beta. Jeśli chcesz mieć pewność, że mieszkasz w stabilnej budowli, zostań tam, aż oficjalnie przydzielą Ci nowe lokum. Jeśli chcesz ryzykować, to po coś – aby coś zmienić. I ponosić konsekwencje za chęć dokonania tej zmiany. W przeciwnym razie to technologiczna hipokryzja.
Na koniec jeszcze odniosę się do jednego zjawiska. Coraz częściej w sieci można przeczytać komentarze zarzucające firmom częste aktualizacje oprogramowania. Tego już zrozumieć nie potrafię. Nie potrafię pojąć myślenia, jakie za takim komentarzem stoi. Jeśli firma często aktualizuje oprogramowanie, to nie znaczy od razu, że aplikacja jest do kitu. Znaczy natomiast z pewnością, że firma nie ma Cię użytkowniku w dupie. I to powinieneś docenić.
Będę się bardzo cieszył, jeśli choć kilku osobom ten tekst rozjaśnił nieco w głowie. Jeśli teraz alfa, beta i inne nie będą Ci się kojarzyły z matematyką w szkole i czymś nieogarnionym. Najbardziej jednak chciałbym, abyśmy byli bardziej konsekwentni, a nie tylko marudzili. Marudzeniem jeszcze nikt niczego nie naprawił.
Ten artykuł pochodzi z archiwalnego iMagazine 09/2015
Krzysztof Kołacz
🎙️ O technologii i nas samych w podcaście oraz newsletterze „Bo czemu nie?”. ☕️ O kawie w podcaście „Kawa. Bo czemu nie?”. 🏃🏻♂️ Po godzinach biegam z wdzięczności za życie.