Pragmatic Programmer – Topic 47: Working Together — Code chung | Blog

Mở đầu

Hồi mới đi làm, mình ghét nhất cái vụ "ngồi chung một máy". Trong đầu mình lúc đó pair programming chỉ là một người gõ, một người ngồi xem — phí thời gian, phí nhân lực. Ai rồi cũng nghĩ "code của mình chỉ mình hiểu, kêu người khác vô chỉ thêm rối". Mãi tới khi kẹt một bug cả buổi chiều, đồng nghiệp ngồi xuống cạnh mình, nhìn màn hình chưa tới năm phút đã chỉ ra chỗ sai — mình mới thấm cái ý của Topic 47 trong Pragmatic Programmer: Working Together. Code chung không phải chuyện "ai gõ, ai xem", mà là hai bộ não cùng chạy trên một bài toán.

Hai lập trình viên nam đang thảo luận code trước laptop Ảnh: olia danilevich — Pexels

Driver và navigator — hai vai, một mục tiêu

Sách phân tích pair programming thành hai vai rất rõ ràng: driver là người đang gõ, còn navigator là người quan sát. Driver mắc kẹt trong chi tiết — cú pháp, tên biến, từng dòng code. Navigator nhìn từ trên xuống: flow có đúng không, có đang giải nhầm bài toán không, chỗ nào sắp nổ bug.

Cái hay là hai vai này phải đổi cho nhau thường xuyên. Cứ 25-30 phút đổi một lần. Đổi vai ép cả hai phải hiểu toàn bộ code, chứ không phải mỗi người ôm một góc rồi né nhau. Mình để ý thấy chính lúc đổi vai là lúc hai đứa tranh luận sôi nổi nhất — và cũng là lúc phát hiện nhiều thứ sai nhất.

# Driver vừa viết xong hàm này, đang hài lòng lắm:
def apply_discount(price, percent):
    return price * percent  # 10% giảm giá mà ra có 10 đồng?

# Navigator nhìn một phát:
# "Ê, discount 10% mà price 100k thì còn 10 đồng hả?"
# — quên chia 100. Bug cổ điển mà mắt người gõ không thấy.

Đúng vậy đó — người viết ra bug thường là người cuối cùng nhìn ra bug. Con mắt thứ hai không phải để soi mói, mà để bắt mấy cú trượt mà bộ não đã "tự sửa" khi đọc lại code của chính mình.

Lợi ích không chỉ là ít bug hơn

Có người nghĩ pair programming chỉ giúp bắt bug sớm. Thật ra lợi ích lớn nhất là chia sẻ kiến thức. Mỗi lần pair là một buổi truyền nghề bất đắc dĩ: người mới học được cách người cũ đặt tên, break function, nghĩ về edge case. Người cũ cũng học ngược lại — bị hỏi "tại sao chỗ này phải làm vậy" hoài thì tự nhiên phải ôn lại lý do đằng sau code của mình.

Còn chuyện bus factor — cái khái niệm "nếu anh này bị xe bus cán thì project chết" — pair chính là cách rẻ tiền nhất để hạ bus factor xuống. Hai người hiểu một module, thay vì một. Không cần document dài dòng, không cần buổi workshop, chỉ cần ngồi chung màn hình vài tiếng mỗi tuần.

Hai người cùng làm việc trên một dự án máy tính trong văn phòng Ảnh: Christina Morillo — Pexels

Mở rộng lên mob programming

Khi bài toán đủ lớn, hoặc cả team đang lạc hướng, sách gợi ý nâng cấp lên mob programming — cả nhóm cùng giải một vấn đề, một người gõ, mấy người còn lại bàn. Nghe thì chậm, nhưng với mấy quyết định kiểu kiến trúc, "chậm một buổi" còn rẻ hơn "refactor một tháng sau khi mỗi người tự đi một hướng".

Quan trọng là đừng biến pair thành "người này gõ, người kia ngồi im xem điện thoại". Pair hiệu quả cần hai thứ: tôn trọng và biết lắng nghe. Phê bình ý tưởng, đừng phê bình người. Đổi bạn pair thường xuyên, đừng ôm mãi một cặp — pair với người khác là cách nhanh nhất để hết "mù" trước những góc nhìn khác trong team.

Hai developer đang xem xét code trên màn hình lớn trong văn phòng hiện đại Ảnh: Mikhail Nilov — Pexels

Kết bài

Tóm lại, Working Together không phải là "mất công ngồi chung", mà là review liên tục + truyền kiến thức + hạ bus factor gói gọn trong một thói quen. Đổi vai đều đặn, đổi bạn pair thường xuyên, phê bình code chứ đừng phê bình người — vậy là pair đã chạy đúng hướng.

Mấy bạn trong team mình xài pair programming thế nào — pair đều mỗi ngày, hay chỉ khi kẹt bug mới nhờ nhau ngồi lại? Hồi đó điều gì làm bạn ngại pair nhất?