Jak uniknąć problemów z przejęciem kodu zleconego innej firmie?

Wielu programistów – zapytanych o największy koszmar w ich życiu zawodowym – wskazuje pracę na kodzie stworzonym przez inny zespół czy firmę. Nic w tym dziwnego. Bez odpowiedniego zadbania o proces zlecania i odbierania kodu firma może otrzymać tysiące chaotycznie napisanych linijek, nad którymi potrafi zapanować wyłącznie ich twórca.

Artykuł przygotował Tomasz Janusz. Chief Technology Officer w firmie Indoorway (Grupa Daftcode), która digitalizuje budynki. Tomasz zajmuje się tworzeniem aplikacji internetowych od ponad 15 lat. Przez wiele lat współtworzył jeden z największych portali technologicznych w Polsce. Pracował zarówno przy backendzie, jak i frontendzie, choć sercem zawsze był przy tym drugim. Niekiedy tęskni za czasami, gdy można było wykonywać kod JS w arkuszach CSS w Internet Explorerze.

Przy natłoku projektów, dość często zdarzają się sytuacje, kiedy część pracy startup musi zlecić na zewnątrz, a następnie zaadaptować dostarczony kod do swojego rozwiązania. Brak czasu, braki kadrowe lub nagły, intensywny rozwój biznesu sprzyjają takiemu obrotowi zdarzeń. Jednak otrzymanie kodu od dewelopera, czy software house’u to dopiero początek przygody. Co zrobić, żeby wchodzenie w cudze buty przebiegło bezproblemowo? Jakie wytyczne dać podwykonawcy, aby dostać to, czego oczekujemy i jak połapać się w otrzymanym kodzie?

Zlecenie wykonania produktu w innej firmie jest bardzo ważnym i wrażliwym na wszelkie zawirowania procesem, od którego zależy przyszłość głównego produktu. Dlatego warto dobrze go zaplanować już od samego początku. Wobec takiego zlecenia można przyjąć dwie różne postawy. Zwolennicy pierwszej z nich wychodzą z założenia, że kod ma “po prostu działać”, bez względu na jego jakość i architekturę. W wyniku takiego podejścia mogą jednak wystąpić problemy ze skalowalnością, a pominięcie testów integralności (jednostkowych lub end-to-end) jest ryzykowne dla całego produktu i może w przyszłości zahamować lub spowolnić jego rozwój.

Przede wszystkim współpraca

Drugie podejście, zdecydowanie preferowane przez Indoorway, to ciągły nadzór nad tworzonym kodem. Wymaga on współpracy z Team Leaderami w firmie zewnętrznej, co częściowo spowalnia proces, ale gwarantuje zgodność z politykami jakości kodu zlecającego. Kiedy decydujemy się na większe zaangażowanie w prace nad zleconym kodem, bierzemy udział w podejmowaniu decyzji na temat jego architektury i na bieżąco jesteśmy świadomi jego potencjalnych wad czy niedociągnięć.

Jak najlepiej zainicjować taką współpracę? Na początek można rozważyć udostępnienie podwykonawcy dokumentacji wytycznych jakości kodu, najlepiej jeszcze przed pierwszym spotkaniem. Daje to podwykonawcy ogląd sytuacji, pozwala lepiej zaplanować i wycenić prace. Niestety bardzo często dokumentacja wytycznych jakości kodu to w firmach dokument pomijany – traktuje się go po macoszemu lub nie tworzy w ogóle. Warto więc zawczasu usystematyzować wytyczne i zebrać je w jednym pliku – będą przydatne zarówno przy zlecaniu zadań zewnętrznie, jak i przekazywaniu dobrych praktyk nowym pracownikom firmy.

Oferty pracy z

Ważne również, aby w ustaleniach pomiędzy firmą, a jej podwykonawcą uczestniczyły nie tylko osoby odpowiedzialne za stronę biznesową, ale i pracownicy, którzy bezpośrednio pracują nad rozwijaniem kodu. Zaplanowanie spotkań czysto technicznych, pomiędzy zespołami programistów, pozwoli na lepsze poznanie tworzonego produktu, precyzyjne przekazanie idei i ustalenie “flow” prowadzonych prac. To też dobra okazja, żeby poznać ludzi zajmujących się danym projektem, co ułatwi dalszą komunikację.

Warunki współpracy zostały ustalone i wymieniliście się uściskami dłoni z programistami po drugiej stronie? Świetnie. Pora przejść do właściwych prac nad kodem, podczas których dobrze pamiętać o trzech kluczowych zasadach:

1. Jeżeli zlecony kod ma być integralną częścią rozwijanego już wcześniej produktu, ważne aby w pierwszej kolejności przygotować modele przepływu danych między kodem “zewnętrznym” (zleconym), a kodem, który był dotychczas rozwijany.
2. W przypadku usług sieciowych dobrą praktyką jest możliwie wczesne przygotowanie kontraktów – np. przy pomocy Swaggera.
3. W przypadku produktów czysto backendowych warto ustalić wersję interpreterów oraz środowiska, w jakim będą one docelowo pracować. Natomiast w przypadku produktów frontowych – minimalne wymagania związane z wersjami przeglądarek internetowych.

Klienci zawsze oczekują, aby zadania były realizowane w sposób możliwie przewidywalny, nie należy więc ukrywać produktu podczas jego tworzenia. Prace przebiegają o wiele sprawniej, gdy podwykonawca i firma przechodzą przez proces tworzenia produktu wspólnie. Trzeba dbać, aby obie strony miały swój udział na każdym etapie prac. W tym celu zleceniobiorcy powinni udostępniać na bieżąco wersje testowe produktu. W przypadku aplikacji internetowych może być to rozwiązane w postaci dedykowanej strony internetowej, a w przypadku aplikacji mobilnych przez platformy Fabric czy TestFlight.

Kolejny etap – przekazywanie kodu

Gdy kontrakt dobiega końca, warto poświęcić czas na zapoznanie się zespołu programistów z kodem stworzonym w firmie zewnętrznej. Z doświadczenia Indoorway wynika, że najlepiej, aby była to możliwie jak największa liczba osób, co pozwoli uniknąć tworzenia tzw. silosów. Kiedy pełną wiedzę o danym projekcie ma tylko jedna osoba, nietrudno o sytuacje kryzysowe w razie jej nieobecności lub niedyspozycji.

Z pomocą we wgryzieniu się w kod i zrozumieniu jego zawiłości powinni przyjść zleceniobiorcy, którzy dobrze znają stworzony produkt. Warto także zwrócić uwagę na to, czy kod jest odpowiednio udokumentowany, czyli czy zawiera przystępną “instrukcję obsługi”. Dobra dokumentacja pozwoli na szybkie wdrożenie zespołu w dany kod, a także będzie dobrym punktem wyjścia dla osób, które w przyszłości będą zatrudnione przy projekcie.

Testowe wersje produktu powinny być, o ile nie były w procesie developmentu, uruchamiane w środowiskach testowych docelowej infrastruktury. Firma pisząca kod musi wiedzieć w jakiej docelowej wersji oprogramowania dana usługa ma być uruchomiona. I mówimy tu zarówno o programowaniu systemowym, jak i webowym. Zaleca się też, aby kod przeszedł testy wydajnościowe, co pozwoli firmie zlecającej na lepsze oszacowanie kosztów użytkowania.

Problemy z kodem to temat rzeka

Na szczęście dzięki budowaniu dobrych relacji ze zleceniobiorcami, w Indoorway zawsze mogliśmy zadbać o płynne przeniesienie kodu do naszej firmy. Jednak zanim wypracowaliśmy świetnie działający schemat, uczyliśmy się na błędach przy innych projektach i zleceniach. Zdarzyło się na przykład, że ustępujący miejsca deweloper w jednej z moich poprzednich firm nie zostawił po sobie żadnego schematu bazy danych ani żadnego pliku tekstowego, który oprowadzałby jego następców – w tym przypadku mnie – po architekturze. Jakość jego kodu też pozostawiała wiele do życzenia. To najbardziej skrajny przypadek, ale nauczył mnie, że trzeba dokładnie planować prace i formułować wymagania wobec podwykonawcy.

Teraz już wiem, że najważniejsze z perspektywy osoby przejmującej kod jest to, czy został on poprawnie opisany: zaczynając od przewidywalnych i czytelnych nazw metod aż po komentarze pomocnicze. Dobrą praktyką jest więc tworzenie kodu, który automatycznie się dokumentuje. Każdy popularny język ma stosowne narzędzia wspomagające tworzenie tego typu kodu i wiele bibliotek stosuje taki sposób dokumentacji.

Po czym rozpoznać dobrego podwykonawcę? Jeśli chcecie mieć pewność, że świadczy usługi wysokiej jakości, już przy pierwszym kontakcie zwróćcie uwagę na to, czy pyta o stanu kodu i czy planuje przeprowadzić jego szczegółowy audyt. Jeśli tak, możecie śmiało negocjować dalej.