---
# System prepended metadata

title: W kupie raźniej

---

---
slideOptions:
  transitionSpeed: fast
  margin: 0
  width: 90%
  height: 100%
  minScale: 1
  maxScale: 1
---


# W kupie raźniej
Praca w zespole

Koło Naukowe Elektroniki i Informatyki w Knurowie
28 i 29 grudnia 2020, 10:00 - 12:00

----


<img src="https://notes.kplabs.pl/uploads/upload_2d40ed1880ab977df80163cf9571c972.png" width="400px">


### Marcin Drobik 

KP Labs

<img src="https://media-exp1.licdn.com/dms/image/C5603AQHD3hDu319CkQ/profile-displayphoto-shrink_800_800/0/1600705383161?e=1614816000&v=beta&t=5GtfrXkeRsRKCSlUDn1BRqj5Z8PcyWg9ASAqEzljnPI" width="400px">

### Bartłomiej Michalski

Future Processing



---

## Krótka prezentacja procesu w projekcie Oryx

![](https://upload.wikimedia.org/wikipedia/commons/thumb/e/e8/YouTube_Diamond_Play_Button.png/1200px-YouTube_Diamond_Play_Button.png)

----

## Elementy procesu

1. Jira
2. Branch na Gitcie
3. Zmiany
4. CMake + Ninja - lokalny build
5. Commit, Push
6. CI: Build, Style Check, Testy, Dokumentacja, Testy Integracyjne
7. Code Review
8. Testy
9. Merge

---

## GIT

![](https://notes.kplabs.pl/uploads/upload_a715789c2a140d91bbecce8ee7864f07.png)



----

## GIT
### Zdecentralizowany centralny system kontroli wersji

![](https://notes.kplabs.pl/uploads/upload_87487e51d2c42574ebfeb29ccaa4fb2a.png)

https://learngitbranching.js.org/
https://git-scm.com/book/en/v2


----


## GIT - Podstawowe zasady


<img src="https://notes.kplabs.pl/uploads/upload_73f26d1f3507bada98e66691ec5ca909.png" width="40%" style="float: right">


<span style="text-align: left; float: left; width: 60%">
    <ul>
        <li class="fragment" data-fragment-index="1">One to rule them all</li>    
        <li class="fragment" data-fragment-index="2">Git vs GitHub vs GitLab vs BitBucket</li>    
        <li class="fragment" data-fragment-index="3">Nie commitujemy artefaktów projetowych</li>    
        <li class="fragment" data-fragment-index="4">Nie ma czegoś takiego jak "tymczasowa zmiana"</li>    
        <li class="fragment" data-fragment-index="5">Treść wiadomości ma mieć sens</li>
    </ul>
</span>

----

## Branch per feature 

![](https://notes.kplabs.pl/uploads/upload_937b273bf53593f4acd421cfcc12193c.png =600x900)


----


## Tylko skąd ten "feature"?


<div style="text-align: left; margin-left: 10%">
    <ul>
        <li class="fragment" data-fragment-index="1">GitHub Issues </li>
        <li class="fragment" data-fragment-index="2">Jira</li>
        <li class="fragment" data-fragment-index="3">Trello</li>
        <li class="fragment" data-fragment-index="3">...</li>
    </ul>    
</div>

----

## Jak planować i dzielić prace?

<div style="text-align: left; margin-left: 10%">
    <ul>
        <li class="fragment" data-fragment-index="1">Scrum, Kanban, Extreme Programming </li>
        <li class="fragment" data-fragment-index="2">Im bliżej tym dokładniej: np.: kamienie milowe, sprinty</li>
    </ul>
</div>

----

## Aktualizowanie brancha


<div style="text-align: left; margin-left: 10%">
    <ul>
        <li class="fragment" data-fragment-index="1">Live Fast, Die Young</li>
        <li class="fragment" data-fragment-index="2">Merge vs Rebase</li>
    </ul>
</div>


![](https://media1.tenor.com/images/662d0e55e8efc96e8c107f270aefe242/tenor.gif)<!-- .element: class="fragment" data-fragment-index="2" -->

---

## Code Review 

![](https://notes.kplabs.pl/uploads/upload_388337c66ba26f847303ddb3b3fea0ea.png)


----

## Code Review przez Pull Request

- Komentuj kod a nie autora<!-- .element: class="fragment" data-fragment-index="1" -->
- Wszyscy sie uczą<!-- .element: class="fragment" data-fragment-index="2" -->
- Bądź dokładny ale też nie rozwiązuj (od razu) problemu za autora<!-- .element: class="fragment" data-fragment-index="3" -->
- używaj precyzyjnego nazewnictwa<!-- .element: class="fragment" data-fragment-index="4" -->

----

## Code Review a standardy


 - Wspólne standardy<!-- .element: class="fragment" data-fragment-index="1" -->
     - nazewnictwo
     - idiomy
     - formatowanie
 - Gotowe standardy<!-- .element: class="fragment" data-fragment-index="2" -->
     - [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)
     - [Python: PEP 8](https://www.python.org/dev/peps/pep-0008/)
 - Formatowanie: powinno być załatwione przez narzędzia<!-- .element: class="fragment" data-fragment-index="3" -->
     - `clang-format`
     - `flake8`

---


## Utrzymywalny projekt

Snowflake Server

![](https://notes.kplabs.pl/uploads/upload_0e6dd32f82adddb613b49ffe836241fd.png =800x800)



https://martinfowler.com/bliki/SnowflakeServer.html

----

##  Minimalne wymagania do pracy w projekcie
 - Automatyzuj!<!-- .element: class="fragment" data-fragment-index="1" -->
 - Zewnętrzne biblioteki<!-- .element: class="fragment" data-fragment-index="2" -->
     - Python: `requirements.txt`
     - C++: CMake `FetchContent`, `conan` albo podobne
 - Ansible, Puppet, Docker<!-- .element: class="fragment" data-fragment-index="3" -->
 - ... albo poprostu archiwum ze wszystkim co potrzebne<!-- .element: class="fragment" data-fragment-index="4" -->
 - Dobra praktyka - nie zakładaj powłoki systemowej, systemu plików, systemu operacyjnego<!-- .element: class="fragment" data-fragment-index="5" -->

----

## It Works On My Machine™
 - Serwery ciągłej integracji które jako minimum próbują zbudować to co jest na Git<!-- .element: class="fragment" data-fragment-index="1" -->
 - Regularne pushe do repozytorium<!-- .element: class="fragment" data-fragment-index="2" -->

----

## Project CLI
 - Make, CMake, project.json, etc...<!-- .element: class="fragment" data-fragment-index="1" -->
 - "Interfejs" do projektu<!-- .element: class="fragment" data-fragment-index="2" -->
     - Uruchomienie tych samych kroków co na CI
 - Command line-first podstawą automatyzacji<!-- .element: class="fragment" data-fragment-index="3" -->
 - Vendor-lock w Embedded - czasem powoduje problemy<!-- .element: class="fragment" data-fragment-index="4" -->

----

## Onboarding

 - Jeśli pierwsza kompilacja i uruchomienie (mając niezbędny sprzęt) jest trudna to jest źle<!-- .element: class="fragment" data-fragment-index="1" -->
 - Krok po kroku opis co potrzeba, krótko i na temat<!-- .element: class="fragment" data-fragment-index="2" -->
 - Opis podstawowych zasad i koncpecji w projekcie, linki do materiałów<!-- .element: class="fragment" data-fragment-index="3" -->
 - Zestaw "ćwiczeń" do wykonania w projekcie, najbardziej typowe zadania<!-- .element: class="fragment" data-fragment-index="4" -->

----

## Dokumentacja

 - Różne rodzaje:<!-- .element: class="fragment" data-fragment-index="1" -->
     - Techniczny data sheet
     - zasady działania
     - przyjęte procedury i standardy
 - Dokumentacja na wiki vs dokumentacja razem z kodem (aka confluence vs pliki md)<!-- .element: class="fragment" data-fragment-index="2" -->

----

## Zespół projektowy, struktura organizacji
 - Różni ludzie, różne specjalizacje różne zadania<!-- .element: class="fragment" data-fragment-index="1" -->
 - Silosy wiedzy <!-- .element: class="fragment" data-fragment-index="2" -->
 - Rola lidera (technicznego)<!-- .element: class="fragment" data-fragment-index="3" -->
 - Model Spotify (z którego Spotify sie wycofał, ale może...)<!-- .element: class="fragment" data-fragment-index="4" -->

---

## Testowanie oprogramowania

----

## Po co inwestować czas w kod testów?

----

## Testy jednostkowe


- Czym jest "jednostka"
- Embedded to nie wymówka żeby ich nie robić, kod to kod<!-- .element: class="fragment" data-fragment-index="1" -->
- TDD<!-- .element: class="fragment" data-fragment-index="2" -->
    - "Test-Driven Development by Example" - Kent Beck <!-- .element: class="fragment" data-fragment-index="3" -->


![](https://notes.kplabs.pl/uploads/upload_48a61d94aa440d4a67ba8fdf3aafe5ce.png)<!-- .element: class="fragment" data-fragment-index="3" -->

----

## Jak uruchomić kod embedded na PC? 

- Wszystkie problemy oprogramowania można rozwiązać kolejną warstwą abstrakcji (z wyjątkiem problemu zbyt dużej ilości warstw abstrackji)<!-- .element: class="fragment" data-fragment-index="1" -->
- Kompilacja natywna (np.: x86-x64) vs cross-compile (np.: PC-> armv7)<!-- .element: class="fragment" data-fragment-index="2" -->
    - QEMU


----

## Testy integracyjne
- Przyjmują różne formy, ale ideą jest uruchomienie większego kawałka<!-- .element: class="fragment" data-fragment-index="1" -->
- Na sprzęcie: idzie w strone testów Hardware-in-the-Loop<!-- .element: class="fragment" data-fragment-index="2" -->
- Możliwie blisko "produkcji": Release, -O3 itd...<!-- .element: class="fragment" data-fragment-index="3" -->
- "Growing Object-Oriented Software, Guided by Tests" - Steve Freeman, Nat Pryce <!-- .element: class="fragment" data-fragment-index="4" -->

![](https://notes.kplabs.pl/uploads/upload_f4bbcbf44a003dee7a8cd9a2ce23ef39.png)<!-- .element: class="fragment" data-fragment-index="4" -->


----

## Testy a serwery CI

----

## Flaky tests
- Testy które czasem zgłaszają błedy - co chcą nam powiedzieć?

---

## Materiały
 - https://learngitbranching.js.org/
 - https://git-scm.com/book/en/v2
 - https://datasift.github.io/gitflow/IntroducingGitFlow.html
 - https://martinfowler.com/bliki/SnowflakeServer.html
 - https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
 - https://www.python.org/dev/peps/pep-0008/
 - https://cmake.org/
 - "Growing Object-Oriented Software, Guided by Tests" - Steve Freeman, Nat Pryce
 - "Test-Driven Development by Example" - Kent Beck 






