Cấu trúc dự án hợp lý, được tiêu chuẩn hóa hợp lý nhưng linh hoạt để thực hiện và chia sẻ công việc khoa học dữ liệu
Tại sao sử dụng cấu trúc dự án này?
Chúng tôi không nói về việc thay đổi tính thẩm mỹ của vết lõm hoặc các tiêu chuẩn định dạng mô phạm - cuối cùng, chất lượng mã khoa học dữ liệu là về tính chính xác và khả năng tái tạo
Khi nghĩ về phân tích dữ liệu, chúng ta thường chỉ nghĩ về các báo cáo kết quả, thông tin chi tiết hoặc trực quan hóa. Mặc dù các sản phẩm cuối này thường là sự kiện chính, nhưng thật dễ dàng để tập trung vào việc làm cho các sản phẩm trông đẹp mắt và bỏ qua chất lượng của mã tạo ra chúng. Vì những sản phẩm cuối cùng này được tạo theo chương trình nên chất lượng mã vẫn rất quan trọng. Và chúng tôi không nói về việc thay đổi tính thẩm mỹ của vết lõm hoặc các tiêu chuẩn định dạng mô phạm - cuối cùng, chất lượng mã khoa học dữ liệu là về tính chính xác và khả năng tái tạo
Không có gì bí mật rằng các phân tích tốt thường là kết quả của những khám phá rất ngẫu hứng và ngẫu nhiên. Các thử nghiệm dự kiến và các phương pháp thử nghiệm nhanh có thể không thành công đều là một phần của quy trình để đạt được nội dung tốt và không có viên đạn thần kỳ nào để biến việc khám phá dữ liệu thành một tiến trình tuyến tính, đơn giản
Điều đó đang được nói, một khi đã bắt đầu, nó không phải là một quá trình khiến bản thân nó phải suy nghĩ cẩn thận về cấu trúc của mã hoặc bố cục dự án của bạn, vì vậy, tốt nhất là bắt đầu với một cấu trúc hợp lý, rõ ràng và tuân theo nó trong suốt quá trình. Chúng tôi nghĩ rằng đó là một chiến thắng khá lớn khi sử dụng một thiết lập khá chuẩn như thế này. Đây là lý do tại sao
Người khác sẽ cảm ơn bạn
Không ai ngồi một chỗ trước khi tạo một dự án Rails mới để tìm ra nơi họ muốn đặt quan điểm của mình;
Một cấu trúc dự án tiêu chuẩn, được xác định rõ ràng có nghĩa là một người mới có thể bắt đầu hiểu một phân tích mà không cần đào sâu vào tài liệu mở rộng. Điều đó cũng có nghĩa là họ không nhất thiết phải đọc 100% mã trước khi biết nơi tìm kiếm những thứ rất cụ thể
Mã được tổ chức tốt có xu hướng tự viết tài liệu trong đó tổ chức tự cung cấp ngữ cảnh cho mã của bạn mà không cần nhiều chi phí. Mọi người sẽ cảm ơn bạn vì điều này vì họ có thể
- Cộng tác dễ dàng hơn với bạn trong phân tích này
- Tìm hiểu từ phân tích của bạn về quy trình và miền
- Cảm thấy tự tin vào kết luận mà phân tích đưa ra
Một ví dụ điển hình về điều này có thể được tìm thấy trong bất kỳ khung phát triển web chính nào như Django hoặc Ruby on Rails. Không ai ngồi một chỗ trước khi tạo một dự án Rails mới để tìm ra nơi họ muốn đặt quan điểm của mình; . Bởi vì cấu trúc dự án mặc định đó là tiêu chuẩn hợp lý và hợp lý trong hầu hết các dự án, nên sẽ dễ dàng hơn nhiều đối với những người chưa bao giờ xem một dự án cụ thể để tìm ra nơi họ sẽ tìm thấy các bộ phận chuyển động khác nhau
Một ví dụ tuyệt vời khác là Tiêu chuẩn phân cấp hệ thống tệp cho các hệ thống giống Unix. Thư mục /etc có một mục đích rất cụ thể, cũng như thư mục /tmp và mọi người [ít nhiều] đồng ý tôn trọng hợp đồng xã hội đó. Điều đó có nghĩa là người dùng Red Hat và người dùng Ubuntu đều biết đại khái nơi tìm kiếm một số loại tệp nhất định, ngay cả khi sử dụng hệ thống của nhau — hoặc bất kỳ hệ thống tuân thủ tiêu chuẩn nào khác cho vấn đề đó
Lý tưởng nhất, đó là cách nên diễn ra khi một đồng nghiệp mở ra dự án khoa học dữ liệu của bạn
Bạn sẽ cảm ơn bạn
Bạn đã bao giờ cố gắng tái tạo một phân tích mà bạn đã thực hiện cách đây vài tháng hoặc thậm chí vài năm chưa? . Dưới đây là một số câu hỏi mà chúng tôi đã học cách hỏi với cảm giác sợ hãi về sự tồn tại
- Chúng ta có phải đi vào và nối cột X với dữ liệu trước khi bắt đầu hay dữ liệu đó đến từ một trong các sổ ghi chép?
- Hãy nghĩ về nó, chúng ta phải chạy sổ ghi chép nào trước khi chạy mã vẽ. đó là "dữ liệu xử lý" hay "dữ liệu sạch"?
- Các tệp hình dạng được tải xuống từ đâu cho các ô địa lý?
- Vân vân, lần vô cực
Những loại câu hỏi này rất khó và là triệu chứng của một dự án vô tổ chức. Một cấu trúc dự án tốt khuyến khích các phương pháp giúp quay lại công việc cũ dễ dàng hơn, chẳng hạn như tách các mối quan tâm, phân tích trừu tượng dưới dạng DAG và các phương pháp hay nhất về kỹ thuật như kiểm soát phiên bản
Không có gì ở đây là ràng buộc
"Sự nhất quán ngớ ngẩn là con yêu tinh của những bộ óc nhỏ bé" - Ralph Waldo Emerson [và ]
Không đồng ý với một vài tên thư mục mặc định?
Cứ liều thử đi. Đây là một cấu trúc nhẹ và được coi là điểm khởi đầu tốt cho nhiều dự án. Hoặc, như PEP 8 đã nói
Tính nhất quán trong một dự án quan trọng hơn. Tính nhất quán trong một mô-đun hoặc chức năng là quan trọng nhất. . Tuy nhiên, hãy biết khi nào không nhất quán -- đôi khi các đề xuất hướng dẫn về phong cách không áp dụng được. Khi nghi ngờ, hãy sử dụng phán đoán tốt nhất của bạn. Nhìn vào các ví dụ khác và quyết định những gì có vẻ tốt nhất. Và đừng ngần ngại hỏi
Bắt đầu
Với suy nghĩ này, chúng tôi đã tạo một mẫu cookiecutter khoa học dữ liệu cho các dự án trong Python. Phân tích của bạn không nhất thiết phải bằng Python, nhưng mẫu cung cấp một số bản mẫu Python mà bạn muốn xóa [ví dụ: trong thư mục
├── LICENSE
├── Makefile