Pierwszym krokiem jest spisanie specyfikacji wymagań,. czyli co to oprogramowanie ma robić. Drugim jest wycena i ustalenie ceny Następnie programista zabiera się za pracę. Po drodze będzie wielokrotnie zadawał ci pytania, które wyjdą w trakcie. Po ukończeniu wstępnej wersji dostaniesz dostęp do opragramowania. Wtedy programista czeka na twoje uwagi i listę rzeczy, ktróre chcesz zmienić. Nastepnie wprowadza te poprawki i znowu udostępnia ci nowszą wersję. Ten krok może powtarzać się wielokrotnie do momentu, aż będziesz zadowolony z wyniku. Zwykle ta część zajmuje najwięcej czasu. To, jak szybko uda się dokończyć oprogramowanie zalezy czesto od tego jak sprawnie wysyłąsz feadback programiście. Po ukończeniu oprogramowania bardzo często klienci zwracają się z pytaniami jak dokładnie oprogramowanie działa. Mogą też zgłosić błąd, który wcześniej przeoczono - w Green Code Studio na wszelkie oprogramowanie udzielamy 2 lata gwarancji, przez ten okres błędy usuwamy bezpłatnie. Zazwyczaj też klienci po dłuższym użytkowaniu wpadają na pomysły co zmienić lub co dodać (zmainy i nowe funkcjonalności są dodatkowo płatne). Ten okres po uruchomieniu zbiorczo anzywamy utrzymaniem, i trwa on tak długo, jak długo korzysztasz z oprogramowania. W Green Code Studio dla części klientów zajmujemy się utrzymaniem oprogramowania, które początkowo stworzyła inna firma, ale klient był niezadowolony z ich podejścia do utrzymania. Pamiętaj jednak, że najmniej problemów występuje, gdy utrzymaniem zajmuje się osoba, która tworzyła projekt od samego początku. Dlatego wybierając wykonawcę pomyśl o tym w perspektywie wielu lat.

W pracy programisty często zdarza się, że klient zgłasza błąd, bo coś działa nie tak, jak powinno. Po sprawdzeniu okazuje się jednak, że program działa dokładnie tak, jak wcześniej ustalono, że ma działać. Czasem wynika to z tego, że po kilku miesiącach ludzie zapominają o tym, co sami chcieli, a czasem osób zainteresowanych danym programem jest kilka, i mają inne wizje, czasem sprzeczne ze sobą. Jedna osoba prosi o dodanie funkcjonalności, po czym inna prosi o jej usunięcie, gdyż uważa to za buga.

Dla mnie wiedza, czy coś jest faktycznie błędem, przekłada się na pieniądze: w Green Code Studio błędy popełnione z mojej winy naprawiam bezpłatnie, ale zmiana spowodowana tym, że to klient zmienił zdanie już bezpłatna nie jest.

Trudniejsza sytuacja jest wtedy, gdy to programiści znajdują w programie coś, co wygląda jak błąd, ale nikt (ani po stronie zespołu programistów, ani po stronie klienta) nie wie na pewno, czy to bug czy feature. Nie da się zrobić programu, który działa poprawnie, jeśli nikt nie wie, co to znaczy poprawnie. Do tego nim więcej elementów, które strach ruszyć, tym programowanie staje się trudniejsze (a więc i droższe)

Znajomy pracował kiedyś nad programem do wykonywania obliczeń dla kopalni. Dostał on program napisany 3 dekady wcześniej w fortranie dla systemu MS-Dos i miał za zadanie przepisać go w nowocześniejszej technologii. Udało mu się w oryginalnym programie znaleźć błędy, przez które wyniki były błędne, czego nikt nie zauważył przez lata.

Jak się przed tym bronić?

Dużą pomocą w rozwiązywaniu tego typu sytuacji są wszelkie notatki i zapiski z komunikacją z klientem, np. maile. Jeśli rozmawiasz osobiście czy przez telefon dobrze zapisywać notatki. Niekoniecznie muszą być ładnie posortowane, ważne, żeby było jakieś słowo kluczowe, po którym wyszukiwarka je znajdzie.

Ja do zapisywania notatek i tego, co mam do zrobienia używam Asany. W bardziej skomplikowanych projektach daję dostęp do Asany klientowi: wtedy zamiast rozmawiać w mailach, które są odpowiedzią odpowiedzi do odpowiedzi odpowiedzi mamy od razu podział na poszczególne zadania. Poza Asaną testowałem też issue tracker w JetBrains Space, i choć uwielbiam JetBrainsów, to to narzędzie wyszło im dosyć ubogo. Pracowałem też na Jirze, ale wydaje mi się oprogramowaniem przeznaczonym raczej dla korpo.

Pomocą jest też posiadanie gita, gdyż można sprawdzić kiedy dana zmiana w kodzie została wprowadzona. Używanie gita wydaje się być czymś oczywistym, ale tylko pozornie.

Od ponad roku pracuję nad projektem, który wcześniej tworzyła inna firma. Klient był niezadowolony, więc zgodnie z umową poprosił o podesłanie kodu źródłowego i przekazał projekt mi. Ale w umowie nie było historii gita, więc tamta firma jej nie przesłała.

Coś, co chciałbym spróbować w przyszłości, to zapisywanie wszystkich ustaleń co program ma robić w jednym miejscu, dostępnym również dla klienta, i wprowadzanie każdej nowej funkcjonalności najpierw w tym dokumencie. Nie wiem jednak, czy sprawdzi się to w praktyce. Próbowałem to tylko na małej skali, w pojedynczych funkcjonalnościach, co do których nie byłem w stanie dość do porozumienia z klientem jak mają działać.

Każdą aplikację w szerokim tego słowa znaczeniu: od Messengera, przez MS Office a na Wikipedii kończąc, można podzielić na 2 części: Frontend i Backend. Są aplikacje, które mają tylko jedną z tych części, ale jest to dosyć rzadkie.

Słowa frontend i backend są używane przez różnych ludzi w różnym znaczeniu, więc musisz wziąć to pod uwagę, gdy koś używa tego słowa, ale ja tutaj używam najszerszego znaczenia. Frontend to wszystko to, co dzieje się na urządzeniu użytkownika. Backend to to, co dzieje się na serwerach.

Weźmy jako przykład aplikację Facebook Messenger. Możemy ją uruchomić wchodząc na facebook.com/messenger.com. Możemy też ściągnąć aplikację z Google Play, App Store, a nawet z Microsoft Store. Ta część to frontend. Ale bez dostępu do internetu Messenger jest bezużyteczny. I to, co jest na serwerach, z czym łączymy się przez internet, to backend.

Backend

Jest to ta część, która znajduje się na serwerze, której użytkownik bezpośrednio nie dotyka, dlatego dla osób nietechnicznych jest mało interesująca.

To co jest interesujące, to że potrzebny jest serwer, który kosztuje. Takie firmy jak Google wydają kosmiczne pieniądze na swoje serwerownie. Jednak jeśli ty myślisz o zrobieniu swojej aplikacji, to z doświadczenia powiem, że najprawdopodobniej wystarczy ci najtańszy dostępny na rynku serwer typu VPS, który będzie cię kosztować kilkanaście zł miesięcznie.

Tutaj też pojawia się takie pojęcie jak chmura. Przy czym jest to słowo używane bardzo często w marketingu, tak że zatraciło ono swoje znaczenie.

Frontend

Są 2 podstawowe podejścia do frontendu: aplikacja natywna i webowa (plus różne kombinacje mieszania tych podejść).

Aplikacja natywna

Aplikacja natywna to podejście bardziej klasyczne. Taką aplikację najpierw trzeba zainstalować. Na PCtach kiedyś instalowało się z płyt, teraz raczej się po prostu ściąga. Na urządzeniach mobilnych mamy sklepy jak Google Play.

Takie aplikacje tworzone są pod konkretny system. Z jednej strony daje to duże możliwości. Z drugiej jednak jest to uzależnienie od danego systemu (tzw. vendor lock). Adobe Photoshop powstał na Windowsa oraz na Mac OSX. Żeby uruchomić go na tablecie z Androidem, twórcy musieli by stworzyć go jeszcze raz od początku. Oczywiście są technologie, dzięki którym można tworzyć program raz i uruchamiać na kilku platformach, ale kilka to nie znaczy wszystkie.

Aplikacja webowa

W 1990 roku powstała koncepcja stron WWW. W założeniu miały służyć do czytania tekstów, które inni ludzie publikowali. Jednak przez te 30 lat przeglądarki internetowe rozwinęły się z narzędzia do czytania tekstu w platformy uruchamiające rozbudowane programy.

Tak więc aplikacja webowa to bardzo rozbudowana strona internetowa. Takimi aplikacjami są Gmail, Google Docs czy Facebook (choć wszystkie one mają też aplikacje Androidową i iOSową).

Zaletą takiej aplikacji jest po pierwsze, że nie musimy jej instalować. Po prostu wpisujemy adres lub klikamy w link. Druga sprawa to wieloplatformowość. Webową aplikację można otworzyć na czymkolwiek. I mówię nie tylko o Windowsie, Androidzie i iOSie. Przeglądarka jest chyba w każdym smart TV, jest w XBoxie, PS5 i Nintendo Switch (choć trochę ukryta). Tworząc aplikację webową jesteśmy też gotowi na te platformy, które dopiero powstaną w przyszłości.

Oczywiście są pewne ograniczenia. Np. możliwości integrowania się z tym co daje system są dość ograniczone. Możemy korzystać np. z kamery, GPS, ale obsługa NFC jest ciągle w fazie beta, a push notyfikacji ciągle nie ma na iPhone.

Podejście mieszane

Te dwa podejścia można mieszać. Można stworzyć aplikację natywną, która w środku uruchamia przeglądarkę internetową. Przykładem jest np. Slack, który możemy uruchomić w przeglądarce, ale możemy też zainstalować aplikację PCtową, która jest tak naprawdę tym samym co wersja webowa.

Oczywiście możemy mieszać te podejścia dowolnie. Możemy mieć część aplikacji zrobioną całkowicie natywnie, a część właśnie w formie webowej.

PWA

Progressive Web Application - jest to również podejście mieszane, ale od drugiej strony. Tworzymy aplikację, która z założenia jest webowa, ale aspiruje do bycia jak natywne. Np. możemy dodać sobie jej ikonę na ekran główny/pulpit i uruchamiać bez widoku paska przeglądarki (działa to zarówno na PCtach z Windowsem, jak i na Androidzie, ale Apple ma do tego ambiwalentny stosunek).