Concord nie skradł serc użytkowników Steam. Nikłe zainteresowanie strzelanką od Firewalk Studios

Yosar napisał:

Piękna teoria. Każdego programistę jej uczą. Niestety rzeczywistość działa trochę inaczej. Takich twoich zmian jest 100, i każda realizowana równocześnie. Bo żadna firma sobie nie pozwoli na to, żeby je realizować jedna po drugiej, za duży koszt i za dużo czasu. Zatem przetestowaliśmy tą jedną zmianę, jesteśmy dumni, wyciągamy pierś po ordery, poszło na produkcję i kaboom. Nie działa. Albo gorzej, działa źle. Ale jak to? Przecież wszyscy się podpisali. I review było, i QA zrobiło testy (notabene przeważnie takie jakie powie programista że trzeba zrobić, bo na budowanie statku z dziurą w środku to QA nie ma czasu) i miało być taki pięknie, a wzięlo i się zrypało.

Jeżeli tak myślisz to albo nie pracowałeś przy poważnych projektach, albo nie masz nic wspólnego z oprogramowaniem albo dotychczas pracowałeś w patologicznych firmach zarządzanych przez durni. 

Kod projektu jest dzielony na gałęzie. Każda gałąź jest samodzielna. Więc zmiany innych nie wpływają na moje kiedy nad nimi pracuje. Następnie zanim dołączę moje zmiany, muszę mieć napisane testy, potwierdzenie od 2 osób i zatwierdzenie od QA że działa. 

Jeżeli zmieniam kod kogoś innego bo np. wykryliśmy tam błąd, zaczynam od testu który ma od teraz testować tę ewentualność. Też będę myślał o innych dokładając testy. Bo ewidentnie programista o czymś nie pomyślał. Generalnie zmiana logiki na ogół albo wymaga nowych testów jeżeli rozszerzamy możliwości albo poprawę obecnych. 

Dodatkowo na projekcie odpalają się testy automatyczne które potwierdzają działanie projektów jako całości. I zawsze przed wgraniem tego kodu po wszystkich potwierdzeniach, zawsze dogrywam główną gałąź do mojej, wciągając zmiany wszystkich i upewniając się że moje niczego nie psują i dalej działają.

Bywa że inny programista pracuje w tym obszarze co ja ale objawia się tak że jest zmiana na głównej gałęzi którą zrobił i moja w tym samym pliku. Dostaje informacje o konflikcie i muszę rozwiązać to tak by jego i moja zmiana działały. Jeżeli mam wątpliwości, to człowiek który zrobił te zmiany pomaga mi je rozwiązać. 

Wtedy ta zmiana trafia do głównej gałęzi.

A przed wypuszczeniem, rzeczy które nie są zautomatyzowane są też sprawdzane manualnie, znaczy ręcznie. 

Także żeby cokolwiek trafiło do klienta na produkcje z tak oczywistym błędem jak te Bethesdy, musiało by to przejść przez kilka warstw zabezpieczeń w postaci procedur. 

A gdyby coś jednak się prześlizgnęło - to wtedy robimy rewizję całego procesu szukając przyczyny. Bo czasem zawini proces a czasem ludzie. Np. jak programista zrobi kiepski code review to będzie traktowany jak junior. Tzn. nie będzie mógł robić code review jak również jego praca może być pod nadzorem seniora jeżeli naprawdę spieprzył. 

Ano się zrypało, bo jedna zmiana zrobiła to, a druga zmiana np zmieniła dane, które podawane są pierwszej zmianie itd itp i milion innych powodów błędów. I już nie działa, albo działa nieobliczalnie. Nie ma takiej możliwości, żeby wszystkie zmiany we wszystkich możliwych kombinacjach przetestować. I wie o tym każdy kto zetknął się z poważniejszym oprogramowaniem niż kalkulator.

Bawi mnie to porównanie bo to właśnie kalkulator jest trudny do przetestowania bo matematyka nie ma końca. Dlatego kalkulatory testuje się tylko do pewnego poziomu dokładności określonego przez sprzęt. 

To ile możesz przetestować zależy od tego jak użytkownik wchodzi w interakcję z grą. Im bardziej jest to skomplikowane tym trudniej się testuje. 

Ale testy automatyczne pokrywają zawsze typowe przypadki użycia jako absolutne minimum. Tzn to co zaplanowałeś by w grze było.

 Dodatkowo wybacz ale ja rozumiem że ktoś nie przetestował sytuacji gdzie za pomocą glitcha gracz się rozpędził i dał radę przeniknąć przez ścianę w grze. Albo dał radę oszukać algorytm który reaguje jak przenikniesz częściowo przez ścianę i ten zamiast na zewnątrz - wsadza Cię do wnętrza ściany. 

Ale mówimy tu o sytuacji gdzie każda planeta w grze miała placeholder jako teksturę. Placeholder który był kolorowy, jaskrawy, idealnie po to by dać się od razu zauważyć. 

Żeby ty wykryć wystarczyło uruchomić grę i spojrzeć na mapę. 

W swoim życiu widziałem już jak najbardziej doświadczeni programiści robili najprostsze fakapy (np. nie usunięcie danych testowych z oprogramowania przed oddaniem na produkcje).

I nie powinno mieć to znaczenia bo dane testowe są tylko na testowych środowiskach. 

Jedyna alternatywa dla tego to umieszczenie ich w kodzie. A wtedy powinny być zauważone przez code review albo testerów. 

Co oznacza że jedno i drugie zawiodło. A to oznacza że to jakaś patologiczna firma która udaje dobre praktyki.

Więc nie śpieszyłbym się tak z oskarżaniem innych o lenistwo i inne gorsze rzeczy. Bo to raczej świadczy przede wszystkim o braku wyobraźni oskarżającego.

Nie. To świadczy o doświadczeniu oskarżającego. Karierę zaczynałem w firmach na zadupiu, na podkarpaciu gdzie tego typu patologii było mnóstwo. Np. firma robiąca online księgarnie gdzie klient tracił 20,000zł zarobku z weekendu bo pracownik spieprzył koszyk zakupowy w piątek. I nikt tego nie wykrył do poniedziałku bo właściciel strony był na wakacjach. W tej firmie programiści spędzali 50% czasu naprawiając błędy które sami stworzyli bo właściciel firmy uważał że testowanie to ekstra koszt i jak nie będzie tego robił to będzie świadczył tańsze usługi niż konkurencja.

No a jak taniej to lepiej prawda? Oczywiście ten sam człowiek zastrzegał że woli swój framework zamiast jakiegoś popularnego, przetestowanego ze społecznością bo "przynajmniej wie co się w nim dzieje". Ten framework oczywiście nie miał żadnych testów. 

Przekopałem się przez patologiczne firmy Januszy i w niektórych nawet udało mi się wprowadzić praktykę testowania i code review z dużym sukcesem. 

Tak samo w jednej gdzie nie potrafili pracować z gałęziami, jak ich nauczyłem jak to robić to dosłownie szefostwo zauważyło to w wynikach finansowych firmy i chcieli mnie zrobić dyrektorem. 

Ale moment jak zacząłem pracować przy projektach które nie robią setek tysięcy przychodu tylko setek milionów - patologie się skończyły. Wiesz dlaczego? 

Bo jeden fuckup generuje takie straty że dosłownie NIC nie jest w stanie ich pokryć. Oszczędzanie na dobrych praktykach czy architekturze czy infrastrukturze prowadzi tylko i wyłącznie do utraty pieniędzy. 

I tam kończy się januszowanie. Wg mnie firma jak Bethesda w teorii powinna dawno skońćzyć januszować ale w praktyce - wychowali swoich fanów tak że ci nie tylko to tolerują ale jeszcze ich bronią. 

Błędy w oprogramowaniu mają tak różne źródła, czasem tak absurdalne, że zakładanie czegokolwiek przy ich analizie kończy się przeważnie rozbiciem nosa i nie dojściem przyczyny prawdziwej.

Nieprawda. Każdy błąd da się wyśledzić. Na ogół jeżeli jest z tym problem to znaczy że albo oprogramowanie jest źle zaprojektowane albo ma niewystarczające logowanie. Bo wszystko co robisz bazuje na danych i w którymś momencie masz złą wartość. I trzeba tylko sprawdzić co ją policzyło i dlaczego źle. 

A czasem trzeba problem po prostu ominąć. Jak np. kiedy przyczyną jest architektura dzisiejszych procesorów i języka programowania. Np. w przeglądarce masz JavaScript. Jak otworzysz konsolę przeglądarki i podasz 

(0.7 + 0.1) === 0.8

to konsola zwróci Ci że lewa strona nie jest równa prawej. A to wynika z tego że składowanie ułamków w postaci binarnej jest trudne dla dzisiejszych procesorów. 

A co do budowania statku z dziurą w środku każda normalna firma potraktowałaby to jako przypadek brzegowy, i gdyby na jednej szali położyć taki przypadek, a na drugiej przerabianie i testowanie od początku całej mechaniki walki, która została już przetestowana  i oddana innym działom do użytku, to nikt przy zdrowych zmysłach nie brałby się za łatanie dziury w środku.

Tylko że musisz sprawdzić przypadki brzegowe np. żeby się upewnić że statek normalnie ląduje na lądowiskach. Np. co się stanie jak statek będzie maksymalnie szeroki. Co się stanie jak będzie maksymalnie wysoki. 

A jeżeli ktoś by testerowi prawidłowo opisał działanie algorytmu celowania w gracza to normalny QA sprawdził by to na 100%. Wiesz dlaczego? Bo tak właśnie działają. Myślą jak gracze bo mają zapewnić jakość dla graczy. 

A gracze wpadli na to w pierwszyc dniach. 

Dodatkowo możesz próbować wytłumaczyć sytuacje ze statkiem ale serio - brakujące tekstury na planetach na mapie zaraz po starcie gry? To chcesz wytłumaczyć? Bo to się da tylko w jeden sposób wytłumaczyć. Nikt nie uruchomił gry przed wysłaniem aktualizacji do graczy.

Smoków latających do tyłu czemu nie zauważyli? 

A tego że jak patrzysz w dół w F76 i biegniesz szybciej? Coś co gracze od razu wyłapali. 

Bądźmy szczerzy - Bethesda nie testuje swoich produktów. 

dariuszp napisał:

To jest kwestia lenistwa. Wiesz jak by to wyglądało w normalnej firmie?

...

Więc jeżeli np. na produkcję trafiły planety które nie mają tekstur, smoki latające do tyłu czy algorytm strzelania do statku który nie celuje w kokpit gdzie gracz siedzi tylko w środek konstrukcji nawet jeżeli nic tam nie ma to oznacza że po tym jak ktoś z devów zrobił zmianę, nikt jej nie zatwierdził. I nikt jej nie przetestował. Nikt też nie sprawdził produktu przed wysłaniem go do graczy jak już została zrobiona nowa wersja. Tzn wszyscy oddali co był odo zrobienia. 

Piękna teoria. Każdego programistę jej uczą. Niestety rzeczywistość działa trochę inaczej. Takich twoich zmian jest 100, i każda realizowana równocześnie. Bo żadna firma sobie nie pozwoli na to, żeby je realizować jedna po drugiej, za duży koszt i za dużo czasu. Zatem przetestowaliśmy tą jedną zmianę, jesteśmy dumni, wyciągamy pierś po ordery, poszło na produkcję i kaboom. Nie działa. Albo gorzej, działa źle. Ale jak to? Przecież wszyscy się podpisali. I review było, i QA zrobiło testy (notabene przeważnie takie jakie powie programista że trzeba zrobić, bo na budowanie statku z dziurą w środku to QA nie ma czasu) i miało być taki pięknie, a wzięlo i się zrypało.

Ano się zrypało, bo jedna zmiana zrobiła to, a druga zmiana np zmieniła dane, które podawane są pierwszej zmianie itd itp i milion innych powodów błędów. I już nie działa, albo działa nieobliczalnie. Nie ma takiej możliwości, żeby wszystkie zmiany we wszystkich możliwych kombinacjach przetestować. I wie o tym każdy kto zetknął się z poważniejszym oprogramowaniem niż kalkulator.

W swoim życiu widziałem już jak najbardziej doświadczeni programiści robili najprostsze fakapy (np. nie usunięcie danych testowych z oprogramowania przed oddaniem na produkcje).

Więc nie śpieszyłbym się tak z oskarżaniem innych o lenistwo i inne gorsze rzeczy. Bo to raczej świadczy przede wszystkim o braku wyobraźni oskarżającego.

Błędy w oprogramowaniu mają tak różne źródła, czasem tak absurdalne, że zakładanie czegokolwiek przy ich analizie kończy się przeważnie rozbiciem nosa i nie dojściem przyczyny prawdziwej.

A co do budowania statku z dziurą w środku każda normalna firma potraktowałaby to jako przypadek brzegowy, i gdyby na jednej szali położyć taki przypadek, a na drugiej przerabianie i testowanie od początku całej mechaniki walki, która została już przetestowana  i oddana innym działom do użytku, to nikt przy zdrowych zmysłach nie brałby się za łatanie dziury w środku.

GThoro napisał:

To nie kwestia lenistwa, to pokazuje, że poszczególne działy w Bethesdzie ze sobą nie współpracują.

dariuszp napisał:

Ale najlepsze jaja od Bethesdy to był fakt że przez czyste lenistwo sobie zaprogramowali że przeciwnik strzela w sam środek Twojego statku. Więc ktoś zbudował statek z dziurą w środku. I jest nieśmiertelny bo wszyscy przeciwnicy strzelają przez tę dziurę.

To jest kwestia lenistwa. Wiesz jak by to wyglądało w normalnej firmie?

Kiedy robię zmianę w oprogramowaniu albo tworzę nowe - 2 inne osoby przeglądają i zatwierdzają to co zrobiłem. Tzw. code review. Bo programiści sami sobie nie ufają.

Nasze algorytmy mają testy jednostkowe. Wrzucamy parametry do tych algorytmów mówiąc jaki efekt się spodziewamy. I również wrzucamy nieprawidłowe parametry by udowodnić że program się psuje w przewidywany sposób, np. wyrzucając wyjątek. 

Następnie to co zrobiliśmy trafia do działu Quality Assurance. To dział który zawiera często mniej techniczne osoby które patrzą na produkt rozsądnym okiem. I przede wszystkim próbują zepsuć to co zrobiliśmy. 

Następnie jak 2 osoby się podpisały pod tym co zrobiłem mówiąc że jest OK a dział QA stwierdza że to co zrobiłem działa i ma jakość której klient oczekuje - moja zmiana trafia do głównego kodu.

Ten główny kod jako całość jest ponownie testowany zanim pójdzie do klienta. W tym wypadku graczy. 

Więc jeżeli np. na produkcję trafiły planety które nie mają tekstur, smoki latające do tyłu czy algorytm strzelania do statku który nie celuje w kokpit gdzie gracz siedzi tylko w środek konstrukcji nawet jeżeli nic tam nie ma to oznacza że po tym jak ktoś z devów zrobił zmianę, nikt jej nie zatwierdził. I nikt jej nie przetestował. Nikt też nie sprawdził produktu przed wysłaniem go do graczy jak już została zrobiona nowa wersja. Tzn wszyscy oddali co był odo zrobienia.