anhtholu444
Senior Member
Mình chỉ học lập trình thời sinh viên. Giờ đi làm chạy phần mềm mã nguồn mở nhiều mà nhiều khi gặp lỗi nhiều khi cần phải đi sâu vào sản phẩm. Không biết đi sâu vào sản phẩm giải pháp nên bắt đầu từ đâu các bác nhỉ.
thắc mắc Có cách nào để đọc hiểu code 1 dự án mã nguồn mở
- Người tạo chủ đề anhtholu444
- Ngày bắt đầu
ngndo
Đã tốn tiền
Bạn chạy code nó không bị lỗi là auto hiểu. Kĩ năng chạy code thành công là kĩ năng quan trọng nhất của dev.
meekoo
Senior Member
Hỏi AI chưa a bạn? AI nó trả lời cặn kẽ với ân cần hơn vozer đấy.
nchhnchh
Senior Member
Build dc ở local, start dc như bác trên nói. xong thì đọc test case hay đọc những case nhỏ nhỏ trước. OS cũng như đi làm thôi. Đọc xong r thì check issue xem có cái nào mình contribute dc koBạn chạy code nó không bị lỗi là auto hiểu. Kĩ năng chạy code thành công là kĩ năng quan trọng nhất của dev.
hungpn2212
Senior Member
opensource chỉ cần kiên nhẫn thôi, đọc nhiều khắc quen
buitruong1689
Senior Member
Đọc hiểu code của người khác nó là kỹ năng cần phải tập luyện chứ ko phải tự dưng lên mạng hỏi công thức là làm được đâu.
Nếu fen không có kiến thức cơ bản về mảng đó, chưa bao giờ viết bất cứ phần mềm, thư viện gì liên quan đến code mà fen đang đọc. Thì 99% là fen sẽ không hiểu tí gì để có thể follow hay chỉnh sửa được code của người khác cả.
Tưởng tượng đơn giản nó giống như việc fen phải học bảng cửu chương xong mới hiểu được người khác làm toán nhân chia vậy.
Diệp Vô Ưu
Member
vứt cả source cho agent đọc rồi nó giải thích cho :
wynn.bullerman
Senior Member
kevinnnn
Junior Member
hold_on_never_leave
Senior Member
cx từng vọc vạch open source, share lại 1 vài kinh nghiệm:
nên bắt đầu đọc từ source mà scope nhỏ, vừa đủ, focus vào 1 vài tính năng core , chứ mới mà nhảy thẳng vào mấy source lớn như k8s, database engine,... thì dễ nản, một vài source được tổ chức theo monorepo, gồm nhiều package riêng biệt cho từng feature, khi đấy chỉ tập trung vào 1 vài package mình cần
đọc open source sẽ học đc khá là nhiều thứ hay ho, nhưng khá là boring, đặc biệt trong thời đại content ngắn lên ngôi, ngồi đọc từng dòng code 1 không phải ai cũng kiên nhẫn để làm được
nhưng nếu ai muốn deep dive vào 1 vấn đề thì nó xứng đáng, nhiều vấn đề hơn cả đọc sách, vì sách nhiều khi không nói kĩ về implementation, và các issue trong quá trình vận hành
- hiểu functionality của source đó trước, lý tưởng nhất là bạn tương tác với function source đó hàng ngày (các thư viện dùng trong dự án), còn nếu là source mà bạn không sử dụng (low level), integrate trực tiếp thì sẽ khó hơn
- đọc source viết bằng static type sẽ dễ hơn so với dynamic type cực kì nhiều, vì dynamic type hay có trò inject magic code vào, không thể hiểu được vì sao nó lại chạy, như mình thì chủ yếu đọc source Golang, Java, JS thỉnh thoảng cũng đọc nhưng thấy khó đọc hơn Golang
- inspect từ ngoài expose function, đi dần dần vào trong để đọc logic
- các open source thường viết test, chạy test sẽ giúp hiểu flow của 1 function hơn khá là nhiều, thay vì phải chạy e2e flow, setup lằng nhằng, chạy test, đặt debug vào xem flow thay đổi thế nào khá là hiệu quả (source mà ko có test thì bỏ qua cái này)
- khả năng đọc hiểu source structure / search: cái này kinh nghiệm là chính, đôi khi bạn sẽ cần phán đoán phần mình muốn tìm nằm ở đâu, nhìn source structure + khả năng search code trong source sẽ giúp tìm nhanh hơn là ngồi mò từng tí 1
- bây giờ thì có thể vừa đọc vừa hỏi AI, sẽ giúp hiểu nhanh hơn, nhưng cần phân biệt 2 vấn đề riêng biệt: hiểu flow, và hiểu tại sao code / solution lại như vậy, AI thường chỉ giúp hiểu flow hơn, còn hiểu code / solution thì phải ngồi mò Issue / discussion / MR thì mới có thêm context, khi đó mới hiểu được, phần lớn sẽ đều bắt đầu với 1 solution đơn giản -> user report issue -> improvement
nên bắt đầu đọc từ source mà scope nhỏ, vừa đủ, focus vào 1 vài tính năng core , chứ mới mà nhảy thẳng vào mấy source lớn như k8s, database engine,... thì dễ nản, một vài source được tổ chức theo monorepo, gồm nhiều package riêng biệt cho từng feature, khi đấy chỉ tập trung vào 1 vài package mình cần
đọc open source sẽ học đc khá là nhiều thứ hay ho, nhưng khá là boring, đặc biệt trong thời đại content ngắn lên ngôi, ngồi đọc từng dòng code 1 không phải ai cũng kiên nhẫn để làm được
nhưng nếu ai muốn deep dive vào 1 vấn đề thì nó xứng đáng, nhiều vấn đề hơn cả đọc sách, vì sách nhiều khi không nói kĩ về implementation, và các issue trong quá trình vận hành
Mỹ Chu Lang
Senior Member
mấy source project Golang CNCF như Prometheus, Loki, Mimir, Tempo... dễ đọc không bác, có cần vững kiến thức OS, Network trước không nhỉ, em định tìm hiểu sau này apply vô Grafana Labs hoặc mấy công ty tương tự, bác có exp mảng này không chia sẻ em ít với, cảm ơn báccx từng vọc vạch open source, share lại 1 vài kinh nghiệm:
- hiểu functionality của source đó trước, lý tưởng nhất là bạn tương tác với function source đó hàng ngày (các thư viện dùng trong dự án), còn nếu là source mà bạn không sử dụng (low level), integrate trực tiếp thì sẽ khó hơn
- đọc source viết bằng static type sẽ dễ hơn so với dynamic type cực kì nhiều, vì dynamic type hay có trò inject magic code vào, không thể hiểu được vì sao nó lại chạy, như mình thì chủ yếu đọc source Golang, Java, JS thỉnh thoảng cũng đọc nhưng thấy khó đọc hơn Golang
- inspect từ ngoài expose function, đi dần dần vào trong để đọc logic
- các open source thường viết test, chạy test sẽ giúp hiểu flow của 1 function hơn khá là nhiều, thay vì phải chạy e2e flow, setup lằng nhằng, chạy test, đặt debug vào xem flow thay đổi thế nào khá là hiệu quả (source mà ko có test thì bỏ qua cái này)
- khả năng đọc hiểu source structure / search: cái này kinh nghiệm là chính, đôi khi bạn sẽ cần phán đoán phần mình muốn tìm nằm ở đâu, nhìn source structure + khả năng search code trong source sẽ giúp tìm nhanh hơn là ngồi mò từng tí 1
- bây giờ thì có thể vừa đọc vừa hỏi AI, sẽ giúp hiểu nhanh hơn, nhưng cần phân biệt 2 vấn đề riêng biệt: hiểu flow, và hiểu tại sao code / solution lại như vậy, AI thường chỉ giúp hiểu flow hơn, còn hiểu code / solution thì phải ngồi mò Issue / discussion / MR thì mới có thêm context, khi đó mới hiểu được, phần lớn sẽ đều bắt đầu với 1 solution đơn giản -> user report issue -> improvement
nên bắt đầu đọc từ source mà scope nhỏ, vừa đủ, focus vào 1 vài tính năng core , chứ mới mà nhảy thẳng vào mấy source lớn như k8s, database engine,... thì dễ nản, một vài source được tổ chức theo monorepo, gồm nhiều package riêng biệt cho từng feature, khi đấy chỉ tập trung vào 1 vài package mình cần
đọc open source sẽ học đc khá là nhiều thứ hay ho, nhưng khá là boring, đặc biệt trong thời đại content ngắn lên ngôi, ngồi đọc từng dòng code 1 không phải ai cũng kiên nhẫn để làm được
hold_on_never_leave
Senior Member
có fen, đọc thì fen sẽ thấy toàn network vs OS thôi, nếu fen chưa trực tiếp làm việc với syscall bao giờ thì đọc sẽ khá là khó đấymấy source project Golang CNCF như Prometheus, Loki, Mimir, Tempo... dễ đọc không bác, có cần vững kiến thức OS, Network trước không nhỉ, em định tìm hiểu sau này apply vô Grafana Labs hoặc mấy công ty tương tự, bác có exp mảng này không chia sẻ em ít với, cảm ơn bác
Mỹ Chu Lang
Senior Member
làm job gì thì hay đụng vào network, syscall thế bác, em làm backend dev hỏi loanh quanh đồng nghiệp thì hiếm khi đụng vào mảng này lắm, thường chỉ có CRUD, nếu traffic cao thì optimize db, code asynchronous, concurrency thôi
hold_on_never_leave
Senior Member
ở VN thì ko có mấy job kiểu này đâu, nên ko có ai làm cũng phải, fen muốn làm thì cứ xác định tự bơi từ a-z đilàm job gì thì hay đụng vào network, syscall thế bác, em làm backend dev hỏi loanh quanh đồng nghiệp thì hiếm khi đụng vào mảng này lắm, thường chỉ có CRUD, nếu traffic cao thì optimize db, code asynchronous, concurrency thôi
Mỹ Chu Lang
Senior Member
sợ học xong không có việc làm thì toang bác ạở VN thì ko có mấy job kiểu này đâu, nên ko có ai làm cũng phải, fen muốn làm thì cứ xác định tự bơi từ a-z đi
hold_on_never_leave
Senior Member
cái đó thì fen phải tự cân bằng thôisợ học xong không có việc làm thì toang bác ạ
market luôn đúng mà, ở đâu thì phải theo đó chứ, muốn theo ngách riêng thì fen phải đi đường riêng thôi, hoặc sang nước ngoài 
Niels Henrik Abel
Member
lên git vào coi open issue. fork về xem fix được ko.
Mỹ Chu Lang
Senior Member
okay cảm ơn bác nhacái đó thì fen phải tự cân bằng thôi
