Rozdział 24 · Co dalej? Roadmap Python- deweloperPortfolio dewelopera
Znaczące projekty z dowodami na rozwiązania, walidację i architekturę, zamiast powtarzających się materiałów szkoleniowych.
Portfolio pokazuje rozwiązania
Repozytorium jest przydatne, gdy inny programista rozumie zadanie, uruchamia projekt, Sprawdź podstawowe właściwości i zobacz, dlaczego architektura wygląda tak, a nie inaczej. Liczba projektów nie rekompensuje braku ukończenia i wyjaśnień.
Powtórzenia edukacyjne i portfolio inżynierskie
| Powtórki z treningów | Portfolio inżynierskie |
|---|---|
| Powtarza wcześniej ustalone kroki i znany wynik. | Zaczyna się od samodzielnie zdefiniowanego problemu, użytkownika i granic. |
| Pokazuje tylko końcowy kod lub zrzut ekranu. | Zapewnia powtarzalną instalację, demo, testy oraz weryfikowalną wersję. |
| Ukrywa bieg zmian i powody podejmowania decyzji. | Zachowuje historię Git, Issues, małe PR i opis kompromisów architektonicznych. |
| Trudno odróżnić rozwiązania autora od instrukcji. | README i documentation wyjaśniają wkład, ograniczenia i przyszłe prace autora. |
Drabina dojrzałości projektu
| Poziom | Co widać w projekcie | Weryfikowalny wynik |
|---|---|---|
| Level 1 | Skrypt rozwiązuje jedno zadanie lokalnie. | Autor może odtworzyć wynik. |
| Level 2 | Istnieją funkcje, struktura katalogów README oraz obsługa spodziewanych błędów. | Nowy użytkownik rozpoczyna projekt zgodnie z instrukcjami. |
| Level 3 | Krytyczna logika jest omawiana przez testy; lint i CI powtarzają lokalną weryfikację. | Zmiana przechodzi automatyczną kontrolę jakości. |
| Level 4 | Są jasne interfejsy, konfiguracja, obserwowalność, budowa pakietów i notatki do wydania. | Artefakt umieszcza się w czystym środowisku i diagnozuje awarię. |
| Level 5 | Opisane są kompromisy, ograniczenia, model zagrożenia lub awarii oraz scenariusz operacyjny. | Rozwiązanie można omówić jako system inżynierski. |
Ta drabinka opisuje dojrzałość dema, a nie rangę dewelopera. Nie wszyscy Projekt potrzebuje Level 5. Jeden głęboki projekt może to osiągnąć, a dwa mniejsze to pokażą różnorodnych zadań.
Jak wybierać projekty
Uniwersalna liczba projektów, a tym bardziej gwarancja zatrudnienia, nie istnieje. Wybierz minimalny zestaw, który pokazuje ogólny fundament, wybraną specjalizację i jakość procesu inżynieryjnego. Skład może być taki:
- jeden mały CLI lub biblioteka z czystym API i pakietem;
- jeden główny projekt specjalizacyjny z prawdziwą granicą: DB, GUI, data pipeline lub game loop;
- jednym z projektów, gdzie szczególnie widoczne są testy, CI i diagnostyka;
- w razie potrzeby jedna komenda lub open-source zakładka;
- opcjonalny eksperyment, pokazujący zainteresowanie badawcze.
Co powinno być w każdym repozytorium
Co czytelnik powinien znaleźć
- README z określeniem problemu, użytkownika, granic rozwiązania i statusu projektu.
- Zrzuty ekranu lub krótka demonstracja potwierdzająca podstawowy scenariusz bez podmieniania opisu technicznego.
- Powtarzalna instalacja: wersje, zależności, instalacja, uruchamianie, testy i komendy budowania.
- Schemat architektury, interfejsy, kluczowe kompromisy i znane ograniczenia.
- Krytyczne testy logiczne i CI powtarzające lokalne kontrole jakości.
- Historia Git, Issues i drobne zmiany pokazujące kierunek rozwiązań inżynieryjnych.
- Wersja wydania lub instalowalny artefakt z notatkami do wydania.
- LICENSE i dokumentację, wystarczające do zadeklarowanego sposobu użycia.
Nie komplikuj projektu przez listę technologii
Nie dodawaj Kubernetes, message brokera, mikroserwisów ani sieci neuronowych dla samej listy technologie. Dodaj komponent, gdy możesz sformułować wymagania, alternatywy, Koszt i sposób weryfikacji. Historia niewielkich, znaczących PR wpływa na rozwój projektu Wyraźniej niż jeden gigantyczny commit.