Vài thư viện lớn hay nhiều thư viện nhỏ?


9

Trong vài tháng, tôi đã tạo ra một khuôn khổ nhỏ để phát triển trò chơi mà tôi hiện đang bao gồm trong tất cả các dự án của mình.

Khung này phụ thuộc vào SFML, LUA, JSONcpp và các thư viện khác. Nó liên quan đến âm thanh, đồ họa, mạng, luồng; nó có một số tiện ích hệ thống tập tin hữu ích và khả năng gói LUA. Ngoài ra, nó có nhiều phương thức tiện ích "ngẫu nhiên" hữu ích, chẳng hạn như trình trợ giúp phân tích cú pháp chuỗi và các tiện ích toán học.

Hầu hết các dự án của tôi sử dụng tất cả các tính năng này, nhưng không phải tất cả các tính năng:

  • Tôi có một trình cập nhật tự động chỉ sử dụng hệ thống tệp và các tính năng mạng
  • Tôi có một trò chơi không có khả năng kết nối mạng
  • Tôi có một dự án không cần JSONcpp
  • Tôi có một dự án chỉ cần những tiện ích chuỗi / toán học

Điều này có nghĩa là tôi phải bao gồm các thư viện chia sẻ SFML / LUA / JSON trong mọi dự án, ngay cả khi chúng không được sử dụng. Các dự án (không nén) có kích thước tối thiểu 10 MB theo cách này, hầu hết trong số đó không được sử dụng.

Giải pháp thay thế sẽ là phân chia khung trong nhiều thư viện nhỏ hơn, mà tôi nghĩ sẽ hiệu quả và thanh lịch hơn nhiều, nhưng cũng sẽ phải trả giá khi phải duy trì nhiều tệp và dự án DLL hơn.

Tôi sẽ phải chia khung của tôi trong rất nhiều thư viện nhỏ hơn:

  • Đồ họa
  • Luồng
  • Mạng
  • Hệ thống tập tin
  • Đồ dùng nhỏ hơn
  • Đồ dùng JSONcpp
  • Đồ dùng LUA

Đây có phải là giải pháp tốt nhất?


1
Hãy nhớ rằng bạn sẽ có thể xây dựng một biểu đồ có hướng của các phụ thuộc của bạn. Nếu một số mô-đun của bạn phụ thuộc vào các mô-đun phụ thuộc vào chúng, bạn chỉ đang gặp rắc rối. Nếu bạn không thể cấu trúc điều này sao cho các phụ thuộc không có hình tròn, bạn không nên lộn xộn với nó.
Bobson

Nó cũng phụ thuộc vào cách lập trình và môi trường lập trình liên quan của bạn, quản lý thư viện và các khái niệm liên quan như thư viện, gói, không gian tên và tương tự ...
umlcat

Đối với tôi, một thư viện chỉ là một container vận chuyển - Đó là kích thước và sự phụ thuộc lẫn nhau (và phụ thuộc bên ngoài) của các thùng nằm bên trong vấn đề đó. Miễn là bạn thiết kế các thùng đơn (ví dụ: tệp đối tượng) là các bộ phận hoạt động độc lập mà không phụ thuộc không cần thiết, cả hai cách đều ổn.
tofro

Câu trả lời:


14

Cá nhân tôi muốn đi cho nhiều thư viện nhỏ.

  • Không khuyến khích các nhà phát triển tạo ra sự phụ thuộc giữa các gói không liên quan.
  • Thư viện nhỏ hơn dễ quản lý hơn mà tập trung hơn nhiều.
  • Dễ dàng hơn để chia tay và có các nhóm riêng quản lý mỗi thư viện.
  • Khi bạn có một yêu cầu mới đủ phức tạp, tốt hơn hết là thêm một mô-đun mới thay vì tìm một thư viện hiện có để chuyển mã mới vào. Các thư viện nhỏ khuyến khích mẫu này.

Nhìn chung, tôi đồng ý mặc dù tôi đã thấy các trường hợp cách tiếp cận thư viện nhỏ không được quản lý tốt và vượt khỏi tầm kiểm soát. Trên một dự án, mỗi thư viện có mã lớp truy cập dữ liệu bán trùng lặp. Mặt khác, có quá nhiều mối quan hệ phụ thuộc giữa các thư viện.
jfrankcarr

@jfrankcarr Đúng, quản lý mã kém có thể ảnh hưởng đến bất kỳ dự án nào. Ý thức của tôi là các dự án có thư viện nguyên khối dễ bị ảnh hưởng hơn so với các dự án có 'thư viện vi mô' nhỏ.
pswg

Chỉ cần một lưu ý phụ - Bản thân SFML được chia thành nhiều mô-đun, do đó bạn không phải liên kết đến ví dụ: Mô-đun mạng nếu trò chơi của bạn chỉ có một người chơi.
sjaustirni 17/03/18

4

Bạn đã đưa ra một mặt của sự đánh đổi, nhưng không phải là một mặt khác. Nếu không có "công bằng và cân bằng" các áp lực mà bạn đang hoạt động, chúng tôi không thể nói cho bạn biết.

Bạn nói rằng việc chia tách các thư viện sẽ làm cho tất cả các dự án của bạn nhỏ hơn. Đó là một điểm cộng rõ ràng. Tôi có thể tưởng tượng nhiều nhược điểm khác nhau:

  • chia tách các thư viện tự nó là một nỗ lực, ngay cả khi nó chỉ phải được thực hiện một lần.
  • duy trì các phiên bản của nhiều thư viện một cách nhất quán là một nỗ lực bổ sung nhỏ nhưng liên tục.
  • Thật không dễ dàng để chắc chắn rằng mọi dự án thực tế thực sự bó những thứ nó cần
  • chia tách có thể không thể sạch như bạn tin vào lúc này và giới thiệu công việc bổ sung, thậm chí có thể đe dọa tính toàn vẹn về mặt khái niệm của một số mô-đun.

Tùy thuộc vào mức độ có thể xảy ra / quan trọng như vậy đối với bạn, chia tách có thể hoặc không thể là lựa chọn phù hợp với bạn. (Lưu ý rằng sự phân đôi giữa "bộ tách" và "bộ gộp" được nhiều người coi là một đặc điểm tính cách cơ bản không dễ bị logic ngay từ đầu!)

Điều đó nói rằng, các nhiệm vụ khác nhau mà bạn nói các mô-đun của bạn đang thực hiện đã bị loại bỏ khỏi nhau mà tôi xem xét ít nhất một số phân tách có thể được yêu cầu.


2

Không có câu trả lời rõ ràng. Yếu tố lái xe tốt nhất tôi có thể nghĩ đến là các thư viện có liên quan với nhau như thế nào và bạn có mong đợi chúng sẽ trở nên liên quan sau này không. Nếu bạn có một mạng lưới phụ thuộc phức tạp thì một thư viện lớn có thể sẽ dễ dàng hơn, nếu bạn có các mối quan hệ tối thiểu thì bạn có thể tách chúng ra một cách sạch sẽ.


0

Điều này có thể rất chủ quan và phụ thuộc vào tâm lý và sự nhạy cảm của bạn, nhưng các thư viện tồn tại lâu nhất của tôi mà tôi đã sử dụng cho các dự án cá nhân của mình và không bắt đầu ghét trong những năm qua luôn là nhỏ nhất, cô lập nhất (không phụ thuộc bên ngoài vào libs khác).

Đó là bởi vì nó chỉ mất một ý tưởng ngu ngốc hoặc cổ xưa để gây rối với toàn bộ nhận thức của tôi về thư viện. Giống như tôi có thể có mã C hoàn toàn hợp lý để rasterize các hình dạng trong thư viện vẽ ngoại trừ nó phụ thuộc vào một thư viện hình ảnh và toán học mà tôi đã viết trong những năm 90 so với các hình ảnh 16 bit, nhìn lại, bây giờ hoàn toàn rất tuyệt. Tôi cũng có thể có một thư viện phân tích cú pháp C ++ với một số mã phân tích cú pháp và mã AST phù hợp trong đó ngoại trừ tôi đã ghép nó với một luồng phân tích cú pháp nguyên khối, nhìn lại, là một thiết kế thực sự ngu ngốc và không thực tế. Vì vậy, bây giờ toàn bộ điều cảm thấy như shite. Hầu hết mã C ++ của tôi từ những năm 90 là hoàn toàn tào lao đối với tôi vì tôi không thực sự biết cách thiết kế hiệu quả trong C ++ hồi đó và đã làm những việc ngu ngốc như sử dụng tính kế thừa để "mở rộng" và cung cấp các lớp hình thành chức năng superset với hơn 100 thành viên và trừu tượng ngớ ngẩn thay vì mô hình hóa các kiểu con phù hợp với giao diện tối giản. Nhiều mã C của tôi đã sống sót qua bộ lọc shite của tôi, mặc dù chỉ là một phần nhỏ. Chủ yếu là tôi đã đưa ra một núi shite. Các hạt cốm vàng nhỏ mà tôi có thể chọn luôn luôn là mã tối giản nhất, tách rời nhất với mục đích duy nhất lớn nhất và thường phụ thuộc ít hơn các loại dữ liệu nguyên thủy.

Sau đó, tôi thậm chí không muốn làm phiền với các lib này nữa ngoại trừ có thể chuyển mã sang một lib mới mà không làm phiền với các lib đó và chỉ hoạt động với các pixel 32 bit và 128 bit thô và thay vào đó là toán học vector thay vì phụ thuộc vào một số lib toán học bên ngoài cho, nói, lib rasterization. Sau đó, mã kéo dài lâu hơn và giữ cho tôi hạnh phúc. Tôi là người hoài nghi với quan điểm của tôi về các thư viện. Tôi có xu hướng đánh giá họ bằng các liên kết yếu nhất thay vì các liên kết mạnh nhất. Tôi không thể bỏ qua cái xấu có lợi cho cái tốt cho đến khi cái xấu được loại bỏ hoàn toàn khỏi thư viện đó.

Vì vậy, tôi bỏ phiếu cho các thư viện nhỏ hơn, độc lập hơn vì chúng có xác suất thấp hơn, ít nhất là đối với tôi, về cảm giác như chúng sẽ trở nên tồi tệ hơn sau này. Nếu bạn đang làm việc trong một nhóm, tôi sẽ bầu chọn cho điều đó thậm chí nhiều hơn với các tiêu chuẩn mạnh hơn để giữ cho các thư viện tách rời nhau, vì chúng có thể trở nên lộn xộn rất nhanh với nhiều bàn tay trừ khi chúng có mục đích rất riêng biệt và mục đích hướng tới sự tối giản (tìm kiếm lý do không thêm nhiều hơn thay vì luôn tìm lý do để thêm nhiều hơn - bạn không thể ghét những gì bạn không thêm vào) ... mặc dù có vẻ như câu hỏi này dành cho các dự án cá nhân nhiều hơn yếu tố tâm lý trong hơn. Nhưng hơn nữa tôi sẽ bỏ phiếu để tách ra các phần chức năng tách rời. Bạn không nhất thiết phải chia khung của bạn cho tất cả các phần bạn muốn ngay lập tức. TÔI'

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.