Chcę poprawić swoje umiejętności programistyczne, studiując znane projekty open source, ale łatwo się zgubić, po prostu wskakując do ich kodu źródłowego.
Postanowiłem więc przeczytać ich dokumentację dotyczącą ich projektu lub architektury (np. Diagramów UML), aby najpierw uzyskać ogólne wyobrażenie o organizacji ich kodu. Ku mojemu zaskoczeniu nie mogę jednak znaleźć żadnej dokumentacji architektonicznej dla dużych projektów open source, takich jak Hibernate, Spring, ASP.NET MVC, Rails itp.
Zacząłem się zastanawiać: w jaki sposób projekt typu open source może odnieść sukces, jeśli nowi twórcy nie mają dokumentacji architektonicznej / projektowej do przeczytania, lub jeśli kierownik projektu właśnie otworzył kod źródłowy, ale zamknął dokumentację?
źródło
Odpowiedzi:
Zakładamy niezmiennie, że wiesz, co robisz, i masz dość intymne zrozumienie tego, co zamierzasz (i oczekujesz) zobaczyć.
Na przykład, jeśli spojrzysz na kod PHP frameworka Symfony, powinieneś już wiedzieć o wstrzykiwaniu zależności, zdarzeniach, wzorcu model / widok / kontroler i tak dalej.
Podobnie, jeśli zagłębisz się w kod C jądra linuksa, założymy, że będziesz realistycznie kompetentny w zakresie modułowości, sygnałów, procesów, wątków i co nie. Oczekuje się także, że będziesz miał talent do jedzenia w systemie szesnastkowym przez cały dzień i do kopania rdzeni za pomocą ogromnej łopaty.
Opiekunowie nie będą mieli problemów z dokumentowaniem architektury, ponieważ jest to rzeczowa kwestia. Czasami znajdziesz zarys tego, co leży w drzewie źródłowym. Częściej jednak sposób uporządkowania drzewa źródłowego sprawia, że wszystko jest zrozumiałe.
Krótko mówiąc, jeśli brakuje ci umiejętności, których opiekunowie oczekują od ciebie, zanim zajrzysz do ich kodu, prawdopodobnie przekopujesz rzeczy, które znacznie przekraczają twoją ocenę płacową. Najpierw zapoznaj się z koncepcjami - Co to jest model MVC? Co to jest wstrzyknięcie zależności? Itd. Następnie zanurkuj.
źródło
Najbardziej udane projekty open source odniosły sukces, ponieważ przede wszystkim program był imponujący lub zrobił coś, czego żaden inny program w tym czasie nie był w stanie zrobić. Nie musi to oznaczać, że źródło jest dobrze udokumentowane, ponieważ programiści, którzy rozpoczęli projekt od początku, znają kod wystarczająco dobrze, aby go nie potrzebować. To niefortunna rzeczywistość, że projekty open source nie muszą być dobrze udokumentowane. Musi to być dobry program lub mierny program, ale dobrze udokumentowany, aby programiści mogli się nim zainteresować.
źródło
Ponieważ programiści Open Source są zwykle utalentowani i wybierają również projekty w swojej dziedzinie wiedzy, mają już w swoich głowach „dokumentację”. Przy niewielkiej przesadzie dokładna dokumentacja jest potrzebna tylko w przypadku braku któregoś z nich: o)
Szczerze mówiąc, tak naprawdę nie czytam „dokumentacji” w obliczu nieznanej bazy kodu. Szybkie wprowadzenie, może kilka szkiców koncepcyjnych i od razu do kodu! Eksperymentuj, wypróbuj małe zmiany. Działa idealnie dla dobrze zaprojektowanego kodu. Jeśli mam do czynienia z okropnym bałaganem, najlepszym sposobem na ich nauczenie jest stopniowe refaktoryzacja w celu poprawy przejrzystości (najlepiej przy pomocy testów jednostkowych).
Dodatkowym powodem mogą być zwykłe organiczne korzenie tych projektów. Architektura jest więc raczej ewolucją wizji w umysłach programistów niż stwierdzoną „udokumentowaną” istotą.
źródło
Powód, dla którego takie dokumenty często nie istnieją, jest dość prosty: programiści lubią programować, a nie pisać dokumentację. Zwłaszcza w przypadku projektów typu open source, które programiści często uczestniczą w czasie wolnym / wolnym.
Zasadniczo pisanie dokumentacji nie jest zabawne. A jeśli nie dostają za to zapłaty, kto chce spędzać wolny czas na robieniu czegoś, co nie jest zabawne?
źródło