Khám Phá Code Review và Hợp Tác Mở Nguồn

Giới thiệu

Tuần này, trong bài lab đầu tiên, tôi đã có cơ hội hợp tác với một bạn học để xem xét mã của nhau và đưa ra những cải tiến. Đây thực sự là một trải nghiệm quý giá, không chỉ đơn thuần là viết mã. Đây là cơ hội tuyệt vời để xem xét các quan điểm khác nhau về cùng một nhiệm vụ và yêu cầu phản hồi.

Phương Pháp Async vs. Sync

Trong đợt xem xét mã này, tôi đã chọn cách tiếp cận bất đồng bộ (async). Thay vì giao tiếp theo thời gian thực trên MS Teams, tôi đã sử dụng Github Issues để cung cấp phản hồi sau khi đã dành thời gian xem xét kỹ lưỡng mã. Lý do chính cho sự lựa chọn này là nó cho phép mọi người phân tích mã một cách sâu sắc và thoải mái hơn. Nó cũng đảm bảo rằng tất cả phản hồi đều được ghi lại, giúp dễ dàng tham khảo khi cần thiết. Tôi thấy điều này hữu ích trong việc tổ chức các vấn đề và kiểm tra những cải tiến đã đưa vào dự án.

Những gì tôi đã học được

Mã tôi xem xét được viết bằng Python, tóm tắt thông tin của một kho mã Git vào một tệp văn bản duy nhất. Cấu trúc mã của Denis rất tốt, sử dụng argparse và pathlib. Tôi biết rằng tôi phải sử dụng argparse cho các tham số dòng lệnh nhưng tôi đã nhận được ý tưởng từ mã của Denis về việc sử dụng pathlib cho quản lý đường dẫn tệp.

Tôi cũng học được rằng việc tạo cấu trúc cơ bản của toàn bộ mã trước khi bắt đầu triển khai các hàm trợ giúp là rất hiệu quả. Denis đã ghi lại tất cả các hàm cần thiết với nhãn "Cần triển khai" để nhắc nhở về những gì cần hoàn thành.

Các Vấn Đề Chính Tôi Đã Ghi Nhận

Khi tôi bắt đầu xem xét mã, nó đang ở giai đoạn đầu nên hầu hết mã đều có nhãn "Cần hoàn thành". Tôi đã tạo hai vấn đề cho tài liệu và hai vấn đề cho việc triển khai tính năng.

README: Hướng dẫn cài đặt Python

Tệp README.md thiếu hướng dẫn về cách thiết lập môi trường Python hoặc cài đặt các thư viện cần thiết. Tôi đã tạo một vấn đề để thêm hướng dẫn cụ thể hơn để người dùng mới có thể dễ dàng thiết lập dự án.

README: Thêm tệp LICENSE vào dự án

Giấy phép là rất quan trọng cho bất kỳ dự án mã nguồn mở nào. Dự án đã có tệp License nhưng sẽ tốt hơn nếu chỉ định điều này trong tệp README.md.

Triển khai "write_git_info" để thêm chi tiết kho

Hàm write_git_info dự kiến sẽ lấy thông tin chi tiết của kho. Nó đã có nhãn "Cần triển khai" nhưng việc tạo một vấn đề sẽ là cách tốt để theo dõi công việc cần hoàn thành.

Triển khai "write_struct_tree" để tạo cây thư mục

Lý do tương tự như hàm trên, hàm "write_struct_tree" cũng nằm dưới nhãn "Cần hoàn thành". Tôi đã tạo một vấn đề yêu cầu triển khai tính năng này để theo dõi các công việc này.

Nhận Xét Mã Của Tôi

Việc có người khác xem xét mã của tôi hơi xấu hổ. Tôi cảm thấy như mình đang để ai đó cười nhạo công việc của mình. Tuy nhiên, nó cũng mang lại cảm giác rất đáng giá khi tôi thấy những vấn đề được tạo ra bởi các đồng đội. Nó khiến tôi nhận ra rằng phản hồi không phải là chỉ trích, mà là một gợi ý để cải thiện dự án.

Định dạng của cây cấu trúc

Đây là một vấn đề mà tôi đã nhận thức. Nó chỉ in toàn bộ danh sách tệp thay vì hiển thị trong một cây cấu trúc. Đây sẽ là điều đầu tiên tôi cần làm.

Thiếu in đường dẫn tuyệt đối

Như thường lệ, lỗi phát sinh từ nơi bạn nghĩ là đã triển khai đúng. Tôi đã dành một chút thời gian để kiểm tra xem các đường dẫn có được in đúng không nhưng thực tế là không. Cảm ơn Denis đã phát hiện ra lỗi này và tạo vấn đề để thu hút sự chú ý của tôi.

Thiếu triển khai tùy chọn -o

Tôi chưa đến giai đoạn này với dự án của mình và các vấn đề sẽ giúp tôi theo dõi những điều cần triển khai. Bộ nhớ của con người rất dễ quên nên tôi sẽ thường xuyên truy cập vào các vấn đề này để nhắc nhở bản thân.

Những Bài Học Tôi Đã Rút Ra Từ Bài Lab Này

Tôi đã học được một vài bài học quan trọng trong suốt bài lab này. Thành thật mà nói, tôi chưa bao giờ nghĩ về tầm quan trọng của tệp README nhưng giờ tôi đã hiểu rằng tệp README định nghĩa ấn tượng đầu tiên của một dự án và khuyến khích người khác tìm hiểu dự án. Thứ hai, tôi học được rằng phản hồi xây dựng không phải là chỉ trích. Phản hồi có một định nghĩa rất khác so với chỉ trích. Nó không chỉ chỉ ra những cải tiến có thể cho dự án mà còn tiết kiệm thời gian của tôi để nhận ra các lỗi và vấn đề cần chú ý. Cuối cùng, tôi rất ấn tượng về cách mà các vấn đề có thể biến những ý tưởng mơ hồ hoặc báo cáo lỗi thành các nhiệm vụ có tổ chức. Tôi luôn thích có một hướng đi khi bắt đầu làm việc gì đó và các vấn đề là chỉ báo rõ ràng nhất về nơi bắt đầu và nơi để tiếp tục.