Dlaczego ktoś grzebał w moim kodzie i co z tego wyniknęło

W poprzednim artykule z tej serii opisaliśmy jak można korzystać z feedbacku aby stać się lepszym developerem i człowiekiem. Tym razem, odpowiadając na wasze komentarze, opiszemy RevYou ­- system który umożliwia poprawę naszych umiejętności kodowania i tym samym tworzenie rozwiązań wysokiej jakości.

Czy to już Github Comments 3.0

RevYou to wewnętrzny system zintegrowany z Githubem, którego celem jest poprawa jakości kodu w tworzonych przez nas aplikacjach. Podstawowy mechanizm systemu oparty jest na założeniu, że każdy developer w firmie może przeglądać zmiany w kodzie wprowadzone przez pozostałe osoby i w zależności od posiadanej wiedzy czy doświadczenia, zgłaszać swoje uwagi lub podpatrywać najlepsze rozwiązania. Wykorzystany mechanizm wzajemnej weryfikacji kodu działa na podobnej zasadzie jak funkcja komentarzy na Githubie jednakże w odróżnieniu od tej paltformy, RevYou daje pewność, że weryfikacja rzeczywiście miała miejsce. Użytkownicy oceniają fragmenty kodu tworzone przez innych współpracowników, a system pilnuje, aby każdy fragment kodu został oceniony.

System, który zna twoje mocne strony

RevYou przechowuje każdy nowy commit na liście „do sprawdzenia” do czasu, aż cały zostanie gruntownie przejrzany i/lub skomentowany przez co najmniej jednego dewelopera. Jako że nie każdy deweloper jest ekspertem we wszystkich tematach czy technologiach, dany użytkownik ma możliwość oceny wybranej części zmian w danym commicie i pozostawienia innych fragmentów do oceny bardziej doświadczonych programistów – ma to szczególne znaczenie, gdy zmiany dotykają wielu języków i technologii. Kolejną cechą RevYou różnicującą to narzędzie względem Githuba jest zakres w jakim działa. W przypadku Github zwyczajową praktyką jest weryfikacja zmian na projekcie (zwykle w postaci PullRequestów), na którym samemu się pracuje. W RevYou natomiast użytkownicy mają możliwość przeglądania zmian na projektach w całej organizacji. Poza prostym opisem tekstowym, oceniający może także dołożyć jeden lub więcej predefiniowanych tagów do danego komentarza, oznaczając go na przykład jako dotyczący wydajności bądź składni. Umożliwia to wykrycie w jakich aspektach dany koder nie ma żadnych problemów, a nad jakimi mógłby popracować.

Każdy komentarz do naszego kodu badź kodu który oceniliśmy ląduje na osobnych listach ­ma to zapewnić, że wszystkie komentarze zostaną przeczytane, a każda dyskusja zakończona jakąś konkluzją.

Kod zrozumiały dla wszystkich

Korzyści wynikających z korzystania z RevYou jest wiele. Oceniający może dowiedzieć się o nowych technologiach i rozwiązaniach poprzez sprawdzanie kodu innych programistów, co jest szczególnie przydatne w dzieleniu się wiedzą między projektami. Co więcej, komentując dany fragment kodu, developer przyczynia się do szerzenia dobrych praktyk i technik w swoim zespole lub nawet w całej firmie, co jest z kolei nie do przecenienia podczas szkolenia młodszych programistów.

Oczywistą zaletą jest bardziej efektywne działanie w zakresie zapewnienia jakości (QA). Kiedy kod jest dokładnie sprawdzony, mamy większe szanse na wyeliminowanie złych rozwiązań i błędów podczas procesu wdrażania, a jakość kodu jest znacznie lepsza. Co więcej, jako że sam kod staje się bardziej jednolity, jest tym samym łatwiejszy do zrozumienia i utrzymania przez innych programistów, którzy mogą pracować nad danym projektem w przyszłości.

revyou2

Dlaczego właśnie RevYou?

Nie będzie niespodzianką, że na rynku istnieją już rozwiązania służące do komentowania kodu. Od wspomnianych już komentarzy w GitHub poprzez komercyjne rozwiązania dedykowane jak Code Brag czy też Atlassian Crucible aż po mnogie rozwiązania wewnątrz poszczególnych firm. W tej konkretnej sytuacji rozwiązania te były jednak albo zbyt rozbudowane, albo na wczesnym etapie rozwoju, albo po prostu zamknięte, uniemożliwiające dostosowanie ich do naszych potrzeb. Stąd decyzja o stworzeniu wewnętrznego rozwiązania dedykowanego tym potrzebom.

Przyszłość RevYou

RevYou zdecydowanie nie rozwiązuje wszystkich problemów związanych z oceną kodu. Warto równolegle korzystać z innych narzędzi, bądź to dostarczających metryki (np. PullReview, CodeClimate, ruby­metrics) bądź też zapewniających automatyczne komentarze do kodu (np. Hound). RevYou nie zastąpi też spotkań i dyskusji w grupie – omawianie odgórnych ustaleń dotyczących standaryzacji podejścia do danych problemów lub wreszcie planowanie usprawnień w architekturze aplikacji wymaga szerokiego spojrzenia na dane rozwiązanie i nie może być zrealizowane poprzez narzędzie koncentrujące się na małych zmianach. Nie jest aspiracją RevYou by zaadresować wspomniane aspekty -­ rozwój tego projektu będzie skoncentrowany na poprawianiu stabilności, łatwości użycia oraz wszelkich zmianach skłaniających do dokładnego i efektywnego weryfikowania kodu.

Wnioski

Niezależnie od użytego rozwiązania, wszelkie praktyki skłaniające zespoły do wzajemnej oceny kodu wyraźnie wpływają na jakość tegoż kodu. Poprawie nie ulega jedynie sama składnia ­- spada wyraźnie ilość błędów, wzrasta świadomość tego “kto w czym jest biegły”, kod staje się czytelniejszy, a poszczególne rozwiązania ulegają standaryzacji pomiędzy zespołami.

Developer Ruby od 2006 roku, obecnie poza programowaniem zajmuje się kontrolą jakości kodu, procesu jego produkcji oraz propagowaniem dobrych praktyk w firmie Selleo. Entuzjasta dobrych seriali i airsoftu.

  • Jacek Jackowiak

    Wszystko fajnie, ale dlaczego wymuszać review każdego commitu, zamiast tylko tego co ma zostać dołączone do głównej gałęzi kodu.

    • kolczyk

      Również tego nie rozumiem, ciekawe który PM się zdecyduje na kolejne
      marnowanie czasu, bo programiści sobie kolejną zabawkę wymyślili 😉 Spotkania, komentarze, oglądanie kodu, nauka, a robić nie ma komu 🙂

      • Jacek Jackowiak

        Nie no, samo review jest jak najbardziej ok i nie rozumiem zespołów które tego nie stosują. Pytanie tylko po co przeglądać zmiany w kodzie który być może nigdy na produkcję nie trafi (bo zmiana zostanie nadpisana kolejnym lokalnym commitem), chyba że zespół zawsze wymaga squashowania commitów przed wypychaniem ich do zewnętrznego repozytorium.

  • Tomasz Kane

    Dobrym rozwiązaniem może być otwarty http://code.google.com/p/gerrit/

    Stoi między programistą a repozytorium i nie pozwala wpuścić niesprawdzonego kodu.

Send this to friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL