1 / 25

Continuous Integration i jakość kodu

Continuous Integration i jakość kodu. Michał Prajs. Agenda. Michał Prajs. SMT Software Prowadzący Continuous Integration Jenkins CI Statyczna analiza kodu Checkstyle Pokrycie kodu testami jednostkowymi Cobertura. SMT Software. Na rynku od 2002 roku Ponad 500 specjalistów IT

jaron
Download Presentation

Continuous Integration i jakość kodu

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Continuous Integration i jakość kodu Michał Prajs

  2. Agenda

  3. Michał Prajs • SMT Software • Prowadzący • Continuous Integration • Jenkins CI • Statyczna analiza kodu • Checkstyle • Pokrycie kodu testami jednostkowymi • Cobertura

  4. SMT Software • Na rynku od 2002 roku • Ponad 500 specjalistów IT • 7 oddziałów na terenie kraju: Wrocław (siedziba główna), Warszawa, Poznań, Kraków, Gliwice, Katowice, Białystok • Oddziały w Holandii, Francji, Wielkiej Brytanii • Część grupy kapitałowej Grupa SMT S.A. notowanej na GPW • Outsourcing IT • Specjaliści • Zespoły • Usługi zarządzane • Projekty informatyczne • Dedykowane • Online • Mobilne • Testy i audyty

  5. Michał Prajs • Współpracuje z SMT od ponad dwóch lat • Programista i techniczny leader zespołu • Specjalista Javy i frameworków na niej opartych • Wprowadza do projektów praktyki pozwalające na łatwy rozwój i utrzymanie oprogramowania

  6. Continuous Integration

  7. Firma software’owa • Czym się zajmuje? • Kto tworzy software? • Jak?

  8. Zamierzchłe czasy • Rozdzielamy projekt na zadania niezależne • Integrujemy części wytworzone przez zespoły • Same wady: • Konieczność wczesnego zdefiniowania punktów styku między modułami • Trudność wprowadzania zmian – mogą dotyczyć kilku zespołów • Czasochłonność integracji i wysokie prawdopodobieństwo porażki

  9. Obecnie, ale bez CI (z wykorzystaniem SCM) • Rozdzielamy zadania tak jak poprzednio • Centralne repozytorium kodu • Kilka wad zostało • Mała odporność projektu na zmiany • Nadal trzeba zintegrować moduły

  10. Continuous Integration • Częste zmiany wymagań • …a nawet samej architektury systemu • Wybredni klienci • Korzyści: • Częste budowanie całego systemu • Każde wgranie kodu do repozytorium sprawdzane (serwer CI robi update przed każdym buildem) • Automatyczne uruchamianie testów jednostkowych i integracyjnych • Gotowe artefakty na testy akceptacyjne, gotowy produkt • Prowadzenie metryk • „U mnie działa”? Pfffff…..

  11. Build CI • Sukces • Archiwizacja kodu • Archiwizacja wytworzonych artefaktów • Statystyki metryk • Porażka • Informacja dla zespołu • Poprawki na gorąco

  12. No to do dzieła • Repozytorium (SVN, CVS, TFS, GitHub, itp.) • Narzędzie do budowania (Maven, Ant) • Testy jednostkowe, integracyjne (JUnit, Mockito, PowerMock) • Analiza statyczna kodu (Checkstyle, PMD) • Serwer CI (Jenkins, Apache CI) • Archiwizacja kodu • Archiwizacja artefaktów • Zadania powykonawcze (auto deploy)

  13. Analiza statyczna koduCheckstyle

  14. Analiza statyczna kodu • „Czystość kodu” • Jednolity kod • Czytelność kodu • Rozszerzalność • Udokumentowany kod • Łatwość utrzymania/serwisowania • Wskazuje miejsca nadające się do refactoringu

  15. Checkstyle • Konfiguracja kontroli standardowych • Integracja z narzędziami do budowania (Mavenplugin) • Integracja z narzędziami do programowania (Eclipseplugin) • Integracja z CI (Jenkins plugin) • 133 standardowe czujki

  16. Design klasy • VisibilityModifier • Wymusza enkapsulację • FinalClass • Wymusza modyfikator final w klasie, która ma tylko prywatne konstruktory • InterfaceIsType • Interface nie powinien jedynie definiować stałych • HideUtilityClassConstructor • Instancja takiej klasy nie ma sensu • DesignForExtension • Wymusza styl programowania, gdzie klasy nadrzędne pozostawiają miejsca, które mogą być nadpisane przez klasy podrzędne, czyli nieprywatna, niestatyczna metoda w klasie nadrzędnej musi być: • Abstrakcyjna lub • Finalna lub • Mieć pustą implementację

  17. Design klasy cd. • MutableException • Wykrywa gdy wyjątek może zmienić swój stan w trakcie cyklu życia • ThrowsCount • Gdy metoda rzuca wyjątki z różnych grup, prowadzi to do złych praktyk, jak łapanie ogólnych wyjątków, jak catch (Exception) • InnerTypeLast

  18. Metryki • BooleanExpressionComplexity • ClassDataAbstractionCoupling • ClassFanOutComplexity • CyclomaticComplexity • NPathComplexity • JavaNCSS

  19. Pozostałe grupy • Konwencje nazewnictwa • Wymuszenie rozmiaru pliku/klasy/metody/linii • Długość linii • Ilość parametrów metody • Polityka pustych znaków • Wyrównanie

  20. Testy jednostkowe

  21. Testy jednostkowe • Test Driven Development • Testy jednostkowe • Mockowanie obiektów • Testy integracyjne

  22. Motywacja • Eliminacja błędów już podczas programowania • Ograniczenie czasu potrzebnego na bugfixing • Poprawność modyfikacji

  23. Pokrycie kodu • Procent w jakim kod jest sprawdzony przez testy jednostkowe • Wszystkie rozgałęzienia • Sytuacje wyjątkowe

  24. Pytania? • „Wolałbyś walczyć z kaczką wielkości konia, czy ze stoma końmi wielkości kaczki?”

More Related