CODE_READING.md

minh.nguyen: Thông thường thì em sẽ follow theo (hầu hết) các bước sau:

• RTFM.
• Dựng và chạy hệ thống với các settings được recommend trong doc. Ví dụ Redis sẽ có sentinel hoặc Redis cluster hoặc standalone.
• Explore tất cả các feature của system hoặc tất cả interface của library, nhất là những feature nào có vẻ fancy.
• Build from source. Chạy lại bằng build object được sinh ra. Ngó thử xem hệ thống có bao nhiêu components, dependencies.
• Đọc thử design doc nếu có
• Debug thử xem giữa các component liên hệ với nhau như thế nào. Thông thường các hệ thống đều có doc.
• Pick một flow đơn giản nhất, Tìm thử entrypoint trong code. Đặt debugger xem thử chạy ra sao.
• Change thử một feature nho nhỏ xem thê nào
• Thực sự đọc code. Lúc đọc thì ghi chú, note lại kĩ càng, không mau quên lắm. Đặc biệt chú ý đến những cái high level design hơn là implementation detail. Chú ý đến những class quan trọng. Chú ý đến background threads.
• Đọc không thì chán lắm. Pick trong issue list ra một cái bug fix thử. Submit và contribute

giongto35: dạ, nghe cũng hay vì càng làm việc nhiều em càng thấy đó là vấn đề. Và đến giờ em vẫn luôn tìm cách tối ưu nhất.

1. Nếu Codebase nhỏ, new product. Đọc hết tất cả PR từ đầu đến hiện tại : hiểu được code history (cái này rất quan trọng, hiểu context của magic) Codebase lớn:

   1. tree để xem code structure
   2. xác định entrypoint file, xác định file được change nhiều nhất : 80% thời gian của người viết code để sửa 20% files git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10 (chôm trên mạng)
   3. có 1 con IDE thật tốt với khả năng find references siêu việt ( ba cái trò text find thì thôi) + run code + debug bằng breakpoint + stack trace

ledongthuc: à ok em. Coi như trong trường hợp bài bản đi nha, tức là không bị gấp, không bị ai rượt nha.

Thì cách tiếp cận của anh thường là top-down, từ general tới detail.1. Step 1 thường anh sẽ đi từ business:

• Anh sẽ phải tìm hiểu coi cái service/source code/system này dùng để làm gì, có tác dụng gì trong business cty/tổ chức
• Nếu nó là dạng service thì anh phải coi service này có chức năng gì, lưu trữ gì, có tác dụng ra sao trong toàn hệ thống
• Nếu nó là dạng library thì mục đích của library này là gì, giải quyết vấn đề gì
• Idea của step này thì thường là non-code, tìm hiểu business, tìm hiểu problem mà cái mình sắp đọc đang giải quyết2. Step tiếp theo anh sẽ tập trung vào cách communicate của source code ra ngoài
• Nếu nó là commandline thì sẽ đọc cách sử dụng commandline, arguments như thế nào
• Nếu nó là API thì đọc xem có những api nào, params nào, lúc này có thể là API dạng REST, protobuf, socket, bla bla
• Nếu nó là web thì coi cách sử dụng từ UI Step này sẽ đa phần tập trung vào document + 1 phần nhỏ code ở tầng communication (API define/UI)3. Step tiếp anh sẽ đọc tới business logic code Ở step này thì bắt đầu anh phải lựa chọn dựa vào mục đích anh đọc cái source code/dự án này:
• Đọc để fix/sửa 1 flow xác định nào đó.
• Đọc để biết general để handle toàn bộ sau này.Nếu Anh chỉ target vào 1 flow/feature xác định nào đó, thì dựa vào step (2), anh sẽ truy vết ra phần business của phần đó để đọc. Nếu anh cần handle toàn bộ, anh sẽ dựa vào step (1) để xác định main purpose của services và dựa vào step (2) để truy vết ra những business logic của phần đó mà đọcỞ phần này, anh sẽ target tập trung đọc vào cái work flow của feature/business.
• Note lại những datasource mà cái flow em đang đọc access vào (write file/db/cache/…)
• Note lại những phần mà logic call ra ngoài hệ thống (kiểu như em call ra service/hệ thống khác để lấy data)
• Note lại những library được dùng trong cái flow ấy^ dựa vào mấy cái trên thì tuỳ tình huống, tuỳ độ hiểu biết của em mà em sẽ consider phải đọc thêm hay ko

Thông thường tới step này là anh ngừng không đọc nữa. Tuỳ vào tình huống đặc biệt hoặc cần làm gì đặc biệt hơn thì anh mới đọc thêm. Idea của anh là đọc để nắm mục đích, cách xài và main flow working thôi. Còn detail hơn thường anh đọc xong anh cũng quên, nên những phần sâu hơn thì khi cần anh sẽ đọc lại.

hieuk09 Kinh nghiệm của mình thì thế này:

• Đầu tiên phải setup được project và chạy test được: cái này quan trọng nhất, làm tiền đề để tiếp tục các bước sau. Bước này có thể khó với project phức tạp, ngôn ngữ không quen thuộc.
• Tiếp theo, tuỳ vào business logic đơn giản hay không mà tiếp cận top-down hay bottom up
  • Nếu business logic phức tạp, nên thử tiếp cận top-down trước: chạy integration test hoặc test tay trên browser để hiểu luồng hoạt động, sau đó xem code để hiểu business được implement như thế nào. Ở bước này có thể thay đổi logic ở code và chạy lại test xem mọi thứ thay đổi như thế nào để hiểu thêm.
  • Nếu business logic đơn giản, hoặc không thể setup được code/test để chạy thử, thì nên chia codebase thành các layer (ví dụ web app thông thường thì là Model-View-Controller), tìm đọc layer thấp nhất trước, sau đó search thử xem layer thấp nhất dó được sử dụng như thế nào. Ví dụ có model User và hàm update_password, thì có thể search user.update_password xem nó được dùng ở đâu, rồi từ đó đi ngược lên để hiểu luồng hoạt động.
• Bước cuồi là tìm các global state / monkey-patch / constant của code để xem assumption của hệ thống là gì, từ đó sẽ dễ hiểu hơn những trade-off trong code, cũng như giới hạn mà những assumption đó mang lại.