---
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
----
## 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
----
## GIT
### Zdecentralizowany centralny system kontroli wersji
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
----
## 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>
<!-- .element: class="fragment" data-fragment-index="2" -->
---
## Code Review
----
## 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://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" -->
<!-- .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" -->
<!-- .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
Google Drive
Gist
Clipboard
Sign in with Wallet
