Wolna aplikacja Qt: jak zlecić diagnozę i sprawdzić poprawkę?

Jeśli aplikacja Qt zwalnia lub przestaje reagować, zacznij od odtworzenia konkretnej czynności użytkownika i pomiaru, gdzie znika czas. Dopiero wynik diagnozy pozwala wybrać między zmianą pobierania danych, sposobu działania interfejsu czy wykonywania obliczeń. Zamawiając poprawkę, uzgodnij również, jak sprawdzicie ją na komputerze i danych odpowiadających codziennej pracy.

Dla osoby odpowiedzialnej za produkt ważne jest rozróżnienie dwóch celów: operacja ma zakończyć się szybciej, a aplikacja ma reagować podczas jej wykonywania. Można umożliwić obsługę okna, nie skracając całego importu. Można też skrócić import, pozostawiając okres, w którym użytkownik nie może nic zrobić. Warto ustalić, który problem utrudnia pracę zespołu.

Opisz problem tak, żeby dało się go powtórzyć

Zgłoszenie „program jest wolny” nie wystarcza do wyceny naprawy. Przygotuj opis czynności: od którego kliknięcia zaczyna się oczekiwanie, co użytkownik widzi w tym czasie i po czym rozpoznaje zakończenie. Zapisz wersję aplikacji, system, komputer oraz rodzaj i wielkość danych. Dołącz informację, czy problem występuje zawsze, przy pierwszym uruchomieniu, czy dopiero po kilku godzinach pracy.

Jeżeli opóźnienie dotyczy tylko niektórych stanowisk, ich porównanie jest częścią diagnozy. Próba na szybszym komputerze wykonawcy może nie odtworzyć zgłoszenia. Podobnie niewielki plik testowy nie zastąpi dokumentu, na którym pracownik faktycznie czeka. Dane testowe powinny zachować cechy istotne dla problemu; przy ich anonimizacji trzeba uważać, by nie usunąć właśnie tych cech.

Na tym etapie można zamówić ograniczoną diagnozę. Jej wynikiem powinny być odtworzony problem, pomiary, wskazana przyczyna albo jasno opisany brak danych oraz propozycja dalszego zakresu. To daje podstawę do decyzji o wydatku, zanim firma zaakceptuje szeroką „optymalizację całej aplikacji”.

Ustal, na co aplikacja rzeczywiście czeka

Wykonawca powinien rozdzielić czas pobierania danych, obliczeń i przygotowania widoku. Pomaga w tym profilowanie, czyli pomiar tego, które części programu wykonują pracę i ile czasu zajmują. Dokumentacja Qt Quick zaleca profilowanie przed wyborem optymalizacji, żeby poprawiać rzeczywisty problem.

Narzędzie trzeba dobrać do aplikacji. QML Profiler w Qt Creator pomaga analizować interfejsy oparte na QML i JavaScript, ale nie profiluje kodu C++. Sam wykres z tego narzędzia nie wyjaśni więc każdego opóźnienia w aplikacji Qt. Poproś o wniosek dotyczący zgłoszonej czynności: co ją opóźnia i jaki pomiar na to wskazuje.

Jeśli program czeka na odpowiedź zewnętrznego systemu, praca nad rysowaniem przycisków może nie skrócić tego oczekiwania. Jeśli dane są już dostępne, lecz ich pokazanie zajmuje dużo czasu, trzeba przyjrzeć się przygotowaniu widoku. To różne zakresy prac, mimo podobnego objawu na ekranie. Wniosek powinien wynikać z obserwacji, a nie z założenia, że winne jest Qt.

Sprawna obsługa okna wymaga osobnego sprawdzenia

W Qt długą pracę można wydzielić tak, aby nie zajmowała części programu odpowiedzialnej za obsługę interfejsu. Wyświetlenie wyniku nadal musi uwzględniać zasady pracy z interfejsem w głównym wątku. Takie rozdzielenie opisuje dokumentacja Qt dotycząca wątków i obiektów. Dla zamawiającego istotne jest zachowanie programu podczas wykonywania zadania.

Samo odłożenie uruchomienia ciężkiej operacji nie oznacza, że będzie ona wykonywana w tle. QTimer ustala moment wywołania, a nie automatyczne przeniesienie pracy do innego wątku. Jeśli podczas demonstracji okno pojawia się szybko, a potem zamiera, sprawdź cały przebieg czynności.

Uzgodnij, czy użytkownik ma widzieć postęp, móc anulować zadanie i bezpiecznie zamknąć okno. Trzeba również określić, co dzieje się z częściowo wykonanymi zmianami. Przycisk „Anuluj”, który pozostawia dane w niejasnym stanie, nie jest wystarczającym wynikiem naprawy.

Przykład: import pliku do aplikacji Qt

Załóżmy hipotetycznie, że pracownik wybiera plik do importu, po czym okno nie reaguje aż do pokazania wyników. Przed zmianą warto osobno zmierzyć czas do wyświetlenia danych i okres braku reakcji na działania użytkownika. Sprawdź też, czy po ponownym wykonaniu tej samej czynności zachowanie się zmienia.

Jeśli pomiar wskaże, że import blokuje obsługę okna, poprawka może dotyczyć wydzielenia tej pracy oraz przekazywania postępu i wyniku. Odbiór powinien obejmować ukończony import, próbę anulowania i zachowanie po błędzie pliku. Jeżeli przyczyną okaże się pobieranie danych z serwera, potrzebny będzie inny zakres. Przykład pokazuje sposób podejmowania decyzji; nie jest wynikiem testu konkretnego produktu.

Ostatecznie porównujesz zarówno czas i możliwość obsługi, jak i poprawność zaimportowanych danych. Szybciej pokazane okno z niepełnym wynikiem nie spełnia tego samego wymagania co poprawnie zakończona operacja.

Porównuj wyniki w tych samych warunkach

W raporcie po poprawce powinny znaleźć się wersje aplikacji przed i po zmianie, komputer, system, dane oraz sposób wykonania próby. Oddziel pierwsze uruchomienie od kolejnych, gdy program może korzystać z wcześniej wczytanych informacji. Powtórz scenariusz, żeby pojedynczy korzystny wynik nie zastąpił oceny codziennej pracy.

Warunki uruchomienia powinny być porównywalne, także pod względem włączonych narzędzi pomiarowych. Jeżeli diagnoza wymaga innej konfiguracji programu, wykonawca powinien opisać tę różnicę i sprawdzić również wydanie przeznaczone dla użytkownika.

Mierz to, co było problemem. Przy długim starcie będzie to czas do możliwości wykonania potrzebnej czynności, przy blokowaniu okna - reakcja na działania użytkownika, a przy pogarszaniu pracy w ciągu dnia - zachowanie po powtarzaniu operacji. Zużycie procesora i pamięci może pomóc w diagnozie, ale samo w sobie nie zastępuje wyniku zadania użytkownika.

Przed wdrożeniem sprawdź też funkcje, na które poprawka mogła wpłynąć, na przykład zapis, filtrowanie czy drukowanie. Jeżeli zmiana dotyka sposobu przechowywania danych lub przebiegu operacji, uzgodnij warunki powrotu do poprzedniej wersji. Zakres tych kontroli powinien odpowiadać zmianie, a nie przypadkowej liście wszystkich możliwości Qt.

Co odebrać od wykonawcy?

Oprócz nowej wersji programu potrzebujesz krótkiego wyjaśnienia przyczyny, zakresu zmiany i wyników porównania. Powinno być jasne, jakie warunki sprawdzono, co nadal pozostaje ograniczeniem i kto obserwuje działanie po wdrożeniu. Użyty scenariusz warto zachować do kontroli kolejnych wydań, żeby ten sam problem nie wracał niezauważony.

Zatwierdzenie poprawki oprzyj na ustalonym wcześniej wymaganiu użytkownika. Obietnica procentowego przyspieszenia bez wskazania czynności, danych i warunków pomiaru nie pozwala ocenić, czy pracownik będzie mógł sprawniej wykonać swoją pracę.