AS
Kontakt

Przegląd i naprawa projektu Unity

Problemy z projektem Unity? Dowiedz się, co trzeba naprawić.

Przejmujesz projekt Unity, straciłeś poprzedniego programistę lub gra albo aplikacja przestała działać? Sprawdzam kod źródłowy, sposób uruchomienia projektu i urządzenia, na których występują problemy, a następnie wyjaśniam, co trzeba naprawić. Możesz przekazać raport swojemu zespołowi lub uzgodnić naprawy ze mną.

Omów swój projekt Zobacz ocenę
20–40hTypowa pierwsza ocena
Najpierw kompilacjaDowody przed obietnicami
NDAPrzed dostępem do materiałów poufnych
Praktyczna pracaDostępne działania naprawcze

Kiedy zacząć tutaj

Projekt istnieje. Pewności brak.

Przegląd pomaga, gdy trzeba zdecydować, co naprawić lub rozwinąć w następnym kroku, ale nie masz jeszcze wiarygodnego obrazu stanu projektu.

Projekt został przejęty

Zmieniły się osoby odpowiedzialne, dokumentacja jest niepełna, a rzeczywista mapa zależności pozostaje niejasna.

Kompilacja jest krucha

Projekt działa na jednym komputerze, zawodzi w CI lub zależy od nieudokumentowanej lokalnej konfiguracji i ręcznych kroków.

Wydajność blokuje wydanie

Czas klatki, pamięć, ładowanie, awarie lub zachowanie na konkretnych urządzeniach wymagają diagnozy opartej na dowodach.

Integracje wciąż się psują

Połączenia z usługami serwerowymi, narzędziami zewnętrznymi, funkcjami telefonu, Steam lub urządzeniami VR stale powodują problemy podczas przygotowywania aktualizacji.

Zmiany mają nieprzewidywalne skutki

Silnie sprzężone systemy sprawiają, że drobne poprawki są kosztowne i podatne na regresje.

Plan opiera się na domysłach

Przed zwiększeniem nakładu pracy zespół potrzebuje uzasadnionej decyzji: dokończyć, zrefaktoryzować czy przebudować.

Konkretne rezultaty pracy

Sprawdź, co działa. Zdecyduj, co naprawić.

Ocena jest zorganizowana wokół decyzji właściciela produktu i kolejnych działań zespołu inżynierskiego.

  1. 01

    Co działa i co uniemożliwia uruchomienie projektu

    Stan kompilacji, informacje o środowisku i jasno zapisane blokady.

  2. 02

    Mapa architektury

    Główne systemy, zależności, granice odpowiedzialności i krytyczne sprzężenia.

  3. 03

    Rejestr ryzyk według priorytetów

    Ustalenia uporządkowane według wpływu, prawdopodobieństwa i pilności dla wydania.

  4. 04

    Ustalenia dotyczące wydajności i integracji

    Zmierzone dowody z właściwej platformy, urządzenia lub gogli.

  5. 05

    Kierunek techniczny

    Uzasadniona rekomendacja: dokończyć, zrefaktoryzować czy przebudować, a nie odruchowo przepisywać.

  6. 06

    Plan napraw podzielony na jasne etapy

    Etapy, kryteria odbioru, zależności i przydatne kolejne decyzje.

Przegląd skupia się na najważniejszych uzgodnionych pytaniach. W ciągu 20–40 godzin nie można znaleźć każdego błędu w dużym istniejącym projekcie, dlatego raport wyjaśnia też, co sprawdzono i co pozostaje niepewne.

Jak przebiega ocena

Poznaj zakres pracy, zanim zainwestujesz w naprawy.

  1. 01

    Brief i dostęp

    Doprecyzuj produkt, platformę docelową, obecną blokadę i kryteria sukcesu. W razie potrzeby uzgodnij NDA przed udostępnieniem repozytorium.

  2. 02

    Sprawdzenie, czy projekt działa

    Uruchom projekt, odtwórz problem i udokumentuj rzeczywistą ścieżkę kompilacji, zanim złożysz obietnice dostarczenia produktu.

  3. 03

    Inspekcja i pomiar

    Prześledź architekturę, zależności, przepływ danych, integracje i wydajność na właściwej platformie docelowej.

  4. 04

    Decyzje i kolejność

    Rekomendacja, co naprawić najpierw, wyjaśnienie możliwości i propozycja niewielkiego pierwszego zakresu prac na podstawie ustaleń.

Kluczowa decyzja

Dokończyć, zrefaktoryzować czy przebudować?

Odpowiedź powinna wynikać z ograniczeń produktu i dowodów, nie z gustu, paniki lub poniesionych kosztów.

Dokończ01

Zachowaj działający rdzeń.

Gdy architektura nadaje się do użytku, skup wysiłek na blokadach, walidacji i lukach krytycznych dla wydania.

Refaktoryzacja02

Poprawa części, które powodują problemy.

Gdy konkretne moduły tworzą ryzyko, izoluj i naprawiaj je bez destabilizowania całego produktu.

Przebuduj03

Stosuj tylko wtedy, gdy potwierdzają to dowody.

Przepisanie staje się uzasadnione dopiero wtedy, gdy obecna struktura nie może zapewnić wymaganego rezultatu produktu.

Odpowiednie dowody

Doświadczenie w dostarczaniu produktów stojące za oceną.

Decyzje architektoniczne opierają się na praktycznym dostarczaniu wydanych gier PCVR, produkcyjnego oprogramowania mobilnego i gier o rozbudowanych systemach.

Wydana gra PCVR na Steam

Reach The Beat

Jedyny inżynier Unity i osoba odpowiedzialna technicznie za architekturę, rozgrywkę i systemy XR, narzędzia, kompilacje, weryfikację sprzętu oraz wydanie.

Zobacz potwierdzenie na Steam

Produkcyjne Android / iOS

Poufny produkt mobilny

Jedyny inżynier klienta Unity i architekt mobilny dla złożonego UI, przepływów zależnych od backendu, weryfikacji na urządzeniach i integracji natywnych.

Tożsamość produktu nieujawniona · Zgodnie z NDA

Gry o rozbudowanych systemach

Powiązane systemy produktu

Architektura i realizacja progresji, zapisu, lokalizacji, analityki oraz systemów treści sterowanych danymi.

5+ lat komercyjnej pracy z Unity · publiczna ocena Upwork 5.0

Pytania przed udostępnieniem dostępu

Jasne pierwsze kroki.

01Czy możesz przejąć istniejący lub porzucony projekt Unity?

Tak. Najpierw sprawdzam, czy projekt działa, przeglądam kod i ustalam, co można naprawić lub wykorzystać ponownie. Rekomenduję pierwszy krok przed wyceną większego zakresu prac.

02Jakiego dostępu potrzebujesz?

Do samej oceny zwykle potrzebne są repozytorium, wersja Unity, reprezentatywna kompilacja, dostępna dokumentacja oraz dostęp do platformy docelowej lub informacje o sprzęcie. Zacznij od ogólnego opisu. NDA można uzgodnić przed przekazaniem wrażliwych szczegółów lub dostępu do repozytorium.

03Czy ocena wskaże, co dokończyć, zrefaktoryzować lub przebudować?

To jeden z głównych celów. Rekomendacja wiąże się z dowodami, ograniczeniami produktu, ryzykiem realizacji i definicją sukcesu, nie z ogólną preferencją przepisywania.

04Czy możesz zrealizować plan po audycie?

Tak. Twój zespół może skorzystać z raportu albo możemy osobno uzgodnić naprawy, wybrane poprawki kodu, wydajności, połączeń z usługami lub przygotowanie do wydania. Przegląd nie zobowiązuje Cię do dalszych prac.

05Jaki zakres ma pierwsze zlecenie?

Zaczynamy od płatnego przeglądu. Przy przejętym projekcie lub niejasnych problemach odpowiednie może być 20–40 godzin. Przed rozpoczęciem uzgadniamy liczbę godzin, cenę, główne pytania i raport. Otrzymasz opis tego, co działa lub uniemożliwia uruchomienie projektu, najważniejsze ryzyka i propozycję pierwszego etapu napraw. Prace programistyczne wyceniam osobno.

Zacznij od blokady

Opowiedz, co wciąż się psuje.

Ograniczony budżet? Podaj swój priorytet i kwotę, z którą czujesz się komfortowo. Jasno powiem, jaki pierwszy krok jest realny.

Poufność od pierwszej rozmowy

Zliczam działania kontaktowe wyłącznie zbiorczo, bez identyfikatorów odwiedzających i treści wiadomości.

Skontaktuj się ze mną bezpośrednio

Potrzebujesz innego rodzaju pomocy?

Wszystkie usługi

Zbuduj grę

Tworzenie gier

Stwórz aplikację inną niż gra

Tworzenie aplikacji

Rozwijaj produkt dalej

Lider techniczny Unity w niepełnym wymiarze

Przywróć i ponownie przetestuj produkt

Aktualizacje i utrzymanie starszych projektów Unity

Połącz AI z rzeczywistym procesem pracy

Integracje AI i próby z prywatną AI

Połączmy potrzebne kompetencje

Tworzenie ze specjalistami od grafiki, dźwięku, projektowania i testów

Sprawdź jakość przed kolejnym krokiem

Testowanie oprogramowania