Prace programistyczne dla sklepów internetowych i systemów webowych

Prace programistyczne

Prace programistyczne obejmują tworzenie nowych funkcji, rozwój istniejących systemów, przebudowę ich elementów, integracje, tworzenie dedykowanych rozwiązań, aktualizacje oraz optymalizację kodu. Realizujemy development dla sklepów internetowych, platform sprzedażowych, systemów B2B, dedykowanych systemów webowych, aplikacji internetowych i innych rozwiązań cyfrowych.

Pracujemy między innymi z PHP, Laravel, Symfony, JavaScript, React i Node.js. W przypadku e-commerce rozwijamy rozwiązania oparte między innymi na PrestaShop, WooCommerce, Magento, Shopware i Shopify.

Dobór technologii zależy od projektu, jego obecnej architektury, zakresu funkcjonalnego oraz planów dalszego rozwoju. Nie zakładamy, że jedna platforma lub technologia będzie odpowiednia dla każdego klienta. Jeżeli klient ma już działający system, najpierw sprawdzamy jego możliwości, ograniczenia i sposób działania. Jeżeli tworzymy nowy projekt, dobieramy rozwiązanie do rzeczywistych potrzeb.

Prace mogą obejmować zarówno pojedynczą funkcję, jak i większą część systemu. Tworzymy nowe funkcjonalności, rozwijamy procesy B2B, modyfikujemy proces zakupowy, budujemy integracje API, rozwijamy panele administracyjne, tworzymy dedykowane moduły i rozwiązania, wdrażamy automatyzacje, aktualizujemy platformy i zależności oraz optymalizujemy istniejący kod.

W przypadku sklepów internetowych development może obejmować również integrację z systemem ERP, BaseLinkerem, operatorami płatności, firmami kurierskimi, marketplace'ami i innymi systemami zewnętrznymi. Zakres integracji ustalamy na podstawie tego, jakie dane muszą być wymieniane, pomiędzy jakimi systemami, w którym kierunku odbywa się wymiana oraz które elementy procesu mają zostać zautomatyzowane.

Nie ograniczamy prac programistycznych do gotowych modułów i wtyczek. Jeżeli istniejące rozwiązanie odpowiada potrzebom projektu, możemy je wykorzystać i dostosować. Jeżeli nie spełnia wymagań albo nie zapewnia odpowiedniego poziomu kontroli nad działaniem systemu, tworzymy rozwiązanie dedykowane. Dotyczy to między innymi modułów PrestaShop, rozszerzeń WooCommerce, integracji oraz funkcji tworzonych bezpośrednio pod konkretny projekt.

1. Analiza zakresu przed rozpoczęciem prac

Przed rozpoczęciem większych prac określamy, co ma zostać wykonane, jaki problem ma zostać rozwiązany i jaki powinien być efekt końcowy. Nie zakładamy, że opis technicznego rozwiązania przekazany przez klienta jest jedynym możliwym sposobem realizacji.

W przypadku prostych zmian możemy przejść bezpośrednio do sprawdzenia systemu i wykonania zadania. Przy większych zmianach analizujemy istniejący kod, konfigurację, zależności, integracje i sposób działania powiązanych funkcji.

W bardziej rozbudowanych projektach przygotowujemy specyfikację, w której opisujemy między innymi funkcje, ścieżki użytkowników, uprawnienia, integracje, zależności oraz zakres zmiany. Jeżeli sposób działania funkcji wymaga wcześniejszego przedstawienia, możemy przygotować również prototyp lub projekt graficzny.

Poziom analizy dopasowujemy do skali i ryzyka zmiany. Dzięki temu proste zadanie nie wymaga niepotrzebnie długiego procesu przygotowawczego, a większe prace nie rozpoczynają się bez sprawdzenia najważniejszych założeń.

Jest to istotne dla klienta, ponieważ pozwala wcześniej wykryć zależności, które mogłyby wpłynąć na zakres, czas lub sposób wykonania prac.

2. Dobór rozwiązania technicznego

Po poznaniu problemu i zakresu dobieramy sposób jego realizacji. Możemy wykorzystać istniejącą funkcję platformy, gotowy moduł lub bibliotekę, rozbudować obecne rozwiązanie albo stworzyć dedykowaną funkcję.

Przy wyborze rozwiązania bierzemy pod uwagę nie tylko możliwość wykonania konkretnej funkcji, ale również jej wpływ na istniejący system i dalszy rozwój projektu.

Gotowy moduł może być dobrym rozwiązaniem, jeżeli odpowiada wymaganiom i nie tworzy problemów z utrzymaniem. W innym przypadku dedykowana implementacja może dać większą kontrolę nad działaniem systemu i ograniczyć zależność od zewnętrznego rozwiązania.

Jeżeli proponowane przez klienta rozwiązanie ma ograniczenia techniczne albo może utrudnić dalszy rozwój, informujemy o tym przed rozpoczęciem prac. Możemy przedstawić alternatywne rozwiązania wraz z ich konsekwencjami, a klient podejmuje decyzję na podstawie zakresu, kosztu, możliwości rozwoju i ryzyka technicznego.

Oznacza to, że development nie polega wyłącznie na realizowaniu wskazanej technologii lub modułu. Obejmuje również ocenę, czy wybrane rozwiązanie ma sens w konkretnym projekcie.

3. Integracje i wymiana danych

Jednym z częstych elementów prac programistycznych są integracje pomiędzy sklepem lub systemem a zewnętrznymi usługami.

Integrujemy między innymi sklepy internetowe z systemami ERP, BaseLinkerem, systemami magazynowymi, operatorami płatności, firmami kurierskimi, systemami fakturowania, marketplace'ami i innymi usługami wykorzystywanymi przez klienta.

Przed rozpoczęciem integracji określamy, jakie dane powinny być wymieniane, pomiędzy jakimi systemami, w którym kierunku oraz gdzie poszczególne informacje mają być zarządzane.

Integracja może na przykład obejmować synchronizację produktów, cen, stanów magazynowych, zamówień, płatności lub statusów dostawy. Jeżeli celem jest automatyzacja procesu, określamy również, które czynności mają zostać wykonane bez udziału pracownika.

Do wymiany danych wykorzystujemy dostępne API i mechanizmy komunikacji danego systemu. Jeżeli gotowa integracja nie spełnia wymagań projektu, możemy stworzyć dedykowane rozwiązanie.

Takie podejście pozwala połączyć systemy zgodnie z rzeczywistym sposobem pracy firmy, zamiast ograniczać zakres integracji do funkcji dostępnych w gotowej wtyczce.

4. Dedykowane moduły i funkcje

Jeżeli gotowy moduł lub wtyczka nie odpowiada wymaganiom projektu, tworzymy dedykowane rozwiązanie.

Dotyczy to między innymi modułów PrestaShop, rozszerzeń WooCommerce, funkcji panelu administracyjnego, integracji oraz mechanizmów obsługujących specyficzne procesy biznesowe.

Dedykowana funkcja może być potrzebna wtedy, gdy firma ma proces, którego nie obsługuje standardowa platforma, potrzebuje innego sposobu zarządzania danymi albo chce połączyć kilka systemów w sposób niedostępny w gotowych rozwiązaniach.

Przykładem może być funkcja B2B wymagająca indywidualnego sposobu obsługi klientów, cen, uprawnień lub zamówień. Innym przykładem jest dedykowana automatyzacja, która pobiera dane z jednego systemu, przetwarza je i przekazuje do kolejnego.

Tworzenie dedykowanych rozwiązań pozwala dostosować działanie systemu do procesu firmy wtedy, gdy wykorzystanie gotowej funkcji oznaczałoby zbyt duże kompromisy.

5. Standaryzacja kodu i procesu pracy

Stosujemy standaryzację zarówno w kodzie, jak i w sposobie realizacji prac. Mamy określone zasady dotyczące tworzenia i porządkowania kodu, implementacji funkcji, tworzenia modułów oraz pracy z repozytoriami.

Dzięki wspólnym zasadom kod nie jest uzależniony wyłącznie od sposobu pracy pojedynczego programisty. Jeżeli nad projektem pracuje więcej niż jedna osoba, kolejny członek zespołu może łatwiej zrozumieć istniejące rozwiązanie i kontynuować development.

Ma to znaczenie szczególnie przy projektach rozwijanych przez wiele miesięcy lub lat. W takim przypadku osoba, która dołącza do projektu później, musi być w stanie zrozumieć istniejący kod, zależności i sposób implementacji wcześniejszych funkcji.

Standardy dotyczą również procesu pracy. Aktualizujemy zmiany w repozytoriach, porządkujemy zadania, prowadzimy informacje o zmianach i wykorzystujemy ustalone środowiska do realizacji prac.

Jeżeli istniejący kod wymaga uporządkowania, możemy również przeprowadzić refaktoryzację lub inne prace porządkujące. Takie prace mają sens wtedy, gdy poprawiają możliwość dalszego rozwoju, zmniejszają ryzyko kolejnych zmian albo ułatwiają utrzymanie systemu.

6. Środowiska deweloperskie, staging i produkcja

W przypadku projektów, które są już używane przez klientów lub pracowników, prace realizujemy na środowisku deweloperskim. Jeżeli projekt wymaga dodatkowego środowiska stagingowego, wykorzystujemy je do sprawdzenia zmian przed wdrożeniem na produkcję.

Nie wprowadzamy większych zmian bezpośrednio na produkcji w systemach, z których korzystają użytkownicy, szczególnie jeżeli obsługują płatności, zamówienia lub dane użytkowników.

Zmiany są najpierw przygotowywane i testowane poza produkcją, a następnie po weryfikacji ustalamy z klientem termin wdrożenia.

Termin wdrożenia może przypadać w godzinach pracy, poza nimi albo w innym ustalonym czasie. Przy większych zmianach uwzględniamy również sposób działania firmy, kampanie sprzedażowe, sezonowość i znaczenie danego systemu dla biznesu.

Jeżeli zmiana może czasowo ograniczyć dostęp do systemu, informujemy o tym klienta i ustalamy sposób przeprowadzenia prac. W razie potrzeby można również wykorzystać komunikat informujący użytkowników o trwających pracach technicznych.

Rozdzielenie środowisk pozwala sprawdzić zmianę przed udostępnieniem jej użytkownikom końcowym. Ogranicza to ryzyko, że błąd w nowej implementacji wpłynie na sprzedaż, proces zakupowy lub codzienną pracę firmy.

7. Testowanie zmian

Programista realizujący zadanie odpowiada również za jego podstawowe testy. Następnie zmiana może zostać dodatkowo sprawdzona przez innego programistę lub członka zespołu.

Drugi przegląd pozwala spojrzeć na implementację z innej perspektywy i sprawdzić, czy zadanie zostało wykonane zgodnie z założeniami oraz czy nie pojawiły się problemy, których nie zauważyła osoba realizująca zmianę.

Testowanie obejmuje nie tylko samą nową funkcję. W zależności od zakresu zmiany sprawdzamy również powiązane elementy systemu.

W sklepie internetowym może to oznaczać między innymi przejście przez ścieżkę zakupową, sprawdzenie koszyka, zamówienia, płatności, integracji, logowania lub innych funkcji, które mogą zostać dotknięte przez wprowadzoną zmianę.

Testy techniczne wykonuje zespół. Klient może dodatkowo sprawdzić zmianę z perspektywy użytkownika i zweryfikować, czy odpowiada ona ustalonemu sposobowi działania firmy.

Jest to szczególnie istotne wtedy, gdy funkcja ma nietypowy sposób wykorzystania wynikający ze specyfiki działalności klienta. Klient może wskazać, że określona funkcja jest używana w konkretny sposób albo że dany proces powinien wyglądać inaczej z punktu widzenia jego użytkowników.

8. Bezpieczeństwo i odpowiedzialność za zmiany

Przy pracach nad działającymi systemami uwzględniamy ryzyko związane z wdrażaniem zmian. Dotyczy to szczególnie sklepów i systemów obsługujących płatności, zamówienia oraz dane użytkowników.

Przed wdrożeniem większej zmiany sprawdzamy zależności pomiędzy modyfikowanym elementem a pozostałą częścią systemu. Jeżeli zmiana może wpłynąć na inne funkcje, uwzględniamy to podczas testów i planowania wdrożenia.

Dbamy również o możliwość przywrócenia systemu w przypadku problemów. Zakres backupów zależy od infrastruktury i dostawcy hostingu, dlatego przed zmianami produkcyjnymi uwzględniamy dostępne mechanizmy kopii zapasowych oraz sposób odtworzenia systemu.

Nie traktujemy działającego sklepu lub systemu jako środowiska do przypadkowego eksperymentowania. Jeżeli nie mamy pewności, czy dany moduł, biblioteka lub integracja będzie działać poprawnie z pozostałymi elementami projektu, najpierw to sprawdzamy.

Jeżeli rekomendujemy konkretny moduł, dostawcę lub usługę, decyzja powinna wynikać z dostępnych informacji, wcześniejszego sprawdzenia rozwiązania, doświadczeń z danym narzędziem lub współpracy z dostawcą. Nie zakładamy, że popularne rozwiązanie automatycznie będzie odpowiednie dla każdego projektu.

Jeżeli pojawia się aktualizacja bezpieczeństwa, ale jej wdrożenie wymaga dodatkowych zmian technicznych, przedstawiamy klientowi obie strony sytuacji: ryzyko związane z aktualizacją oraz konsekwencje jej niewdrożenia. Pozwala to podjąć decyzję na podstawie rzeczywistego ryzyka, a nie wyłącznie kosztu wykonania aktualizacji.

9. Dokumentacja i historia zmian

Podstawowa dokumentacja projektu powstaje po to, aby sposób działania systemu był zrozumiały również dla osoby, która nie uczestniczyła w jego tworzeniu.

Dokumentujemy najważniejsze funkcje, procesy i zależności. W przypadku integracji opisujemy między innymi sposób przepływu danych i działania poszczególnych elementów procesu.

Przy większych projektach prowadzimy również backlog, changelog i changelist. Dzięki temu można sprawdzić, jakie zmiany zostały zaplanowane, co zostało wykonane oraz jakie modyfikacje pojawiały się w trakcie projektu.

Dokumentacja jest aktualizowana wraz z rozwojem systemu. Dzięki temu informacje dotyczące projektu nie pozostają wyłącznie w kodzie ani w pamięci osób, które pracowały nad nim wcześniej.

Ma to znaczenie przy długotrwałym rozwoju projektu oraz przy zmianach w składzie zespołu. Kolejna osoba może korzystać z zapisanych informacji, zamiast odtwarzać historię rozwiązania wyłącznie na podstawie kodu.

10. Przejęcie istniejącego projektu

Prace programistyczne mogą obejmować przejęcie istniejącego projektu po innym software house lub programiście.

Nie wymagamy, aby klient posiadał pełną dokumentację techniczną. Jeżeli dokumentacja jest dostępna, wykorzystujemy ją do poznania systemu. Jeżeli jej brakuje, analizujemy rozwiązanie bezpośrednio podczas pracy.

W przypadku przejmowanego projektu sprawdzamy między innymi strukturę kodu, zastosowane technologie, moduły, integracje, konfigurację oraz sposób działania istniejących funkcji.

Nie zawsze wykonujemy pełny audyt przed rozpoczęciem współpracy. Możemy rozpocząć od konkretnych zadań i wykorzystać je również do poznania systemu. Jeżeli podczas prac pojawią się problemy lub zależności mające znaczenie dla dalszego rozwoju, informujemy o nich klienta.

Jeżeli klient potrzebuje pełnej oceny stanu technicznego, możemy potraktować audyt jako osobny zakres prac.

Takie podejście pozwala przejąć również projekty, których wcześniejszy wykonawca nie pozostawił z pełną dokumentacją. Jednocześnie klient otrzymuje informacje o istotnych ograniczeniach technicznych w momencie, gdy pojawiają się one w rzeczywistych pracach.

11. Odpowiedzialność za wykonany kod

Odpowiedzialność za prace programistyczne oznacza również odpowiedzialność za decyzje i implementacje wykonane przez Sopchy.

Jeżeli błąd wynika bezpośrednio z naszej pracy, poprawiamy go bez dodatkowego rozliczania klienta za czas potrzebny na usunięcie własnego błędu.

Jeżeli problem wynika z elementu znajdującego się poza naszym zakresem, np. zmiany po stronie zewnętrznego dostawcy, działania hostingu, operatora płatności lub systemu ERP, informujemy klienta o przyczynie i możliwym sposobie dalszego działania.

Odpowiedzialność za własny kod nie oznacza odpowiedzialności za wszystkie elementy zewnętrzne, z których korzysta projekt. Dlatego przy problemach technicznych ustalamy, gdzie znajduje się przyczyna i który element wymaga działania.

Jeżeli podczas realizacji zadania okaże się, że założone rozwiązanie nie jest bezpieczne, stabilne lub możliwe do utrzymania, informujemy o tym klienta zamiast wdrażać je wyłącznie dlatego, że zostało pierwotnie wskazane jako wymaganie.

12. Formy realizacji prac

Prace programistyczne mogą być realizowane jako pojedyncze zadania, większy etap projektu albo stały rozwój istniejącego systemu.

Pojedynczym zadaniem może być na przykład poprawienie błędu, zmiana konfiguracji, dodanie funkcji lub wykonanie konkretnej integracji. Większy zakres może obejmować rozwój całego procesu B2B, przebudowę checkoutu, migrację technologii lub stworzenie większego modułu.

W przypadku większych prac zadania są dzielone na konkretne elementy i rejestrowane w Sopchy Panel. Przy większych projektach prowadzimy również backlog oraz informacje o wykonanych zmianach.

Klient może sprawdzić status zadania, osobę odpowiedzialną, czas pracy i komentarze dotyczące realizacji. Pozwala to śledzić development bez konieczności każdorazowego pytania, co dzieje się z konkretnym zadaniem.

Prace programistyczne rozliczamy godzinowo. Zakres prac może być dzięki temu zwiększany lub zmniejszany w zależności od aktualnych potrzeb projektu. Przy większych zakresach najpierw określamy założenia i przygotowujemy estymację na podstawie dostępnych informacji.

Podsumowanie

Prace programistyczne w Sopchy obejmują zarówno pojedyncze zmiany, jak i rozwój większych sklepów, platform sprzedażowych, systemów B2B oraz dedykowanych aplikacji webowych.

Pracujemy z istniejącymi systemami i tworzymy nowe rozwiązania. Możemy rozwijać PrestaShop, WooCommerce, Magento, Shopware i Shopify, a także tworzyć dedykowane rozwiązania oparte między innymi na PHP, Laravel, Symfony, JavaScript, React i Node.js.

Zakres developmentu może obejmować nowe funkcje, moduły, integracje API, automatyzacje, procesy B2B, panele administracyjne, zmiany procesu zakupowego, aktualizacje, migracje i optymalizację istniejącego kodu.

Istotną częścią prac jest również sposób ich realizacji. Analizujemy zakres i zależności, dobieramy rozwiązanie techniczne, pracujemy na środowiskach innych niż produkcja, testujemy zmiany, dokumentujemy istotne elementy projektu i przyjmujemy odpowiedzialność za własne implementacje.

Dzięki temu development jest częścią działającego systemu firmy, a nie wyłącznie wykonaniem pojedynczego zadania programistycznego. Każda zmiana powinna uwzględniać istniejącą architekturę, sposób pracy użytkowników, zależności z innymi systemami oraz możliwość dalszego rozwoju projektu.