Dbanie o jakość kodu w dużej organizacji
Łukasz Młyński LPP S.A.
Poznań, 30.06.2018r.
Łukasz Młyński
Cześć – jestem Łukasz ☺.
Pracuję w LPP.
Z zamiłowania to bym był aktorem (lub komentatorem sportowym)
…
ale programowanie też jest świetne ☺
O czym będę mówił
Po co nam
jakość kodu deweloperzy”„My Jakość kodu a organizacja
Automatyzacja,
narzędzia
Korzyści dla
organizacji
Słów kilka o kodzie i jakości - „z czym to się je”
Źródło: [1]
Czym jest jakość oprogramowania?
Ogół cech produktu (aplikacji), które wpływają na zdolności spełniania przez niego określonych wymagań, m.in. elastyczność , funkcjonalność , integralność , niezawodność , efektywność ,
użyteczność , wydajność .
Cykl życia aplikacji
Definiowanie wymagań Projektowanie
Programowanie
Integracja (wdrożenie) Utrzymanie, rozwój
Specyfika wytwarzania oprogramowania
1. Rotacja pracowników
2. Branża bardzo „agile” - częste zmiany koncepcji, projektów, członków zespołu itp …
3. Nowe zadanie => często kosztowna analiza, duży poziom niepewności, koszt zdobywania wiedzy procesowej
Specyfika wytwarzania oprogramowania
Źródło: [2]
„Nie piszemy kodu dla siebie, lecz dla innych
programistów”
Edward Aloysius Murphy, Jr
Prawa Murphy’ego
„Jeśli coś jest głupie, ale działa, to nie jest głupie”
Źródło: [2]
Prawa Murphy’ego
„Prowizorka zawsze okazuje się najtrwalsza”
Źródło: [2]
„Trytytka”!!!
Jakoś vs
Jakość
Co programiści mogą zrobić
Źródło: [4]
Nie pytaj się co firma może zrobić w kwestii jako ści kodu
Pytaj co
Ty
możesz zrobić w kwestii jakości koduPisanie „czystego”,
„dobrego” kodu
Odpowiednie nazewnictwo
▪ Repozytoria, projekty
▪ Foldery, pliki
▪ Klasy, interfejsy
▪ Metody, funkcje
▪ Zmienne, stałe
▪ …
„There are only two hard things in Computer Science: cache invalidation and naming things.”
-- Phil Karlton
Odpowiednie nazewnictwo
Nazwy MAJĄ znaczenie
Źródło: [2]
Źródło: [6]
„Less is more”
1. Małe klasy, metody, funkcje
2. Mniejsza liczba parametrów w funkcjach, metodach, właściwości w klasach
3. Umiejętne komentowanie kodu 4. No „dead code”
Nieskomplikowane warunki logiczne
Wzorce projektowe
Źródło: [5]
Fajnie brzmiące akronimy
Pisanie
SOLID
nego kodu1. S ingle responsibility principle 2. O pen/closed principle
3. L iskov substitution principle 4. I nterface segregation principle 5. D ependency inversion principle
Don’t be
STUPID
1. S ingleton
2. T ight coupling 3. U ntestability
4. P remature Optimalization 5. I ndescriptive Naming
6. D uplication
Kolejne fajnie brzmiące akronimy
1. DRY – Don't Repeat Yourself 2. KISS – Keep It Simple, Stupid
3. YAGNI - You Aren't Gonna Need It 4. TDA – Tell, Don't Ask
Zasada skautów
„Zawsze zostawiaj obóz czystszym niż go zastałeś”
Formatowanie kodu /
PSR
Sprawdzanie / review kodu
1. Częste code review (lecz niewielkiej ilości kodu) 2. Konstruktywna krytyka
3. Uczenie się robiąc code review
„Ask a developer to review 10 lines of code, he'll find 10 issues.
Ask him to do 500 lines and they'll say it looks good”.
Testowanie
1. Testy jednostkowe 2. Testy funkcjonalne 3. Testy automatyczne 4. Testy wydajnościowe 5. Testy integracyjne
6. …
Co można zrobić w ramach organizacji?
„Wspólnymi siłami”
1. Ustalenie standardów kodowania / formatowania 2. Spisanie standardów, upublicznienie
3. Przestrzeganie zasad, respektowanie ich
4. Automatyzacja, wykorzystanie pomocniczych narzędzi
Test Joela
1) Czy używasz systemu kontroli wersji?
2) Czy możesz zbudować wersję w jednym kroku?
3) Czy stosujesz codzienne budowanie wersji?
4) Czy używasz systemu zarządzania błędami?
5) Czy usuwasz błędy zanim napiszesz nowy kod?
6) Czy masz harmonogram aktualizowany na bieżąco?
7) Czy masz specyfikację?
8) Czy programiści mają komfortowe warunki pracy?
9) Czy używasz najlepszych dostępnych narzędzi?
10) Czy masz testerów?
11) Czy kandydaci piszą kod podczas rozmowy kwalifikacyjnej?
12) Czy praktykujesz korytarzowe testy wygody użytkowania?
@LPP
Proste triki, narzędzia,
automatyzacja
„Potęga” naszego IDE
Code Sniffer
Sonarqube
Sonarqube
Sonarqube
Sonarqube
Sonarqube
Sonarqube
Sonarqube
Korzyści dla organizacji
1. Mniejszy czas na wdrażanie nowych funkcjonalności do aplikacji
2. Szybsze wdrażanie nowych pracowników w kod projektu
3. Łatwiejsze aktualizacje wersji (np. języka programowania, kodu aplikacji itp…)
4. Mniej „nieoczekiwanych” błędów, aplikacja stabilna 5. Spokojny sen :)
Pytania?
Bibliografia i źródła
1) https://starecat.com 2) http://demotywatory.pl 3) http://mklr.pl
4) http://www.gazetaprawna.pl 5) https://www.script-tutorials.com 6) https://9gag.com
