Rozdział 23 · Część VI · Wydanie pierwszej wersjiRezultaty: pełna ścieżka projektu od pomysłu do premiery
Od pomysłu po pierwsze wydanie — cała ścieżka jest raz w całości, na prawdziwym projekcie.
Pełna ścieżka projektu
Na początku tego rozdziału SafeSort był tylko pomysłem. Teraz to prawdziwe repozytorium na GitHub — Cartesian-School/safesort – z 14 zamkniętymi Issues, realnymi Pull Request, zielonymi CI weryfikacji i opublikowanymi Wydanie 0.1.0. Oto cała podróż, z tym, co pojawiło się na każdym etapie:
Co już SafeSort zrobić
| Komenda | Co robi | Zmienia pliki? |
|---|---|---|
| scan | znajduje i liczy pliki według kategorii | nie |
| plan | pokazuje plan ruchów | nie |
| duplicates | znajduje pliki z tą samą zawartością | nie |
| apply | wykonuje transfery z planu | tak, tylko na wyraźne polecenie |
| undo | cofa ostatnią wykonaną operację | tak, tylko odzyskiwanie |
co dalej
Wersja 0.1.0 celowo nie obejmuje wszystkiego, co możliwe: pierwsza część tego rozdziału to Określił granice. Dalszy rozwój SafeSort wykracza poza zakres tego rozdziału, ale niektóre Instrukcje naturalnie kontynuują to, co już zostało zrobione: publikacja pakietu w PyPI, klasyfikacja nie tylko przez rozszerzenie, ale także przy dokładnym sprawdzeniu zawartości pliku, interfejs dla Ustawienia inne niż ręczna edycja pliku TOML-.
Aneks do tego rozdziału powtarza tę samą ścieżkę, od problemu do Pull Request, Sześć razy, już samodzielnie, przy sześciu małych projektach: Dodatkowa praktyka: sześć mini-projektów dla GitHub.
Czego nauczyliśmy się w tym rozdziale
- Przed napisaniem kodu wymagania projektu opisują nie tylko to, co program robi, ale także to, czego świadomie nie robi.
- Podział na read-only planowanie i dwie jawne operacje, bezpośrednią apply i odwrotną undo, chroni przed przypadkowymi zmianami plików użytkownika.
- Wyszukiwanie duplikatów wykonuje kosztowną operację — haszowanie — tylko wtedy, gdy faktycznie może zmienić odpowiedź: po wybraniu plików według rozmiaru.
- Testy automatyczne działają tylko na katalogach tymczasowych – żaden test nie powinien dotykać rzeczywistych plików użytkownika.
- Git i GitHub — część developmentu od samego początku, a nie końcowy krok: Issue formułuje zadanie, gałąź izoluje pracę, Pull Request otwiera ją do weryfikacji, GitHub Actions sprawdza testy automatycznie.