Cách nhanh nhất để hiểu một hệ thống là chọn một hành động cụ thể của người dùng rồi lần theo nó qua từng lớp: giao diện gửi đi cái gì, máy chủ nhận ở đâu, kiểm tra những gì, đọc và ghi dữ liệu nào, rồi trả về cái gì. Mỗi lần lần theo như vậy là một sợi chỉ nối những phần mã rời rạc thành một bức tranh.
Chào bạn, đây là Nhà Lập Trình. Tập trước mình nói về việc nhận một dự án cũ. Tập này đi sâu vào kỹ năng mà mình coi là quan trọng nhất khi đọc mã người khác: đi theo một yêu cầu từ đầu tới cuối. Người giỏi kỹ năng này có thể vào bất kỳ dự án nào và bắt đầu làm việc sau vài ngày.
Chọn một hành động đủ nhỏ và đủ thật
Đừng chọn hành động kiểu hiểu phần thanh toán. Nó quá rộng. Hãy chọn một cú bấm cụ thể: người dùng đã đăng nhập, bấm nút thêm vào giỏ ở trang một sản phẩm. Hoặc: nhân viên kho bấm xác nhận đã nhận hàng.
Hành động càng cụ thể, bạn càng biết mình đang tìm gì. Bạn biết điểm bắt đầu là nút nào, điểm kết thúc là dữ liệu nào thay đổi. Mọi thứ ở giữa là con đường bạn cần khám phá.
Hãy chọn hành động mà người dùng thật làm nhiều. Đó thường là con đường được viết kỹ nhất, được sửa nhiều nhất, và phản ánh đúng cách dự án được tổ chức. Những chức năng ít ai dùng thường là chỗ có mã lạ, để sau.
Trước khi bắt đầu, tự đoán thử: mình nghĩ yêu cầu này sẽ đi qua những đâu. Sau khi lần theo xong, so với phỏng đoán. Chỗ nào đoán sai là chỗ bạn vừa học được điều mới về dự án.
Lớp giao diện: nút bấm gửi đi cái gì
Bắt đầu từ phía người dùng. Mở công cụ dành cho nhà phát triển có sẵn trong trình duyệt, chuyển sang phần theo dõi mạng, rồi bấm nút. Bạn sẽ thấy chính xác yêu cầu nào được gửi đi, tới đường dẫn nào, mang theo dữ liệu gì, và máy chủ trả lời ra sao.
Đây là một mẹo tiết kiệm rất nhiều thời gian. Thay vì đọc mã giao diện để đoán nút bấm gọi tới đâu, bạn nhìn thẳng vào thứ thật sự đi qua mạng. Có đường dẫn rồi, bạn tìm nó trong mã phía máy chủ.
Với ứng dụng điện thoại, việc này khó hơn một chút, nhưng vẫn có công cụ để xem các yêu cầu ứng dụng gửi đi trong môi trường thử nghiệm.
Ghi lại đường dẫn, dữ liệu gửi đi và dữ liệu trả về. Đây là hai đầu của sợi chỉ. Việc còn lại là nối chúng.
Lớp máy chủ: từ cửa vào tới nơi xử lý
Ở phía máy chủ, tìm xem đường dẫn đó được giao cho phần mã nào xử lý. Thường có một bảng định tuyến. Từ đó bạn tới được hàm xử lý chính.
Nhưng trước khi tới hàm chính, yêu cầu thường đi qua vài lớp trung gian chạy ngầm cho mọi yêu cầu: kiểm tra đăng nhập, kiểm tra quyền, ghi nhật ký, chống gửi trùng. Những lớp này thường không nằm cạnh hàm chính, và người mới hay bỏ sót. Rồi họ không hiểu vì sao yêu cầu bị từ chối trước khi tới hàm của mình.
Trong hàm chính, đi từng bước. Dùng công cụ gỡ lỗi chạy từng dòng nếu có, dừng ở từng bước để xem dữ liệu lúc đó trông như thế nào. Nếu không dùng được công cụ gỡ lỗi, in ra tạm vài dòng để thấy dữ liệu đi qua.
Chú ý những chỗ luồng chạy rẽ nhánh theo điều kiện. Người dùng thường khác người dùng thành viên, sản phẩm còn hàng khác sản phẩm hết hàng. Ghi lại các nhánh, nhưng chỉ đi sâu nhánh chính trước.
Lớp dữ liệu và những việc chạy ngầm
Cuối cùng yêu cầu chạm tới cơ sở dữ liệu. Xem nó đọc bảng nào, ghi bảng nào, ghi những cột nào. Nếu có thể, bật chế độ ghi lại mọi câu truy vấn trong môi trường thử nghiệm, rồi bấm nút một lần và xem danh sách truy vấn được chạy. Có khi bạn sẽ ngạc nhiên vì một cú bấm đơn giản lại chạy tới vài chục truy vấn.
Rồi hãy để ý những việc không chạy ngay. Nhiều hệ thống đẩy một phần công việc ra chạy ngầm: gửi thư xác nhận, cập nhật báo cáo, đồng bộ sang hệ thống khác. Yêu cầu đã trả kết quả cho người dùng, nhưng câu chuyện vẫn chưa kết thúc.
Còn có những thứ tự động kích hoạt bên trong cơ sở dữ liệu, chạy mỗi khi một bảng thay đổi. Chúng vô hình khi đọc mã chương trình. Nếu bạn thấy một cột thay đổi mà không tìm được dòng mã nào ghi nó, hãy nghi ngờ chúng.
Những việc chạy ngầm và tự động là nơi các lỗi khó hiểu nhất thường trú ẩn. Biết chúng tồn tại đã là một nửa chiến thắng.
Vẽ lại sợi chỉ bằng lời của bạn
Khi lần theo xong, hãy vẽ lại, bằng giấy bút hay bằng vài dòng chữ. Một chuỗi ô vuông nối với nhau: nút bấm, đường dẫn, lớp kiểm tra, hàm xử lý, bảng dữ liệu, việc chạy ngầm. Không cần đẹp, chỉ cần đúng.
Bản vẽ này giúp bạn nhớ. Nó cũng giúp bạn thấy những điều lạ. Vì sao kiểm tra quyền ở hai chỗ? Vì sao đọc cùng một bảng ba lần? Những câu hỏi đó có khi dẫn tới lỗi thật, có khi dẫn tới một lý do lịch sử mà bạn nên biết.
Làm vài lần với vài hành động khác nhau, bạn sẽ có một tập bản vẽ. Chồng chúng lên nhau, bạn có bản đồ của cả hệ thống, ít nhất là của những con đường quan trọng nhất.
Kỹ năng này mang theo được mọi nơi. Ngôn ngữ thay đổi, khung ứng dụng thay đổi, nhưng mọi hệ thống đều có yêu cầu đi vào, được xử lý, chạm vào dữ liệu và trả ra. Người biết lần theo sợi chỉ thì không sợ dự án lạ.
Câu hỏi thường gặp
Công cụ dành cho nhà phát triển trong trình duyệt dùng để làm gì?
Để xem cấu trúc trang, theo dõi các yêu cầu mạng, xem thông báo lỗi của chương trình chạy trên trình duyệt và đo tốc độ tải. Phần theo dõi mạng đặc biệt hữu ích khi muốn biết một nút bấm gửi gì tới máy chủ.
Không dùng được công cụ gỡ lỗi thì lần theo mã bằng cách nào?
Có thể in tạm dữ liệu ra nhật ký ở từng bước, hoặc đọc mã kết hợp với tìm kiếm toàn dự án. Nhớ xoá các dòng in tạm sau khi xong để không làm rối nhật ký.
Vì sao một cú bấm lại chạy nhiều truy vấn cơ sở dữ liệu?
Thường do chương trình lấy dữ liệu từng mẩu trong vòng lặp thay vì lấy một lần, hoặc do nhiều lớp cùng đọc cùng một dữ liệu. Đây là nguyên nhân phổ biến khiến trang chậm.
Làm sao biết có việc chạy ngầm sau một yêu cầu?
Tìm trong mã những chỗ đẩy việc vào hàng đợi hoặc lịch chạy định kỳ, và xem nhật ký của các tiến trình chạy nền. Nếu dữ liệu thay đổi mà không thấy mã nào ghi, hãy kiểm tra cả các tự động kích hoạt trong cơ sở dữ liệu.
Có nên thử lần theo mã trên hệ thống đang chạy thật?
Chỉ nên quan sát, như đọc nhật ký, không nên bấm thử các thao tác thay đổi dữ liệu. Việc lần theo từng bước nên làm trên môi trường thử nghiệm với dữ liệu giả hoặc bản sao.
