Projekty Python do portfolio — od skryptu do aplikacji w Django
Sześć projektów Python do portfolio od najprostszego: co musi zawierać każdy (README, testy, API, baza, deploy, bezpieczeństwo), słaby i mocny dowód oraz lista kontrolna.
Zespół LearnIT

Krótka odpowiedź
Projekt Python do portfolio przekonuje wtedy, gdy ktoś inny może go uruchomić, zrozumieć i rozwijać. Zacznij od prostego narzędzia w terminalu i przetwarzania pliku CSV, potem zbuduj klienta API z bazą danych, REST API w FastAPI lub Django REST Framework i aplikację w Django. Każdy projekt powinien mieć README z instrukcją uruchomienia, testy, konfigurację bez sekretów w repozytorium i historię commitów. Dwa, trzy dopracowane projekty mówią więcej niż wiele porzuconych.
Spis treści · 4
Projekt w portfolio Python Developera ma przekonać, że potrafisz napisać kod, który ktoś inny uruchomi, zrozumie i będzie mógł rozwijać. Dlatego liczy się nie temat, tylko to, co otacza kod: README, testy, sposób pracy z danymi, wdrożenie i podstawy bezpieczeństwa. Poniżej sześć projektów ułożonych od najprostszego — przy każdym to, co musi się w nim znaleźć.
Ogólne zasady porządnego repozytorium i profilu opisaliśmy w tekście portfolio na GitHubie. Tutaj skupiamy się na tym, czego oczekuje się od projektów backendowych w Pythonie i Django.
Sześć projektów od najprostszego
1. Narzędzie w terminalu do porządkowania plików
Program sortuje pliki w katalogu według rozszerzenia i daty, a na życzenie pokazuje, co zamierza zrobić, zanim cokolwiek przeniesie.
- README: co robi program, jak go zainstalować i przykład wywołania,
- testy: pytest dla funkcji, które decydują, gdzie trafi plik,
- bezpieczeństwo: program nie zapisuje niczego poza wskazanym katalogiem.
2. Przetwarzanie pliku CSV z raportem
Skrypt wczytuje dane, filtruje je i zapisuje podsumowanie do nowego pliku.
- README: przykładowy plik wejściowy i wynik, który powinien powstać,
- testy: także dla złych danych — pustego pliku, brakującej kolumny, tekstu zamiast liczby,
- bezpieczeństwo: w repozytorium nie ma prawdziwych danych osobowych, tylko przykładowe.
3. Klient publicznego API z pamięcią w bazie
Program pobiera dane z publicznego API i zapisuje je w SQLite, żeby nie pytać serwera o to samo dwa razy.
- API: obsługa błędów sieci, limitu czasu i ponownych prób,
- baza danych: SQLite z prostym schematem opisanym w README,
- testy: odpowiedzi API podmienione w testach, żeby testy nie zależały od internetu,
- bezpieczeństwo: klucz do API w zmiennej środowiskowej, nigdy w kodzie.
4. REST API w FastAPI albo Django REST Framework
Interfejs do zarządzania jednym zasobem, np. listą zadań, z rejestracją i logowaniem użytkownika.
- API: pełny CRUD, dokumentacja endpointów i sensowne kody odpowiedzi,
- baza danych: PostgreSQL i migracje,
- testy: testy endpointów, również dla błędnych danych i braku uprawnień,
- deploy: docker-compose, które uruchamia API z bazą jednym poleceniem,
- bezpieczeństwo: walidacja danych wejściowych i uwierzytelnianie tokenem.
5. Aplikacja webowa w Django
Aplikacja z kontami użytkowników, formularzami i uprawnieniami, np. prosty system rezerwacji.
- baza danych: modele z relacjami i migracje,
- testy: testy modeli, widoków i uprawnień — kto co może zobaczyć i zmienić,
- deploy: aplikacja uruchomiona poza Twoim komputerem albo gotowa do uruchomienia w kontenerze,
- bezpieczeństwo: ustawienia produkcyjne oddzielone od deweloperskich, wyłączony tryb debug, sekrety poza repozytorium.
6. Aplikacja z zadaniami w tle i automatycznym wdrożeniem
Projekt 4 lub 5 rozbudowany o zadania wykonywane w tle, np. wysyłkę powiadomień, oraz pipeline CI/CD.
- API i baza danych: jak w projekcie 4 lub 5, plus kolejka zadań (np. Celery z Redisem),
- testy: uruchamiane automatycznie w pipeline przy każdej zmianie,
- deploy: nowa wersja trafia na serwer po zmianie w głównej gałęzi,
- bezpieczeństwo: ograniczenie liczby zapytań i logi, z których da się odtworzyć, co się stało.
Słaby i mocny dowód umiejętności
Ten sam projekt może przekonywać albo nie — zależnie od tego, jak jest pokazany.
| Słaby dowód | Mocny dowód |
|---|---|
| README z samym tytułem | README: problem, uruchomienie jednym poleceniem, przykładowe żądanie i odpowiedź |
| brak testów | testy uruchamiane automatycznie przy każdej zmianie |
| hasło w pliku ustawień | konfiguracja przez zmienne środowiskowe i plik z przykładowymi wartościami |
| jeden commit „final” | historia commitów pokazująca kolejne kroki |
| zrzut ekranu działającej aplikacji | adres wdrożonej aplikacji albo docker-compose, które ją uruchamia |
| kod skopiowany z tutoriala | własny pomysł na rozszerzenie i opis decyzji w README |
Lista kontrolna osoby, która sprawdza projekt
- projekt uruchamia się według README w kilka minut,
- testy przechodzą lokalnie i w pipeline,
- w repozytorium ani w historii nie ma sekretów,
- dane wejściowe są walidowane, a błędy zwracają zrozumiałe komunikaty,
- struktura projektu jest czytelna — widać, gdzie jest logika, a gdzie widoki,
- autor potrafi wyjaśnić każdą decyzję na rozmowie.
Od czego zacząć?
Jeśli dopiero uczysz się podstaw, zacznij od projektów 1 i 2 — kolejność nauki opisaliśmy w planie nauki Pythona od zera. Przed projektami 4 i 5 porównaj frameworki w tekście Django, Flask czy FastAPI. Nie musisz zrobić wszystkich sześciu: dwa, trzy dopracowane projekty mówią więcej niż sześć porzuconych.
Chcesz budować takie projekty z feedbackiem do kodu? Kurs Python Developer prowadzi od podstaw języka przez bazy danych i Django po API i wdrożenie, a projekty trafiają do Twojego portfolio.
Chcesz nauczyć się programowania w Pythonie?
Przejdź od teorii do praktyki pod okiem mentorów. Sprawdź kurs Python Developer w LearnIT.
Zobacz kurs Python Developer


