Mở đầu — vì sao bài này quan trọng
Có một niềm tin sai lầm rất phổ biến trong nghề: "BA không cần biết đọc code, đó là việc của dev". Niềm tin này khiến nhiều BA mãi mãi đứng ở vị trí trung gian thụ động — nhận yêu cầu từ business, ném sang cho dev, rồi cầu nguyện rằng thứ được build ra giống với thứ đã viết trong spec. Khi có sai lệch, họ chỉ biết há hốc mồm chờ dev giải thích, và thường là không hiểu lời giải thích đó.
Một Technical BA giỏi thì khác. Bạn không cần viết được code production, không cần thông thạo thuật toán hay tối ưu hiệu năng. Nhưng bạn cần đọc được code đủ để xác minh implementation có khớp với spec hay không, ước lượng độ phức tạp một cách độc lập thay vì tin 100% vào con số dev đưa ra, ngồi cùng dev gỡ một sự cố production mà không trở thành gánh nặng, và phát hiện sớm những lỗ hổng về business logic trước khi nó gây thiệt hại thật.
Hãy hình dung thế này: một bác sĩ không nhất thiết phải tự mổ, nhưng bác sĩ giỏi phải đọc được phim X-quang và kết quả xét nghiệm. Đọc code với BA cũng vậy — nó là kỹ năng đọc "phim chụp" của hệ thống. Trong bài này, chúng ta sẽ học cách đọc code một cách có chiến lược, và cách dẫn dắt một buổi code walkthrough hiệu quả với đội kỹ thuật.
Khái niệm cốt lõi
Đọc code khác với viết code
Điều giải phóng đầu tiên bạn cần hiểu: đọc code dễ hơn viết code rất nhiều. Khi viết, bạn phải đối mặt với một trang trắng, phải nhớ cú pháp chính xác, phải tự nghĩ ra cấu trúc. Khi đọc, mọi quyết định đã có sẵn — việc của bạn chỉ là lần theo luồng logic và đối chiếu với kỳ vọng nghiệp vụ. Bạn được phép bỏ qua những phần kỹ thuật thuần túy (cấu hình kết nối, xử lý threading, tối ưu bộ nhớ) và tập trung vào phần mang nghiệp vụ: điều kiện, vòng lặp, phép tính, và các nhánh rẽ quyết định.
Ba tầng đọc code mà BA cần phân biệt
Tầng 1 — Đọc để định hướng (orientation): Bạn chưa cần hiểu từng dòng. Bạn muốn biết "hệ thống này gồm những phần nào, file nào xử lý cái gì". Đây là lúc đọc tên thư mục, tên file, tên hàm. Một codebase đặt tên tốt sẽ kể cho bạn nghe câu chuyện của nó: calculateLoanInterest, validateKycDocument, sendOtpSms — bạn hiểu ngay chúng làm gì mà chưa cần mở ra.
Tầng 2 — Đọc để xác minh logic nghiệp vụ (verification): Đây là tầng quan trọng nhất với BA. Bạn mở một hàm cụ thể và truy: "Spec nói lãi suất ưu đãi áp dụng cho khoản vay trên 500 triệu, code có đúng vậy không?". Bạn tìm dòng if (loanAmount > 500_000_000) và đối chiếu. Bạn không quan tâm code viết bằng Java hay Python — bạn quan tâm con số 500_000_000 và toán tử > (lớn hơn) hay >= (lớn hơn hoặc bằng).
Tầng 3 — Đọc để gỡ lỗi (debugging): Tầng này thường làm cùng dev. Khi production lỗi, bạn lần theo log, theo dữ liệu đầu vào thực tế, để xác định lỗi nằm ở yêu cầu (spec sai), ở implementation (code sai so với spec), hay ở dữ liệu (data bẩn). BA không cần sửa code, nhưng việc khoanh vùng đúng "loại lỗi" giúp cả đội tiết kiệm hàng giờ.
Những thứ BA NÊN tập trung khi đọc
Trong một file code, hãy huấn luyện mắt mình tìm bốn nhóm này: các điều kiện rẽ nhánh (if/else/switch — nơi business rule sống), các con số và hằng số (ngưỡng, hạn mức, tỷ lệ — nơi sai lệch nghiệp vụ hay ẩn nấp), tên hàm được gọi (để hiểu luồng đi qua những bước nào), và các thông báo trả về cho người dùng (error message, validation message — thứ trực tiếp ảnh hưởng trải nghiệm). Phần còn lại — vòng lặp tối ưu, xử lý ngoại lệ kỹ thuật, dependency injection — bạn có thể lướt qua.
Tình huống thực tế
Tình huống 1 — Ngân hàng số tại TP.HCM: con số > đắt giá
Tại một ngân hàng số ở TP.HCM (tạm gọi là VietDigi Bank), spec của tính năng "miễn phí chuyển khoản" ghi rõ: khách hàng có số dư bình quân tháng từ 2 triệu đồng trở lên được miễn phí chuyển khoản liên ngân hàng. Sau khi lên production, bộ phận chăm sóc khách hàng nhận hàng loạt phàn nàn: khách có đúng 2 triệu vẫn bị trừ phí 7.000đ/giao dịch.
Chị Lan, Technical BA của dự án, không chờ dev điều tra. Chị mở thẳng đoạn code tính phí, tìm hàm isEligibleForFreeTransfer và thấy dòng:
if (averageBalance > 2_000_000) { return true; }
Vấn đề lộ ngay: spec viết "từ 2 triệu trở lên" — tức phải là >= (lớn hơn hoặc bằng), nhưng dev viết > (lớn hơn). Khách có đúng 2.000.000đ rơi vào vùng loại trừ. Chị Lan gắn ảnh chụp dòng code, trích spec, và tạo ticket fix chỉ trong 20 phút. Nếu chị không đọc được code, ticket này sẽ qua tay 3-4 người, mỗi người mô tả lại một kiểu, và có thể mất cả ngày để dev hiểu đúng vấn đề.
Bài học: Lỗi nghiệp vụ tốn kém nhất thường nằm ở những chi tiết nhỏ nhất — một dấu = thiếu. BA đọc được code sẽ bắt được class lỗi này nhanh hơn bất kỳ ai, vì BA là người hiểu rõ nhất ý định nghiệp vụ đằng sau con số.
Tình huống 2 — Sàn TMĐT Đông Nam Á: ước lượng độc lập
Một sàn thương mại điện tử khu vực Đông Nam Á (giả định, quy mô tương tự Tiki) muốn thêm tính năng "áp nhiều mã giảm giá cho một đơn hàng". Dev lead ước lượng 3 sprint (6 tuần) vì "phải viết lại toàn bộ engine tính giá".
Anh Khoa, Technical BA, nghi ngờ con số này quá lớn. Anh mở module tính giá hiện tại, đọc hàm applyDiscount và phát hiện engine thực ra đã được thiết kế nhận một danh sách mã giảm giá (List<Coupon> coupons), nhưng phần giao diện và API chỉ truyền vào một phần tử duy nhất. Tức là phần lõi đã hỗ trợ sẵn nhiều mã, chỉ cần mở khóa ở tầng API và bổ sung rule chống xung đột mã.
Anh Khoa quay lại trao đổi với dev lead bằng dữ kiện cụ thể từ code, không phải bằng cảm tính. Sau khi cùng nhìn lại, cả hai thống nhất ước lượng giảm xuống còn 1 sprint cộng thêm thời gian cho rule chống xung đột. Dự án về đích sớm hơn một tháng.
Bài học: BA đọc được code không phải để "bắt lỗi dev", mà để đối thoại kỹ thuật bình đẳng. Một ước lượng dựa trên việc thực sự nhìn vào code đáng tin hơn nhiều so với phỏng đoán. Đây cũng là cách BA xây dựng uy tín với đội kỹ thuật.
Tình huống 3 — Fintech ví điện tử: gỡ sự cố production lúc nửa đêm
Một công ty fintech ví điện tử tại Hà Nội gặp sự cố: 2% giao dịch nạp tiền bị treo ở trạng thái "đang xử lý" và không bao giờ chuyển sang "thành công" dù tiền đã trừ. Đội on-call gồm một dev và chị Hương — Technical BA của luồng thanh toán.
Thay vì chỉ ngồi nghe, chị Hương cùng dev đọc log và lần theo code xử lý callback từ cổng thanh toán. Chị nhận ra trong hàm handlePaymentCallback, có một nhánh if (callback.status == "SUCCESS") cập nhật trạng thái, nhưng cổng thanh toán mới đây đã đổi giá trị trả về thành "success" viết thường. Code so sánh phân biệt hoa-thường nên không khớp, giao dịch không được cập nhật.
Vì hiểu cả nghiệp vụ lẫn đọc được đoạn so sánh chuỗi, chị Hương xác định ngay đây là lỗi tích hợp do đối tác đổi format, không phải lỗi nội bộ. Chị viết được mô tả chính xác cho dev fix tạm (so sánh không phân biệt hoa-thường) và mở ticket dài hạn yêu cầu đối tác cung cấp tài liệu thay đổi. Sự cố được khoanh vùng trong 40 phút.
Bài học: Trong tình huống production nóng, BA đọc được code rút ngắn đáng kể thời gian khoanh vùng nguyên nhân. Bạn trở thành người cộng tác thực sự với dev chứ không phải khán giả.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng mỗi khi cần đọc một đoạn code, dù là để xác minh spec hay chuẩn bị cho một buổi walkthrough.
Bước 1 — Xác định rõ câu hỏi trước khi mở code. Đừng đọc code lan man. Hãy viết ra câu hỏi cụ thể: "Hàm tính phí có áp dụng đúng ngưỡng 2 triệu không?" hoặc "Khi đơn hàng bị hủy, code có hoàn điểm thưởng không?". Câu hỏi rõ ràng giúp bạn biết cần tìm gì và khi nào thì dừng.
Bước 2 — Tìm điểm vào (entry point). Hỏi dev hoặc dùng chức năng tìm kiếm (search) trong IDE/GitHub để tìm tên hàm hoặc từ khóa liên quan. Ví dụ tìm discount, interest, fee, validate. Bắt đầu từ cái tên gần nhất với nghiệp vụ bạn quan tâm.
Bước 3 — Đọc từ trên xuống, lần theo luồng. Đọc tên hàm, đọc các điều kiện if/else, ghi chú lại bằng tiếng Việt từng bước: "nếu số dư > 2 triệu → miễn phí; ngược lại → tính phí 7.000đ". Bạn đang dịch code thành câu chuyện nghiệp vụ.
Bước 4 — Đối chiếu với spec. Đặt code và spec cạnh nhau. Soi từng business rule: con số có khớp không, toán tử có đúng không, có nhánh nào bị thiếu không, có nhánh nào dư mà spec không nhắc tới không.
Bước 5 — Ghi nhận điểm nghi vấn, không tự kết luận. Nếu thấy lệch, đừng vội khẳng định "code sai". Hãy ghi: "Spec nói X, code đang làm Y, nhờ dev xác nhận". Có thể có lý do kỹ thuật bạn chưa thấy. Thái độ hỏi thay vì buộc tội giữ được quan hệ tốt với đội.
Bước 6 — Tổ chức code walkthrough khi cần. Với những thay đổi lớn hoặc logic phức tạp, hãy mời dev đi qua code cùng bạn. Quy tắc cho buổi walkthrough: chuẩn bị câu hỏi trước, để dev "kể chuyện" qua từng đoạn, bạn liên tục đối chiếu với góc nhìn nghiệp vụ và người dùng ("nếu khách nhập số âm thì sao?", "trường hợp đơn hàng quốc tế thì rẽ vào đâu?"). Buổi walkthrough tốt thường lộ ra các edge case mà cả spec lẫn code đều bỏ sót.
Lỗi thường gặp & mẹo
Lỗi 1 — Cố hiểu từng dòng. Người mới hay sa lầy đọc cả những dòng kỹ thuật vô nghĩa với nghiệp vụ rồi nản. Mẹo: cho phép bản thân bỏ qua. Bạn chỉ cần hiểu phần mang business logic, phần còn lại lướt qua không có tội gì cả.
Lỗi 2 — Tin tuyệt đối vào comment trong code. Comment (chú thích) đôi khi lỗi thời vì code đã đổi mà chú thích chưa cập nhật. Mẹo: code là sự thật, comment chỉ là gợi ý. Khi comment và code mâu thuẫn, hãy tin code và hỏi lại dev.
Lỗi 3 — Đọc code mà không có dữ liệu thật. Hiểu logic nhưng không biết dữ liệu thực tế chạy qua thế nào sẽ dễ kết luận sai. Mẹo: khi gỡ lỗi, luôn hỏi "với input cụ thể này, code đi vào nhánh nào?". Một ví dụ dữ liệu thật quý hơn mười lần đọc suông.
Lỗi 4 — Biến walkthrough thành buổi soi lỗi dev. Nếu BA dùng walkthrough để bắt bẻ, dev sẽ phòng thủ và buổi họp mất tác dụng. Mẹo: đóng khung là "cùng nhau hiểu hệ thống để phục vụ khách hàng tốt hơn". Hỏi "mình hiểu thế này đúng chưa?" thay vì "sao lại làm thế này?".
Mẹo nâng cao — Dùng lịch sử thay đổi (git history) như nhật ký. Khi muốn biết tại sao một đoạn logic lại như vậy, hãy nhờ dev xem commit liên quan. Lời nhắn commit thường ghi lý do thay đổi, giúp bạn hiểu bối cảnh nghiệp vụ trước đây mà không cần đoán mò.
Mẹo — Tự dựng "bản đồ luồng" bằng lời. Sau khi đọc xong, viết lại luồng bằng tiếng Việt thành các bước có đánh số. Nếu viết được mạch lạc nghĩa là bạn đã hiểu; nếu vấp ở đâu, đó chính là chỗ cần hỏi dev.
Bài tập thực hành
Bài 1 — Dịch code thành nghiệp vụ. Cho đoạn giả mã sau, hãy viết lại bằng tiếng Việt thành các business rule và chỉ ra mọi con số, ngưỡng, toán tử:
function calculateShippingFee(order) {
if (order.total >= 500000) return 0;
if (order.region == "noi_thanh") return 15000;
return 30000;
}
Gợi ý: liệt kê 3 nhánh, nêu rõ ngưỡng miễn phí và điểm cần xác nhận với spec (ví dụ: 500.000đ là "từ" hay "trên"?).
Bài 2 — Săn lỗi > và >=. Spec của bạn ghi: "đơn hàng từ 1 triệu trở lên được tặng voucher". Code ghi if (order.total > 1_000_000). Hãy viết một ghi chú ngắn (3-4 dòng) gửi dev mô tả vấn đề, trích spec, và đề xuất sửa — theo đúng giọng cộng tác, không buộc tội.
Bài 3 — Chuẩn bị một buổi code walkthrough. Chọn một tính năng bạn đang làm. Viết ra 5 câu hỏi nghiệp vụ và edge case bạn sẽ đặt cho dev khi đi qua code (ví dụ: input rỗng, số âm, trường hợp khách quốc tế, đơn hàng bị hủy giữa chừng, mất kết nối khi đang xử lý).
Bài 4 — Khoanh vùng lỗi. Mô tả một sự cố production giả định ("khách báo điểm thưởng không được cộng sau khi mua hàng"). Hãy liệt kê 3 giả thuyết về loại lỗi (spec sai / code sai / data bẩn) và với mỗi giả thuyết, nêu bạn sẽ đọc đoạn code nào và tìm dữ liệu gì để kiểm chứng.
Tóm tắt
Đọc code không biến BA thành developer, và đó không phải mục tiêu. Mục tiêu là biến bạn thành một Technical BA có khả năng đối chiếu implementation với spec một cách độc lập, ước lượng và đối thoại kỹ thuật bằng dữ kiện thật, và cộng tác hiệu quả khi gỡ sự cố. Hãy nhớ ba điều cốt lõi: đọc code dễ hơn viết code rất nhiều, nên đừng sợ; chỉ tập trung vào phần mang nghiệp vụ — điều kiện, con số, tên hàm, thông báo — và lướt qua phần kỹ thuật thuần túy; và luôn giữ thái độ cộng tác, dùng câu hỏi thay vì lời buộc tội.
Như các tình huống ở VietDigi Bank, sàn TMĐT khu vực, hay công ty ví điện tử cho thấy, kỹ năng này tạo ra khác biệt thật bằng tiền và bằng thời gian — một dấu = thiếu được bắt trong 20 phút, một ước lượng cắt giảm cả tháng, một sự cố production khoanh vùng trong 40 phút. Hãy bắt đầu nhỏ: lần tới khi nhận một tính năng, xin dev cho xem đoạn code xử lý business rule quan trọng nhất và tự dịch nó thành tiếng Việt. Làm đều đặn, bạn sẽ ngạc nhiên vì code không đáng sợ như mình tưởng.