Rozdział 23 · Część II · Planowanie SafeSort na GitHubJak zaplanować Project: najlepsze praktyki
Project łatwe do stworzenia w sekundę i równie łatwe do zagracenia tuzinem niewykorzystanych pól — kilka decyzji należy podjąć wcześniej.
Stworzenie Project to kwestia sekund; błąd, który popełnia niemal każdy początkujący — natychmiast dodaj tuzin pól i trzy widoki „na przyszłość”
Ustalić zakres z wyprzedzeniem
Project można powiązać z jednym repozytorium lub połączyć w nim kilka.
Dla SafeSort odpowiedź jest prosta — jeden Project na jedno repozytorium, ponieważ cała praca
tego rozdziału odbywa się w Cartesian-School/safesort nie
Nie ma sensu pobierać zadań z innych repozytoriów kursów do jednego lista.
Mniej dziedzin jest lepszych
| Zamiast | Lepiej |
|---|---|
| pole „na wszelki wypadek” | pole, które odpowiada na konkretne pytanie (kto jest ważniejszy, która część kodu) |
| wolny tekst tam, gdzie opcji naprawdę jest niewiele | Single select z wcześniej znaną listą wartości |
| nowy widok dla każdego pomysłu „a co jeśli się przyda” | jeden lub dwa przedstawienia, które naprawdę otwierają się codziennie |
Pola i reprezentacje można zmieniać później
Nic z rozwiązanych w tym kroku nie jest wyryte w kamieniu: GitHub pozwala dodać, zmienić nazwę lub usunąć pole i widok w dowolnym momencie, nie tracąc już zebranych danych. Błąd nowicjusza — nie „wybrać niewłaściwe pole”, lecz rozwiązać wszystko naraz i nigdy nie przeglądać ponownie.
Krótko
- Zanim utworzysz Project, powinieneś zdecydować, czy jest to jedno repozytorium, czy wiele repozytoriów.
- Mniej pól i widoków, z których każde jest faktycznie używane, lepiej tuzin „na przyszłość”
- Status jest polem wbudowanym; powinieneś dodawać własne pola tylko wtedy, gdy Status nie odpowiada na żądane pytanie.