Refleksje o PKgui

Ten post jest długi. Zawiera wyrywkową historie mojego projektu, który tworzę po godzinach od blisko 3 lat. Piszę ten post z myślą o pracy pisemnej, którą muszę oddać. Projekt został rozpoczęty gdy nauczyłem się C++, zafascynowałem się programowaniem w nim i, nie mając pojęcia o czasie jaki zajmuje napisanie czegoś dużego, stwierdziłem, że napiszę moduł do mojego programu, który zajmie się interfejsem użytkownika. Inną, jakże istotną przyczyną utworzenia własnej biblioteki była chęć nauczenia się przyzwoitego programowania (co osiągnąłem) i fatalne problemy z konfiguracją gotowych bibliotek GUI. Później dowiedziałem się, dlaczego programiści C++ przechodzą piekiełko konfiguracji takich bibliotek zamiast stworzyć samemu komponenty potrzebne do programu, nawet jeśli to tylko mały podzbiór komponentów dostępnych w wybranej bibliotece - po prostu tworzenie i tak zajmuje dużo więcej czasu.
Cała ta biblioteka przechodziła wiele przemian w samym projekcie, nie mówiąc już o implementacji szczegółów. Początkowo szacowany czas zwiększał się z jednego miesiąca, poprzez 3, 6 i 12 miesięcy aż doszedłem do wniosku, że, wzorując się na niektórych deweloperach, skończę jak będzie gotowe. Zabrakło na początku jednoznacznej specyfikacji tego, co będzie, a czego nie będzie w projekcie. Ciągle wydawało mi się, że jak dołożę jeszcze jedną rzecz, to będzie lepiej, a ponieważ obecny projekt nie ułatwia takiego rozszerzenia, powinno się go nieco przeprojektować, bo to wstyd pokazywać taki kod komukolwiek. W dużej części była to prawda, ponieważ dopiero uczyłem się programować i projektować i duże części kodu rzeczywiście były nieczytelne, skopiowane, nieudokumentowane i zbyt skomplikowane. Często powodem było niewłaściwe użycie technik, takich jak szablony, przeładowanie funkcji czy polimorfizm. Było kilka rzeczy, z których byłem w pewnym sensie dumny, a które później okazały się beznadziejne w użyciu.
Sztandarowym przykładem czegoś, nad czym zmarnowałem dużo czasu jest właściwość biblioteki, dzięki której można wywoływać tę samą funkcję dla wielu widżetów na raz (widżet - element interfejsu, np napis albo przycisk). To umożliwiałoby np. zmianę stylu interfejsu. Próbowałem różnych rozwiązań. Idealne rozwiązanie byłoby nieintruzywne, tzn unikałoby zmieniania czegokolwiek w widżetach kiedy trzeba wywołać dla wielu z nich funkcję, która nie była jeszcze tak wywoływana. Sprawę komplikuje jednak fakt, że aby wywołać funkcję dla hierarchii widżetów (każdy widżet ma dzieci, one mają swoje dzieci itd), trzeba znać dzieci widżeta, czyli pobrać od niego dane. Idealne rozwiązanie byłoby też ogólne, tzn takie, żeby nie trzeba było definiować żadnych specjalnych komponentów dla każdej funkcji, którą chcemy wywołać. Ostatecznie rozwiązanie używa zewnętrznej biblioteki zwanej Loki. Ostatecznie ten mechanizm nie jest tak często używany, chyba że użytkownik programu zapragnie zmienić styl (skórkę) interfejsu. Na początkowe, częściowo intruzywne rozwiązania zmarnowałem dużo czasu, zanim zdałem sobie sprawę do czego tak naprawdę jest a do czego nie jest przewidziany język C++, którego używam. Pewnych rzeczy po prostu nie da się łatwo zrobić i dlatego tak błądziłem. Tak, żeby dodać smaczku do tej historii dodam, że obecnie rozważam całkowite porzucenie tego rozwiązania, bo ono używa biblioteki Loki, która ma różne niepożądane efekty uboczne, głównie zwiększenie czasu kompilacji i rozmiaru wynikowego kodu z powodu polegania na szablonach.
Krótkie omówienie tego, czego się nauczyłem dzięki temu projektowi.
Nauczyłem się technik inżynierii oprogramowania, hamowania swoich ambicji i planowania zadań. Nauczyłem się, ile jestem w stanie stworzyć w normalnych okolicznościach i jak wygląda praca po godzinach. Nauczyłem się, ile problemów mogą stworzyć niespodziewane szczegóły techniczne i jak ważne jest, żeby nie zapomnieć o tym, co się zrobiło. Najlepiej dokumentować wszystko, co się tworzy. Mogą to być komentarze w kodzie, ale nie stracą one na wartości jeżeli znajdą się na przykład na blogu. Na podstawie rozwiązań użytych w PKgui można by napisać co najmniej kilka ciekawych artykułów i żałuję, że ich nie napisałem. Stworzenie tego projektu wymagało też wielokrotnego zwracania się o pomoc na forum, dzięki czemu nauczyłem się skutecznie pytać, co przydaje mi się nie tylko na forum.
Mógłbym spędzić czas nad czymś bardziej wartościowym, np. nad wymyślaniem algorytmów ewolucyjnych, nauką na uniwersytecie w celu otrzymania lepszych ocen, czy projektem prowadzonym z kolegami, który dałby dużo więcej, bo mielibyśmy gotowy produkt, który można by było np. sprzedać.
Czy zmarnowałem czas, pisząc to GUI? Zupełnie naturalną reakcją byłoby powiedzenie, że nie żałuję bo się dużo nauczyłem, bla bla terefere. Jednak nie mam w zwyczaju tak się nad sobą rozczulać, więc nie będę, tym bardziej, że ten projekt nie był żadnym traumatycznym przeżyciem, o którym można by zrobić stereotypowy rozczulający materiał dla na staczającym się ostatnio TVN24. Żałuję, że nie wykorzystałem tego czasu inaczej, jestem natomiast zadowolony z ilości i jakości kodu, którym teraz dysponuję i nie mogę się doczekać dokończenia projektu, pokazania kodu światu, przyjęcia komentarzy, jakiekolwiek one nie będą i rozpoczęcia pracy nad czymś innym, co będzie wydawać się mniej trywialne i da bardziej "namacalne" efekty działania. Ciekawą ideę opisałem w swoim raporcie na temat rozwoju kariery, który oddałem na Career Management Skills, jednak nie będę jej tu opisywał, bo ten post i tak już jest długi. Ten paragraf uzasadnia wniosek z całego projektu: Nie angażować się w coś, co nie jest zupełnie ulubionym zajęciem, czymś, o czym się marzy.