Đọc hiểu mã nguồn đồ án của người khác trong ba ngày

Có mã nguồn chạy được rồi nhưng mở ra thấy hai trăm file là cảm giác quen thuộc. Tin tốt: để trả lời hội đồng, bạn không cần hiểu hai trăm file. Bạn cần hiểu một luồng đi xuyên qua hệ thống, và hiểu cấu trúc đủ để biết chức năng nào nằm ở đâu.

Ba ngày, mỗi ngày một mục tiêu rõ ràng.

Ngày 1: cơ sở dữ liệu trước, code sau

Đây là chỗ ai cũng làm ngược. Mở code trước là lạc; mở cơ sở dữ liệu trước là hiểu được cả hệ thống trong hai tiếng.

Mở công cụ quản lý cơ sở dữ liệu, nhìn danh sách bảng, rồi trả lời:

• Có bao nhiêu bảng, bảng nào là bảng chính
• Bảng nào là bảng trung gian của quan hệ nhiều-nhiều
• Khoá ngoại nối bảng nào với bảng nào
• Bảng người dùng lưu vai trò kiểu gì: một cột role, hay bảng roles riêng

Vẽ lại sơ đồ quan hệ ra giấy. Với MySQL Workbench thì hút ngược từ cơ sở dữ liệu ra sơ đồ chỉ mất vài phút, nhưng vẽ tay một lần nhớ lâu hơn nhiều.

Xong bước này bạn đã trả lời được nguyên một nhóm câu hỏi của hội đồng: hệ thống lưu gì, quan hệ ra sao, vì sao tách bảng.

Ngày 2: lần theo đúng một luồng, từ nút bấm tới cơ sở dữ liệu

Chọn một chức năng có ghi dữ liệu, ví dụ "đặt hàng" hoặc "thêm sản phẩm". Không chọn đăng nhập, vì đăng nhập thường dùng thư viện có sẵn nên đọc không thấy được cấu trúc dự án.

Lần theo đúng thứ tự này, mở từng file:

1. Giao diện — nút bấm gọi hàm nào
2. Hàm gọi API — gửi đi đâu, phương thức gì, gửi lên những trường nào
3. Controller ở backend — hàm nào nhận, nhận kiểu dữ liệu gì
4. Service — kiểm tra ràng buộc gì, tính toán gì
5. Repository hoặc câu lệnh SQL — ghi vào bảng nào

Vừa đọc vừa ghi ra giấy tên file và tên hàm ở mỗi tầng. Tờ giấy đó chính là sơ đồ tuần tự trong báo cáo, và cũng là thứ bạn cầm khi hội đồng hỏi "chức năng này chạy thế nào".

Mẹo tìm nhanh: tìm toàn dự án theo chuỗi chữ hiển thị trên màn hình, ví dụ tìm "Đặt hàng thành công". Chuỗi đó gần như luôn nằm ngay cạnh đoạn code cần đọc. Cách này nhanh hơn mở từng thư mục nhiều.

Làm lại một lần nữa với một chức năng chỉ đọc dữ liệu, ví dụ "danh sách sản phẩm". Hai luồng là đủ để thấy quy luật của cả dự án.

Ngày 3: kiểm tra bằng cách tự thêm một chức năng nhỏ

Đọc mà không gõ thì tưởng hiểu. Cách kiểm tra rẻ nhất: tự thêm một thứ nhỏ.

Chọn một việc bé nhưng đi qua đủ mọi tầng, ví dụ:

• Thêm một cột ghi_chu vào bảng sản phẩm, cho hiển thị và sửa được
• Thêm bộ lọc theo khoảng giá vào trang danh sách
• Thêm cột ngày tạo vào bảng danh sách ở trang quản trị

Làm được nghĩa là bạn hiểu thật, vì phải sửa từ cơ sở dữ liệu lên tới giao diện. Làm không được thì chỗ tắc chính là chỗ bạn chưa hiểu, và giờ bạn biết phải hỏi cái gì.

Đây cũng là câu hội đồng rất hay hỏi: "giờ thầy muốn thêm chức năng X thì em sửa ở đâu". Đã tự làm một lần rồi thì trả lời trôi.

Bốn thứ phải biết trước khi vào phòng bảo vệ

Dù không đủ ba ngày, tối thiểu phải nắm bốn thứ sau:

Cấu trúc thư mục. Mở dự án ra, nói được mỗi thư mục chính chứa gì.

Đường đi của một yêu cầu. Từ trình duyệt tới cơ sở dữ liệu đi qua những tầng nào.

Cách xác thực hoạt động. Đăng nhập xong nhận cái gì, cái đó lưu ở đâu, những lời gọi sau gửi nó đi thế nào, hết hạn thì sao.

Chỗ khó nhất của dự án. Mỗi đồ án có một chỗ rắc rối nhất — thuật toán gợi ý, tính tiền có khuyến mãi, xử lý ảnh. Hội đồng luôn hỏi vào đúng chỗ đó. Đọc kỹ riêng phần này.

Những chỗ không cần đọc

Đừng phí thời gian vào: thư viện bên ngoài, file cấu hình dựng, mã tự sinh, phần giao diện thuần trang trí. Không ai hỏi bạn về nội dung file cấu hình đóng gói.

Nếu vẫn tắc

Cách nhanh nhất để gỡ tắc là ngồi cùng người đã dựng dự án đó và đi qua từng tầng một lượt. Một tiếng ngồi cùng bằng cả tuần tự dò, vì bạn hỏi được đúng chỗ mình không hiểu thay vì đọc lan man.

Bên mình có hạng mục riêng cho việc này trong bảng giá, và mọi bản trong danh mục đều kèm phần giải thích cấu trúc dự án.

Đọc thêm

28 câu hỏi phản biện hội đồng hay hỏi — dùng làm đề tự kiểm tra sau ba ngày.

Vẽ sơ đồ use case, ERD và sơ đồ tuần tự — mấy tờ giấy bạn ghi trong ngày 1 và ngày 2 chính là nguyên liệu của chương phân tích thiết kế.