Pomysły na projekty programistyczne, które uczą czytać kod

Pomysły na projekty programistyczne, które uczą czytać prawdziwy kod

Większość list pomysłów na projekty programistyczne podaje Wam aplikację do zarządzania zadaniami i życzą powodzenia. Projekty, które rzeczywiście czynią was zatrudnialnymi, to takie, w których czytacie kod, który nie został napisany przez Was, znajdujecie właściwy plik w ciągu paru minut i zmieniacie go bez rozbijania buildu. To umiejętność, którą sprawdzają rekruterzy, a samodzielny projekt ze sprawy nie ją doskonali.

Na tej stronie znajdziecie przegląd pomysłów na projekty programistyczne, które rzeczywiście rozwijają umiejętności wymagane w pracy zawodowej. Nie są to kolejne do-do aplikacje czy przesłodzeni tutoriale. To projekty skonstruowane z myślą o tym, czego naprawdę potrzebuje inżynier: umiejętności czytania, zrozumienia i modyfikacji istniejącego kodu.

Poniżej znajdują się pomysły na projekty programistyczne posortowane według umiejętności, które rozwijają, plus sposób na wybranie jednego projektu, abyście go rzeczywiście ukończyli zamiast porzucić go w trzecim tygodniu.

Dlaczego większość pomysłów na projekty programistyczne załamuje się w trzecim tygodniu?

Zaczynamy z pustym folderem. Pierwsze 40 linijek kodu czuje się wspaniale. Następnie aplikacja potrzebuje autentykacji, schematu bazy danych i miejsca do wdrażania, a zdaję sobie sprawę, że spędzam sobotę czytając dokumentację zamiast budować rzecz, którą sobie wyobraziłem.

Regularnie pojawiają się trzy scenariusze niepowodzenia:

• Zakres to produkt, nie projekt. „Zbuduj klon Netfliksa" to firma. „Zbuduj funkcję, która wybiera następny odcinek na podstawie historii oglądania" to projekt.

• Nie ma czytającego kodu. Nikt nie przegląda waszego kodu, więc nic nie zmusza Was do uczynienia go czytelnym.

• Projekt nigdy nie dotyczy istniejącego kodu. Pierwszy dzień w pracy to 95 procent czytania. Wasz samodzielny projekt to 95 procent pisania. Ta asymetria to powód, dlaczego juniory z solidnym portfolio wciąż się blokują w pierwszym sprincie.

Wybór narzędzia ma mniejsze znaczenie, niż się sądzi. Pomiń weekend poświęcony porównywaniu frameworków i wybierz ten, w którym uruchomisz „hello world" w ciągu 20 minut.

Które pomysły na projekty programistyczne są warte Waszego czasu jako początkujący?

Wybierajcie projekty z jasnym stanem końcowym, który możecie zademonstrować w jednym zdaniu. Oto pięć, które skalują się dobrze od studenta pierwszego roku do osoby zmieniającej karierę:

1. CLI tracker wydatków z eksportem CSV. Nauczycie się parsowania argumentów, operacji plikowych i jak strukturyzować program z więcej niż jednym modułem. Wyślijcie go z README-m, który nieznajomy by mógł śledzić.

2. Checker linków do folderu dokumentacji. Przejdźcie przez katalog plików markdown, wyodrębnijcie adresy URL, zgłoście martwe linki. Mały, przydatny i uczy recursion oraz kodów statusu HTTP.

3. Osobiste API z jednym rzeczywistym źródłem danych. Ściągnijcie swoje dane (treningi, książki, commity) do SQLite i udostępnijcie przez trzy endpointy. To tu po raz pierwszy spotkacie paginację i obsługę błędów.

4. Narzędzie do porównywania tekstu. Porównajcie dwa pliki i wydrukujcie zmiany. Wygląda trywialne, dopóki nie spróbujesz radzić sobie z przesunętymi liniami, gdzie dowiadujecie się, dlaczego algorytm Myersa stał się standardem w Gicie.

5. Mały bot do narzędzia czatu, którego już używacie. Przypomnienia, podsumowania standu, powiadomienia o statusie buildu. Rzeczywisty użytkownik (Wy) daje natychmiastową informację zwrotną.

Omijajcie, chyba że macie konkretny powód: aplikacje pogodowe (każdy tutorial tu się kończy, więc Wasz repo znika w kupie), listy zadań bez trwałości i wszelkie „chatboty AI", które to tylko cienka otoczka wokół wywołania API bez Waszych danych.

Które projekty uczą, jak działają rzeczywiste systemy?

Gdy już potraficie skończyć małe rzeczy, zbudujcie miniaturową wersję czegoś, czego używacie codziennie. Chodzi nie o jego zastąpienie. Chodzi o dowiedzenie się, dlaczego rzeczywisty jest zbudowany w taki sposób.

CodeCrafters utrzymuje listę 73 projektów do zbudowania samodzielnie, a te, które najbardziej opłacają się dla pracujących inżynierów, mają wspólną cechę: publiczną specyfikację, którą możecie sprawdzić. Kilka wartych Waszego weekendu:

• Wasz własny Git. Init, commit, log i branching z użyciem storage adresowanego zawartością. Write Yourself a Git prowadzi przez wnętrze. Po tym konflikty merge przestają terać jak pogoda.

• Magazyn klucz-wartość. Papier Bitcask jest krótki na tyle, aby przeczytać w jednej sesji, a jego projektowanie (dziennik append-only plus indeks w pamięci) pokazuje Wam większość tego, czym system storage handluje.

• Serwer HTTP z surowych gniazd. Parsuj linię żądania, serwuj plik statyczny, zwróć 404. Trzysta linii i nigdy więcej nie traktować webowego frameworku jak czarną skrzynię.

• Mały interpreter. Tokenizer, parser, evaluator. To pojedynczy projekt, który zmienia sposób, w jaki czytacie każdy inny kawałek kodu.

Każdy z nich zajmuje dwa do czterech weekendów, nie dwie do czterech godzin. Przebadajcie odpowiednio i napiszcie na początek, co znaczy „gotowe".

Dlaczego wkład do istniejącego repozytorium to najlepszy pomysł na projekt, który nikt nie wymienia?

Ponieważ to ten projekt, który odpowiada pracy. Otworzenie repozytorium z 200 plikami i bez mapy to rzeczywiste codzienne doświadczenie pracownika inżynierskiego, a prawie żaden artykuł o „pomysłach na projekty" Wasa tam nie wysyła.

Mechanika jest prostsza, niż się wydaje. Open Source Guide stwierdza, że każdy projekt GitHub ma stronę /contribute (dodajcie ją na koniec adresu URL repozytorium), która wymienia zagadnienia przyjazne dla początkujących, i wskazuje, że 28 procent przypadkowych wkładów to dokumentacja: poprawki błędów, reformatowanie, tłumaczenia. Zacznijcie tutaj. Poprawka dokumentacji uczy Was cyklu fork, branch, PR z prawie żadnym ryzykiem.

Następnie przejdźcie do małego buga. Oto procedura, która działa:

1. Wybierz projekt, którego już używasz, abyś wiedział, jak wygląda prawidłowe zachowanie.

2. Filtruj problemy po „good first issue" i przeczytaj pięć, zanim wybierzesz jeden.

3. Odtwórz błąd lokalnie, zanim dotkniesz jakiegokolwiek kodu.

4. Znajdź punkt wejścia. To trudna część i tu większość ludzi się poddaje.

5. Zrób najmniejszą zmianę, która to naprawia, dodaj test i otwórz PR wcześnie jako szkic.

Krok 4 to ten, o którym nikt Wam nie ostrzega. Będziecie szukać ciągu błędu, wylądujcie w pliku, śledzicie wywołanie funkcji w trzech innych plików i tracicie wątek. Robiliście to wcześniej: grep, Ctrl+F, blame, następnie zapytajcie kogoś. Rzeczywisty problem to nie inteligencja. To czas czytania.

Jak narzędzie AI może skrócić fazę czytania bez robienia pracy za Was?

Tu narzędzia świadome bazy kodu zarabiają na swoje utrzymanie. Pytanie, które naprawdę zadajecie, to „gdzie X jest podłączone w tym repo", a narzędzie, które zaindeksowało kod, może na to odpowiedzieć ze ścieżkami plików w sekundy zamiast 40 minut grep.

Reguła, która Was uczy: poproś o mapę, następnie sam przeczytaj kod. „Które pliki obsługują wygaszanie sesji i co je wymienia?" to dobre pytanie. „Napraw mi ten bug" to jak skończyć otworzeniem PR, którego nie możecie bronić w przeglądzie. Open Source Guide mówi to bezpośrednio: osoby wspierające pozostają odpowiedzialne za zgłaszane zmiany, a praca wspierana przez AI musi być weryfikowana względem konwencji projektu.

Szybkie porównanie tego, co każda opcja jest dobra dla tego przypadku:

Cursor jest mocny, gdy repo jest już otwarte w Waszym edytorze i chcecie wbudowane odpowiedzi o pliku przed sobą. Kiedy odpowiedź przechodzi wiele repozytoriów, które są powszechne gdy wspieracie projekt z oddzielonymi pakietami.

Chat GitHub Copilot siedzi najbliżej przepływu pracy pull request, co pomaga, gdy przeglądacie diff kogoś innego. Jego odpowiedzi opierają się na plikach, które masz otwarte, więc najpierw musisz przyciągnąć właściwe w kontekst.

Aider pracuje z terminala i bezpośrednio edytuje pliki przez git commits. To doskonałe dla uczących się, którzy chcą czystą historię każdej zmiany i ryzykowne, jeśli akceptujesz edycje, których nie czytałeś.

Continue.dev jest otwarte i pozwala wskazać model z Waszego wyboru, więc kontrolujesz koszt i gdzie idzie Wasz kod. Kompromis to czas konfiguracji: spodziewajcie się spędzić wieczór na konfiguracji.

Żaden z nich nie zastępuje kroku 4 powyższej procedury. Zmniejszają ją z popołudnia na przerwę na kawę i wciąż musicie rozumieć, co znaleźliście.

Jak powinien wyglądać projekt, gdy chcecie złapać pracę?

Rekruterzy nie klonują Waszego repo. Spędzają na tym około dwóch minut. To, co sprawdzają, jest konkretne: czy README mówi, co to robi i jak to uruchomić, czy jest folder z testami, czy commity są czytelne i czy możecie wyjaśnić jedną decyzję projektową na głos.

Budujcie dla tego czytającego:

• Napiszcie README pierwsze. Jeśli nie możecie opisać projektu w czterech zdaniach, zakres jest błędny.

• Trzymajcie commity małe i nazwane podle zamiaru. „Handle empty CSV rows" lepsze niż „fixes".

• Dodajcie jeden test, który by złapał rzeczywisty bug, w który wpadliście. Jeden uczciwy test lepszy niż odznaka pokrycia.

• Zanotujcie jedną rzecz, która nie zadziałała. Krótka sekcja „co próbowałem i odrzuciłem" sygnalizuje więcej dojrzałości niż bez skazy historia.

Zmergowany pull request w znanym projekcie open source często przeważa trzy samodzielne aplikacje, ponieważ dowodzi, że potraficie pracować w czyjchś ograniczeniach. Jeśli zarządzacie zespołami, ta sama logika stosuje się odwrotnie: junior, który wysłał PR do zewnętrznego repo, rośnie szybciej, ponieważ już wykonali krok „znajdź punkt wejścia" pod presją.

Jak wybrać jeden projekt i go ukończyć?

Zamiast uczucia użyjcie filtra. Oceńcie każdy pomysł od 1 do 3 na cztery pytania:

• Czy możecie to zademonstrować w 60 sekund? 3 oznacza jedno polecenie i jeden widoczny wynik.

• Czy używa kodu, którego nie napisaliście? 3 oznacza bibliotekę, specyfikację lub istniejące repo.

• Będziecie to używać sami? 3 oznacza powód do otwarcia go w przyszłym tygodniu.

• Czy możecie skończyć w cztery weekendy? 3 oznacza, że możecie nazwać ostatnie zadanie dzisiaj.

Cokolwiek poniżej 9 wraca na półkę. Następnie ustaw blok kalendarza, nie poziom motywacji. Dwie stałe sesje tygodniowo przez cztery tygodnie biją jeden heroiczny weekend, po którym cisza.

Praktyczne wskazówki do dalszej nauki

Podczas pracy nad wybranym projektem zwróćcie uwagę na kilka rzeczy. Po pierwsze, dokumentacja to nie zbyt wiele, to integralnie ogranie projektu. Kiedy napiszecie README, wyobraźcie sobie, że czyta je osoba, która nigdy nie słyszała o Waszym projekcie. Czy mogłaby go uruchomić w ciągu 5 minut? Czy wie, co robi kod? Czy rozumie, jak wdrożyć zmianę?

Po drugie, commity mają znaczenie. Nie tylko dla Was dzisiaj, ale dla każdego, kto przegląda Waszą pracę. Każdy commit powinien być atom zmian: jedna logiczna zmiana, niezależna, którą można opisać w jednym zdaniu. Historia commitów to ścieżka myśli, a dobra ścieżka jest łatwa do śledzenia.

Po trzecie, testy nie są dodatkiem. Jeden uczciwy test, który przechwyci rzeczywisty błąd, ma więcej wartości niż sto testów, które tylko sprawdzają, czy kod robi to, co robi. Piszcie testy dla przypadków brzegowych, dla rzeczy, które Wasz nowy inżynier mógłby zepsuć.

Podsumowanie: od teorii do praktyki

Przestańcie zbierać pomysły na Pinterest. Wybierz jeden projekt, który buduje, i jeden, który czyta. Zbudujcie mały interpreter lub CLI, aby udowodnić, że potraficie pisać, coś, co macie na githubie, coś z testami i README. Następnie otwórzcie PR do dokumentacji repozytorium, które już używacie, aby udowodnić, że potraficie czytać i pracować w ograniczeniach innego zespołu.

Razem te dwa projekty pokrywają obie połowy pracy: pisanie i czytanie. A druga połowa, czytanie, to ta, którą prawie nikt nie praktykuje na samym projekcie domowym. To Wasz efekt konkurencyjny.