Najlepsze / złe praktyki udostępniania kodu? [Zamknięte]


9

Im więcej eksploruję Github , tym bardziej mi się podoba. Bardzo podoba mi się to, jak kodowanie staje się bardziej społeczne.

Jestem ciekawy, czy są jakieś złe praktyki, których programiści powinni unikać, dzieląc się swoim kodem. A jeśli nazywamy złe praktyki, jakie są najlepsze praktyki udostępniania kodu ?

Na przykład:

Czy złą praktyką w przypadku pojedynczego repozytorium jest posiadanie wielu skryptów / projektów o nazwie „MiscProjects” ? Gdzie to repozytorium, jak sama nazwa wskazuje, jest zbiorem różnych małych skryptów i projektów. Może to przypominać sposób, w jaki programista organizuje projekty na lokalnej pamięci, ale być może nie jest to optymalne do udostępniania kodu?

Może gdyby zrobiono dobrą README / dokumentację, byłoby lepiej? A jeśli wszystko jest dobrze udokumentowane, wszystko idzie?

Odpowiedzi:


9

Chociaż nie ma „złych praktyk” osadzonych w kamieniu, podobnie jak w przypadku innych systemów kontroli wersji, istnieją konwencje .

Twoje repozytorium Git powinno być jak najmniejsze. Jeśli pochodzisz z modułu CVS / SVN, powszechne było posiadanie strukturalnego pojedynczego repozytorium, które może składać się z wielu repozytoriów dla wielu projektów. Sposób Git polega na dzieleniu ich i oddzielnym repozytoriom Git dla każdego projektu. Powody są następujące:

  • Git jest szybszy w przypadku mniejszych transakcji repo.
  • Ze względu na swoją konstrukcję każda operacja wpływa na całe repo . Nieefektywne jest wykonywanie operacji Git nad niezbędnymi projektami, jeśli pracujesz tylko nad jednym z nich.

Dokumentacja, jak zawsze, jest koniecznością. Podczas gdy ludzie są biegli w czytaniu kodu, nikt nie chce interpretować kodu bardziej niż jest to konieczne. Użycie najwyższego poziomu README do opisania projektu i struktury repozytorium Git zawsze będzie dobrą rzeczą dla osób zaangażowanych (lub chcących się zaangażować) w projekt.

Większość projektów w GitHub jest zgodna z konwencjami. Użyj ich jako przykładów, jak ustrukturyzować przyszłe projekty.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.