Thực tiễn tốt nhất / xấu để chia sẻ mã? [đóng cửa]


9

Càng khám phá Github , tôi càng thích nó. Tôi thực sự thích cách mã hóa đang trở nên xã hội hơn.

Tôi tò mò liệu có bất kỳ thực hành xấu nào mà các lập trình viên nên tránh trong việc chia sẻ mã của họ với nhau. Và trong việc đặt tên cho các thực tiễn xấu, các thực tiễn tốt nhất để chia sẻ mã là gì?

Ví dụ:

Đây có phải là một thực tế tồi đối với một repo duy nhất có nhiều tập lệnh / dự án có tên 'MiscProjects' không? Trường hợp repo này, như tên cho thấy, là một tập hợp các kịch bản và dự án nhỏ linh tinh. Điều này có thể giống như cách lập trình viên tổ chức các dự án trên bộ nhớ cục bộ của anh ấy / cô ấy, nhưng nó có thể không tối ưu để chia sẻ mã?

Có lẽ nếu một README / tài liệu tốt được thực hiện, nó sẽ tốt hơn? Hoặc miễn là nó được ghi chép lại, bất cứ điều gì đi?

Câu trả lời:


9

Mặc dù không có "thực tiễn xấu" nào được đặt ra, tương tự như vậy với các hệ thống kiểm soát phiên bản khác, vẫn có những quy ước .

Repo Git của bạn nên càng nhỏ càng tốt. Nếu bạn đến từ mô-đun CVS / SVN, thông thường có một kho lưu trữ duy nhất có cấu trúc có thể bao gồm nhiều kho lưu trữ cho một số dự án. Cách Git là tách chúng ra và có repos Git riêng cho từng dự án. Lý do là:

  • Git là nhanh hơn cho repos nhỏ hơn.
  • Do thiết kế của nó, mỗi hoạt động ảnh hưởng đến toàn bộ repo . Sẽ không hiệu quả khi thực hiện các thao tác Git đối với các dự án cần thiết nếu bạn chỉ làm việc với một trong số chúng.

Tài liệu, như mọi khi, là phải. Trong khi mọi người có kỹ năng đọc mã, không ai muốn giải thích mã nhiều hơn họ cần. Sử dụng README cấp cao nhất để mô tả dự án và cấu trúc của repo Git sẽ luôn là một điều tốt cho những người tham gia (hoặc muốn tham gia) vào dự án.

Phần lớn dự án trên GitHub phù hợp với các quy ước. Sử dụng chúng làm ví dụ cho cách cấu trúc các dự án trong tương lai của bạn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.