cây mã nguồn: rộng hoặc sâu

Question

Sau khi viết một vài ứng dụng appengine python, tôi thấy mình bị rách giữa hai cách tiếp cận để tổ chức cây mã nguồn của tôi: rộng hoặc sâu.

Để biết cụ thể, hãy xem xét đơn đăng ký nội bộ cho một cửa hàng tư vấn nhỏ để quản lý hoạt động kinh doanh như quản lý liên hệ, theo dõi dự án & báo cáo và quản lý nhân viên. Ứng dụng có thể sử dụng các thực thể chính như: Công ty, Người dùng, Danh bạ, Khách hàng, Dự án, Timesheets, v.v. Nếu không đi vào chi tiết, người ta có thể tưởng tượng rằng các mô hình này cắt ngang qua các chức năng của trang web. Điều này có thể có nghĩa là có một số khớp nối.

Trong ví dụ này, là nó thích hợp hơn để tổ chức trong một cách sâu sắc, ví dụ:

models/ 
    people.py 
    accounting.py 
    projects.py 
    foo.py 
controllers/ 
    reporting.py 
    employeeops.py 
    accounting.py 
    crm.py 
views/ 
    ... 

hoặc rộng cách, ví dụ, bằng cách "ứng dụng":

people/ 
    models/ 
    views/ 
    controllers/ 
contact-mgmt/ 
    models/ 
    views/ 
    controllers/ 
time-tracking/ 
    models/ 
    views/ 
    controllers/ 
project-reporting/ 
    models/ 
    views/ 
    controllers/ 

tôi biết tất cả các thiết kế liên quan đến sự cân bằng, vì vậy khi trả lời bạn có thể chỉ ra sở thích của bạn và một số lý do (ví dụ, giả định, điều chỉnh các mối quan tâm, giới hạn khuôn khổ, vấn đề khả năng mở rộng, cân nhắc bảo trì mã, tác động của cấu trúc nhóm phát triển, v.v.).

Answer 1

Lưu ý: Tôi chưa từng làm việc trong python cụ thể. Có nói rằng ...

Rộng và tôi sẽ cho bạn biết lý do: Không bao giờ đau khi có thể xóa mọi thứ nhanh chóng. Trong sự nghiệp của tôi, tôi thường được yêu cầu thêm những thứ và đưa ra một lịch trình tương đối hợp lý để làm điều đó, nhưng khi một thứ gì đó cần phải được loại bỏ, yêu cầu hầu như không bao giờ đi kèm với phân tích tác động hoặc thời gian để gây rối. Khi bạn phá vỡ mọi thứ bằng các mô-đun chức năng chính, bạn thường kết thúc với một thiết kế ghép đôi ít hơn nhiều. Nó có thể là một nỗi đau thực sự trong ass, nhưng đối với những lần khi bạn hoàn toàn có để có được các mô-đun thứ tự làm việc tắt vào cuối tuần, nó là một cuộc sống tiết kiệm.

Answer 2

Cấu trúc thư mục quá sâu làm cho nó khó hiểu. Quá rộng làm cho nó khó hiểu. Tôi muốn giữ sự cân bằng giữa chúng. Về dự án tôi đang làm việc, chúng tôi không biết chúng tôi cần gì, vì vậy chúng tôi không sớm tạo ra một cấu trúc thư mục lớn. Sau khi tất cả, chúng tôi chỉ bắt đầu với 5 tệp, vì vậy chúng tôi thực sự không có cần cho cấu trúc thư mục. Khi dự án trở nên lớn hơn, chúng tôi tổ chức mọi thứ để giữ cho nó gọn gàng như chúng tôi đã đi; không có thư mục nào có nhiều hơn 10 tệp, phân nhóm mọi thứ thành các thư mục một cách rõ ràng. Nó sẽ mất một vài phút để di chuyển nó xung quanh. Bây giờ chúng tôi có hơn một trăm tập tin, và nó luôn luôn rõ ràng mọi thứ đang ở đâu. Đề nghị của tôi là làm tương tự - giữ cho nó gọn gàng, đừng đi quá xa với chiều sâu hoặc chiều rộng, hoặc bạn sẽ làm quá phức tạp.

Answer 3

Trong trường hợp của bạn, tôi nghĩ mô hình "rộng" là tốt hơn. Bạn nên cố gắng tạo ứng dụng để chúng có thể sử dụng lại ngay cả khi bạn không định sử dụng lại chúng ở bất kỳ đâu vì điều này sẽ khuyến khích ghép nối lỏng lẻo hơn với các ứng dụng khác nhau và giúp bảo trì dễ dàng hơn trong thời gian dài.

Answer 4

Thực ra tôi thích trộn. Phần mềm được chia thành các thành phần ngang và dọc.
Các thành phần nằm ngang có thể tái sử dụng trên tất cả các mô-đun và đại diện cho mã chung được sử dụng lại mà không phải là ứng dụng cụ thể, thay vào đó là kiến ​​trúc cụ thể.
Vì vậy, tôi có các thư mục dành cho các tiện ích phổ biến, Khung, thư viện cơ sở hạ tầng có thể tái sử dụng, chẳng hạn như Persistence, Communications, Security, ... vn ...

Thành phần dọc là trường hợp sử dụng riêng lẻ. Đối với mỗi trường hợp sử dụng, tôi có một thư mục có giao diện người dùng, máy chủ và dưới UI tôi có chế độ xem và bộ điều khiển. Mô hình thường được chia sẻ giữa hai người.

Nếu dự án của bạn thực sự lớn thì bạn có thể có các lĩnh vực trách nhiệm khác nhau, chẳng hạn như Kiểm soát khoảng không quảng cáo, Bán hàng, Quản lý liên hệ, Báo cáo vv ... Thêm các cấu trúc này vào thư mục của bạn và đặt các trường hợp sử dụng theo chúng.

Hãy thoải mái nếu có bất kỳ tái sử dụng nào để di chuyển bất kỳ thành phần nào lên trên cây.