Ostatnio udało mi się rozwiązać problem lokalnej społeczności. Zarządzanie ludźmi i zasobami generowało sterty papieru i z biegiem czasu zaczęło się komplikować. Powodowało różne frustracje i błędy. Zacząłem się wtedy zastanawiać czy aplikacja, która zgromadziłaby wszystkie potrzebne dane w jednym miejscu i zapewniłaby odpowiedni dostęp do nich, mogłaby pomóc tej lokalnej społeczności.

Code

Planowanie

Nikt tak dobrze nie zna specyfiki problemu, jak ten kto się aktualnie z danym problemem zmaga. Dlatego aby ustalić funkcjonalności jakie powinny być zawarte w narzędziu, którego stworzenia się podjąłem, przeprowadziłem burzę mózgów z osobami odpowiedzialnymi za zarządzanie lokalną grupą. Otrzymałem w ten sposób informację o tym co powinna zawierać aplikacja. Na pytanie jak wprowadzić opisane funkcjonalności oraz jakie technologie wykorzystać musiałem odpowiedzieć sobie sam.

Przy wyborze narzędzi i technologii postawiłem na wykorzystanie tych sprawdzonych. Jako, że określony został docelowy termin, zrezygnowałem z eksperymentowania z nowinkami technologicznymi. Chciałem w ten sposób uniknąć niespodzianek i zbędnych opóźnień.

MVP

Pierwsze wersja aplikacji powstała dość szybko, ponieważ prototypowanie aplikacji w Ruby on Rails jest nadzwyczaj proste. Pierwszy prototyp powstał w ok. 20 godzin i był gotów do wstępnego przedstawienia. Zawierał on funkcje logowania, wysyłania wiadomości między użytkownikami, publikowania postów, zarządzania użytkownikami, przechowywanie notatek w formie plików pdf oraz terminarz spotkań.

Technologie jakie wykorzystałem to wspomniany wyżej framework back-endowy Ruby on Rails, baza danych to PostgreSQL, framework front-endu to Bootstrap. Skorzystałem także z kilku gemów, które ułatwiły proces tworzenia aplikacji, takich jak Devise, Paperclip czy Capistrano.

Wdrażanie i testowanie

Kiedy tylko skończyłem pierwszą wersję narzędzia, oddałem ją użytkowniką do testów. Dzięki temu na bieżąco mogłem otrzymywać od nich feedback i wprowadzać dodatkowe ulepszenia o jakie prosili. Na bieżąco naprawiałem także błędy aplikacji, które nie zawsze były oczywiste do wykrycia. Każda poprawka w programie była od razu dostarczana na serwer testowy z którego korzystali użytkownicy.

Na tym etapie aplikacja nie przechowywała żadnych prawdziwych danych. Z każdą kolejną poprawką baza danych była czyszczona i zapełniana nowym, losowo wygenerowanym, zestawem danych.

Skalowalność

Wstępny projekt narzędzia zakładał, że użytkownikami aplikacji będą tylko i wyłącznie członkowie jednej lokalnej grupy. Postanowiłem jednak, że można wykorzystać potencjał tworzonego rozwiązania w szerszej skali. W pierwszej wersji aplikacji nie ma możliwości dodania kilku grup jednocześnie, natomiast zostanie ona wprowadzona w wersji kolejnej.

Grzech programisty

Niestety na ogólnym pośpiechu w procesie wdrażania narzędzia ucierpiała jego jakość. To co widzą użytkownicy nie odbiega w żaden sposób od standardów czy ich wymagań. Wszytskie funkcjonalności zostały zaimplementowane i spełniają swoje role. Natomiast przez “pójście na skróty” w pewnych momentach tworzenia aplikacji, wymagane są teraz poprawki przed opublikowaniem kodu źródłowego. Dotyczą głównie optymalizacji, stylu kodu i poprawek wyglądu narzędzia.

Kod projektu, który roboczo nazwałem “Erencontre” zosatnie opublikowany za pewien czas na moim Githubie. Natomiast będzie to już wersja zawierająca wszytskie w/w poprawki i usprawnienia.

Podsumowanie

Szybki proces wdrażania aplikacji zdecydowanie przyspiesza termin oddania narzędzia do użytku, natomiast cierpi na tym jakość kodu, pojawiają się drobne przeoczenia, spada poziom bezpieczeństwa i wydajności aplikacji. Nie są to katastrofalne w skutkach negatywne efekty. Należy się jednak zastanowić czy po pierwszym wdrożeniu aplikacja będzie nadal rozwijana i jak długo będzie trzeba ją utrzymywać.

W najbliższym czasie podzielę się kilkoma wnioskami do jakich doszedłem pracując nad tym projektem.

Zapraszam do komentowania 😉