Tak, to już! Dziś nadszedł ten dzień – setny dzień naszego wyzwania. A więc czas spojrzeć wstecz i odpowiedzieć na ważne pytanie…

Czy udało nam się osiągnąć to, co założyliśmy?

W czasie stu dni zrealizowaliśmy zdecydowaną większość naszych planów – począwszy od poszukiwania najlepszej platformy sprzętowej, po zaprojektowanie architektury systemu, implementację, aż po skonstruowanie prototypu.

Każdy z powyższych etapów składał się oczywiście z mniejszych fragmentów, których nie sposób w tym miejscu wymienić. Część z nich była drobiazgowo zaplanowana, część powstawała na “gorąco”, w miarę postępu prac. Stąd też niezwykle trudno jest ocenić, które elementy zostały zrealizowane w 100%…

Od strony hardware’u zasadnicza trudność leżała w stworzeniu możliwie szybko stabilnej platformy sprzętowej dla dalszego rozwijania oprogramowania. Od pewnego momentu wskazane jest bowiem testowanie w środowisku jak najbardziej zbliżonym do docelowego. Ponieważ na realizację projektu przeznaczyliśmy jedynie 100 dni, nie mogliśmy sobie pozwolić na budowanie kilku, stopniowo ulepszanych prototypów – to pochłonęłoby zbyt wiele cennego czasu. Musieliśmy “upchnąć” jak najwięcej funkcjonalności i komponentów na etapie “proof-of-concept”, kiedy to operowaliśmy na płytce prototypowej i chmarze kabli połączeniowych. Następnie trzeba było całą wiedzę, całe zebrane doświadczenie i szkic projektu przenieść na jedyny prototyp…

Sporym zaskoczeniem był fakt, iż ów prototyp udało się uruchomić bez większych problemów i to już za pierwszym razem. Jest to o tyle ciekawe, iż system zawiera całkiem sporo połączeń sygnałów o stosunkowo wysokiej częstotliwości, wrażliwych na zakłócenia oraz wszelkie niedociągnięcia przy projektowaniu płytki drukowanej i prowadzeniu szyn zasilania. Oczywiście do schematu wkradło się kilka drobnych błędów – ale jest to przecież przywilej prototypu 🙂

Strona oprogramowania, mimo iż nie posiadała aż tak wyśrubowanych ograniczeń czasowych, wcale nie okazała się łatwiejsza. Czymś co podkreślałem na każdym niemalże kroku była jasna i przemyślana architektura najmniejszego nawet fragmentu systemu. To właśnie ona w połączeniu z zestawem testów jest w stanie zapewnić, że oprogramowanie, które tworzymy będzie stabilne i łatwe w utrzymaniu. Nie sposób bowiem napisać software, który będzie zlepkiem kodu, o zagmatwanej strukturze, który “jakoś przypadkiem działa”.

To właśnie zaprojektowanie takiej struktury stanowiło główny problem i pochłonęło ogromną część przeznaczonego czasu. Wymagało to bowiem drobiazgowego wręcz przemyślenia każdego aspektu, przewidzenia każdego możliwego scenariusza działania.

Kilka przemyśleń i wniosków

Dobrą praktyką w wielu nowoczesnych metodologiach tworzenia oprogramowania jest tzw. retrospektywa. W skrócie polega ona na spojrzeniu wstecz i próbie oceny projektu, zadania czy sprintu, określenia co udało się nam osiągnąć, co było cennym doświadczeniem, a co może wymaga poprawy i większej uwagi… No to zaczynamy!

Co było ok:

• Tworzenie oprogramowania w formie kolejnych, ściśle rozdzielonych warstw i modułów,
• Re-użycie dojrzałego kodu z poprzednich projektów,
• Zastosowanie zunifikowanego podsystemu graficznego, opartego na widgetach,
• Wydzielenie backendu danych,
• Zbudowanie stanowiska testowego, symulującego rzeczywiste, docelowe środowisko pracy,
• Konsekwentne utrzymywanie kodu w dobrej jakości, ciągłą refaktoryzacja oraz unikanie “chodzenia na skróty”,
• Szerokie wdrożenie testów jednostkowych,
• Przechowywanie kodu pod kontrolą Git’a,

Co powinniśmy zrobić lepiej:

• Wprowadzenie testów komponentowych oraz integracyjnych,
• Uruchomienie całej aplikacji również na komputerze PC, w celu łatwiejszego debugowania i testowania,
• Stworzenie spójnej i usystematyzowanej listy rzeczy do zrobienia “to-do”,

Do poszczególnych tematów na pewno powrócę jeszcze w następnych artykułach (tak, tak… będą kolejne!). Chciałbym natomiast podzielić się z Wami jedną, szczególnie istotną moim zdaniem, konkluzją:

To, że w oprogramowaniu pojawiają się błędy jest rzeczą naturalną. I rzeczywiście, część z nich wynika z niedopracowanych narzędzi, błędnej dokumentacji… Jednak myślę, że jest to nie więcej niż 10%. Pozostałe 90% jest wynikiem naszego lenistwa i niechlujności – chodzenia “na skróty”, pisania kodu “po łebkach” i aby tylko uruchomić. Tracimy w ten sposób cenne godziny, tylko dlatego, iż wcześniej szkoda nam było poświęcić minuty na zrobienie czegoś solidnie.

To jak zwijanie kabla słuchawek na szybko, aby tylko wepchnąć do kieszeni… Po to by za chwilę mozolnie go rozplątywać

Sukces czy porażka?

Cóż, dla wielu wynik wyzwania 100 dni będzie rozczarowaniem – nie powstało przecież gotowe urządzenie, które każdy może założyć w swoim samochodzie. Musimy jednak pamiętać, jakie były pierwotne założenia. Naszym celem było przede wszystkim stworzenie prototypu i pokazanie, że da się w tak krótkim czasie stworzyć bardzo konkretny i ambitny projekt. Ponadto, mam nadzieję, udało się też przekazać w tych stu artykułach sporo cennego doświadczenia, które być może okaże się dla Was przydatne.

Sam odbieram te 100 dni jako cenną lekcję. To wyzwanie nie tylko pozwoliło mi pogłębić wiedzę z zakresu programowania i projektowania, ale co ważniejsze – nauczyło szanować czas, roztropnie z niego korzystać i lepiej planować. Uświadomiłem sobie dzięki temu, że to nie otaczający nas Świat odbiera nam cenne sekundy i minuty życia, a my sami pozwalam się z nich okradać…

Czy to ostatni artykuł? Absolutnie nie… 🙂 Parafrazując słynne słowa Winstona Churchilla:

To nie jest koniec, to nawet nie jest początek końca. Ale na pewno jest to koniec początku!