Czy źle jest dołączyć do projektów open source jako amator?

Przez około sześć miesięcy myślałem, że powinienem dołączyć do projektu iPhone'a lub iPada o otwartym kodzie źródłowym, aby doskonalić swoje umiejętności w Objective-C, ale za każdym razem, gdy to robię, widzę tysiące linii kodu w dużych projektach, które ja w końcu przekonuję się, że nigdy nie zrozumiem. Zawsze myślę, że moje zobowiązania byłyby po prostu kłopotliwe dla administratorów projektu i starszych współpracowników, więc zawsze wycofuję się w ostatniej chwili.

Moje pytanie zasadniczo brzmi: czy jest to problem, gdy doświadczony pośrednik programista dołącza do projektu typu open source?

Nie, nie jest.

Jeśli baza kodu projektów, na które patrzysz, jest zbyt zniechęcająca, zastanów się:

• Wybór (nawet) mniejszego projektu do pracy.
• Wybierz mniejsze zadanie w ramach projektu:
  • Napisz przykład / tutorial / demo na coś
  • Zaktualizuj i napraw dokumentację (wszystkie projekty, system operacyjny lub nie, wymagają lepszych dokumentów)
  • Napraw wiele błędów o niskim priorytecie, ale łatwych do naprawienia (duża ekspozycja na kod, deweloperzy są zwykle zadowoleni, niskie ryzyko)
• Istnieją sposoby na wniesienie wkładu bez zatwierdzania dostępu do podstawowego źródła, takie jak:
  • Przesyłanie poprawek, które można komentować.
  • Rozwidlanie i składanie wniosków o pociągnięcie (patrz wyżej)
  • Rozwidlaj się i pracuj sam, żeby zobaczyć, dokąd cię zaprowadzi. Jeśli jesteś szczęśliwy, poproś deweloperów, aby spojrzeli na wszystko, co zrobiłeś, aby zobaczyć, czy ma to sens.

Aby przezwyciężyć swój „strach” przed nieprzyjmowaniem zobowiązań, najpierw wybierz bezpieczne punkty. Pozwoli to zarówno tobie, jak i zespołowi deweloperów zyskać zaufanie do twojego związku i nauczyć się nawzajem myślenia. W miarę doskonalenia się (zarówno pod względem umiejętności, doświadczenia, jakości kodu, jak i zrozumienia zespołu projektu systemu operacyjnego i jego dynamiki) będziesz w stanie sprostać większym zadaniom, jednocześnie wprowadzając mniej problemów.

Pomaga również w ustaleniu odpowiednich punktów początkowych i sprawdzeniu, co zespół może dla Ciebie uznać za odpowiedni.

Jako przykład, przez lata włączyłem się trochę w Buildbot. Zacząłem naprawiać kilka drobnych problemów, a potem podniosłem jakość kroków źródłowych Mercurial, naprawiając niektóre rażące błędy. Na koniec przepisałem większość stron i zamieniłem wklejanie kodu HTML na rozwiązanie do generowania HTML oparte na szablonie. Ten ostatni to kilkaset zobowiązań w ciągu kilku miesięcy ciężkiej pracy.

Zrobiłem też trochę pracy z Mercurialem, ale ci faceci są bardziej wybredni, a technologia bardziej skomplikowana, więc nie dostałem jeszcze żadnych poprawek do rdzenia. Zrobiłem kilka raportów o błędach i napisałem kilka małych rozszerzeń, ale w tej chwili nie dostałem nic większego.

Mam nadzieję, że to pomoże.

Wskocz. Monitoruj przez chwilę listy rozwoju i przedstaw się, kiedy czujesz się komfortowo. W wielu projektach jest kilka łatwiejszych zadań w zakresie naprawy błędów lub dokumentacji, które regularni chętnie Ci przedstawią. Większość projektów jest całkiem przyjazna dla nowych rąk i doprowadzą cię na tyle szybko, abyś mógł stać się prawdziwym atutem Projektu.

Po chwili zapoznasz się ze strukturą i najważniejszymi częściami podstawy kodu. Nauka rozumienia takiego kodu jest naprawdę ważną częścią programowania, a open source to świetny sposób na naukę go.

Idź po to. Jest mnóstwo początkujących, którzy robią to samo. Kierownik projektu może pomóc ci znaleźć rzeczy do zrobienia, które nie są poza twoją ligą. Stopniowo wyrastasz na resztę.

Aha, a to, że nie rozumiesz kodu, nie oznacza, że ​​jest dobry . Widziałem jakiś naprawdę okropny kod. Niektóre z nich są trudne do zrozumienia, ponieważ są źle napisane i złożone są o wiele bardziej skomplikowane niż powinny.