Jak zarządzać kodem - poradnik dla nietechnicznych

Tworząc produkt w internecie warto od samego początku stworzyć procedury, które zminimalizują ryzyko różnego rodzaju kryzysów i zagrożeń. Dla osób z doświadczeniem technicznym duża część z tych rzeczy to oczywistość. Dla nietechnicznych - to kwestie, o które trzeba zapytać partnera technologicznego. Możesz nie znać szczegółów, ale ogólnie musisz wiedzieć o co w tym wszystkim chodzi.

Kod źródłowy aplikacji

Kod i to co potrafi, to jeden z głównych elementów przewagi konkurencyjnej w aplikacjach internetowych. Trzeba go chronić i dbać o niego w szczególny sposób. Przede wszystkim system kontroli wersji - jeśli jeszcze go nie stosujesz, to bardzo źle. Dobry system kontroli wersji to ratunek przed wpadkami, które dzieją się, gdy nad kodem pracuje kilka osób. Pilnuje, żeby nikt nie nadpisywał sobie plików, oraz by istniała jedna, spójna wersja aplikacji, do której dostęp posiadają wszystkie osoby uprawnione.

My polecamy GITa, ale jeśli Twój zespół ma doświadczenie w innych systemach, można też wykorzystać Bazaar, Mercurial, czy starego dobrego SVNa. Git ma przewagę dzięki genialnemu serwisowi Github, którym możesz hostować swój kod w pakiecie z wieloma udogodnieniami.

Poza kodem Twoja aplikacja składa się jeszcze z bazy danych oraz repozytorium plików i obrazków. Warto zadbać, aby te 3 elementy były jedynymi wymaganymi do działania systemu - dlatego powinniśmy w kodzie trzymać też konfigurację serwera, czy inne poboczne elementy systemu, które mogą się zmieniać i ewoluować wraz z kodem.

Takie podejście zapewni Ci możliwość szybkiego "postawienia" serwisu od nowa nawet wówczas, kiedy Twój produkcyjny serwer spłonął w pożarze.

Czego nie powinniśmy trzymać w repozytorium, to hasła. Dobrą praktyką jest stworzenie jednego pliku konfiguracyjnego, który będzie przechowywał wszystkie wymagane hasła i kody dostępu. Ten plik powinien znajdować się poza repozytorium, tylko na serwerze i w bezpiecznym miejscu u uprawnionego developera. Hasła trzeba bezwzględnie generować generatorami haseł i przechowywać na dyskach TYLKO w postaci zaszyfrowanej (polecamy 1Password).

Jest wiele metodologii tworzenia kodu. Tradycyjnie przyjmuje się, że każdy programista tworząc nową funkcjonalność powinien stworzyć nową gałąź (wersję) repozytorium i w nim powoli tworzyć całość swojej pracy, aby na koniec ktoś przyłączył tę gałąź z powrotem do głównego drzewa. My uważamy, że w przypadku startupów jest to droga nieefektywna. Jeśli team nie jest większy niż 4 programistów, czas, który trzeba przeznaczyć na "łączenie" poszczególnych gałęzi, jest nieproduktywny. Każdy powinien pracować na jednej wersji i kilka razy dziennie integrować kod z innymi.

Dobre praktyki wymusza framework, czyli silnik, na którym budujemy swoją aplikację. Frameworki to pewien narzut, często programiści nie chcą ich stosować, bo ich zdaniem spowalnia to zarówno sam proces, jak i działanie aplikacji. Jednak szczególnie w przypadku startupów ważny jest czas, jaki można zaoszczędzić wykorzystując gotowe elementy, które ma wbudowany każdy dobry framework.

Facebook i Twitter mogą właśnie pozwolić sobie na frameworki lub szyte na miarę technologie. Do czasu osiągnięcia tej skali, lepiej trzymać się silników sprawdzonych przez setki lub tysiące programistów. Warto zauważyć, że Twitter do niedawna też był oparty na frameworku Ruby on Rails.

Testy

W każdym nowoczesnym podręczniku programowania znajdziemy rozdziały na temat tego, jak ważne są automatyczne testy oprogramowania. Niestety, proces ten jest bardzo łatwo zaniedbać. Przecież trzeba naprawić superważny błąd albo klient czeka na strasznie pilną funkcjonalność, a na mojej przeglądarce działa...

Testy to ubezpieczenie. Nie są potrzebne tak długo, jak wszystko jest ok. Każda aplikacja, która jest rozwijana bez testów, prędzej czy później (raczej prędzej) trafi na moment, w którym uruchomienie nowej funkcji sprawi, że inne przestaną działać. Automatyczne testy mają przed tym chronić.

W jaki sposób "zmusić" zespół do pisania i utrzymywania testów? Warto stworzyć system automatycznego uruchamiania testów po każdej zmianie w kodzie (tzw. Continuous Integration). Szczególnie przydatne, a zarazem proste do wdrożenia mogą być testy składni - np. Javascript potrafi dobrze działać na jednej przeglądarce, ale już w Internet Explorerze zupełnie odmówić posłuszeństwa w przypadku najdrobniejszego braku średnika. Niektóre narzędzia pozwalają też automatycznie sprawdzać zastosowanie "najlepszych praktyk" i odrzucać zmiany, które wprowadzają "nieładny" kod.

Często korzystamy z zewnętrznych API serwisów takich, jak Facebook, czy mniejsi dostawcy usług. Warto testować czy ich API przypadkiem się nie zmieniło i czy nie będzie to miało wpływu na nasz serwis. Nie wszyscy komunikują zmiany w odpowiedni sposób i z wystarczającym wyprzedzeniem.

Dobrą zasadą przy poprawianiu błędów jest każdorazowe napisanie testu, który nie przechodzi przed poprawką, a przechodzi po. Uchroni nas to przed jednym z bardziej irytujących rodzajów błędów, czyli takich, które uporczywie powracają mimo każdorazowego ich poprawiania.

Code review

Testy to rodzaj hamulca awaryjnego, który nie pozwala dużym błędom wchodzić na produkcyjny serwer. Dobrze jest jednak ciągle dbać o jakość kodu, o to, żeby był optymalny, przejrzysty, zgodny ze standardami i naszymi wewnętrznymi procedurami. W małym teamie najlepszy do tego jest tzw. "Code Review", czyli przegląd kodu. Można to robić bez dodatkowych narzędzi, ale najlepiej wdrożyć mechanizm, który będzie wymagał, aby każda zmiana była zatwierdzona przez drugiego programistę i w przypadku braku takiego zatwierdzenia kod przestaje przechodzić przez system testów automatycznych.

Takie "peer review" po pierwsze sprawia, że kod musi być czytelny. Po drugie, nie wypada wrzucać do repozytorium kodu niechlujnego, bo ktoś z kolegów go wyśmieje. Po trzecie, każdy mniej więcej wie nad czym pracują inni, więc w razie czego mogą się wspierać lub zastępować. Dodatkowa para oczu oznacza też, że można łatwo wyłapywać ciekawe kawałki kodu i uczyć się wzajemnie od siebie. Świetnie do tego sprawdza się Github, który umożliwia komentowanie każdej linijki kodu wysyłając powiadomienia do wszystkich developerów.

W wielu firmach w SV stosuje się też tzw. pair programming, czyli programowanie w parach. Dwóch programistów siedzi razem i razem tworzą linie kodu. To bardzo ciekawa technika, która przynosi rewelacyjne wyniki. Warto się nią zainteresować.

Kod łatwiej się pisze niż czyta. To zupełnie odwrotne reguła niż w literaturze. Dodatkowo, im więcej czasu minęło od powstania danej linijki kodu, tym trudniej przypomnieć sobie lub dojść, jak miał on działać. Peer review, automatyczne testy, czy pair programming pomagają dostrzec problemy na najwcześniejszym możliwym etapie i zdusić je w zarodku.

Kuba Filipowski - zarządza firmą oferującą system do rekrutacji pracowników Humanway, jest również współzałożycielem Netguru - spółki, która tworzy aplikacje internetowe.

Wiktor Schmidt - zarządza zespołem developerów w firmie oferującej system do rekrutacji pracowników Humanway oraz w firmie Netguru - tworzącej aplikacje internetowe.

Więcej o:
Komentarze (1)
Jak zarządzać kodem - poradnik dla nietechnicznych
Zaloguj się
  • advertum

    Oceniono 1 raz 1

    Co się stało, że na gazecie nagle pojawił się materiał związany z programowaniem? Pewnie następne będą poradniki o PHP ;)

    ----------
    Naprawiają laptopy zawodowo!

Aby ocenić zaloguj się lub zarejestrujX