Phương pháp con vịt cao su là giải thích từng dòng mã của mình thành lời cho một người nghe, kể cả khi người nghe chỉ là một con vịt đồ chơi đặt trên bàn. Khi buộc phải nói rõ từng bước chương trình làm gì và vì sao, bạn sẽ vấp ngay ở chỗ mình tưởng là hiểu mà thật ra đang giả định sai. Và đó thường chính là chỗ có lỗi.
Chào bạn, đây là Nhà Lập Trình. Có lẽ ai làm nghề cũng từng trải qua cảnh này: bí một lỗi cả buổi, sang bàn đồng nghiệp nhờ xem, bắt đầu giải thích, và giữa chừng tự dừng lại: à, thôi, mình biết rồi. Đồng nghiệp chưa kịp nói câu nào. Tập này kể vì sao chuyện đó xảy ra, và cách biến nó thành một công cụ chủ động.
Cái tên kỳ lạ và câu chuyện đằng sau
Cái tên con vịt cao su đến từ một câu chuyện được kể đi kể lại trong giới lập trình: một người lập trình mang theo một con vịt cao su, và mỗi khi gặp lỗi, anh ta giải thích mã cho con vịt nghe, từng dòng một. Con vịt không nói gì, nhưng rất nhiều lần anh ta tự tìm ra lỗi giữa chừng.
Câu chuyện nghe buồn cười, nhưng ý tưởng thì nghiêm túc. Nhiều đội còn đặt thật một con vịt đồ chơi trên bàn, như một lời nhắc: trước khi làm phiền đồng nghiệp, hãy giải thích cho con vịt trước.
Không nhất thiết phải là con vịt. Có người nói với chậu cây, có người nói với con mèo, có người viết ra giấy như thể đang viết thư cho một người bạn không biết gì về dự án. Điều quan trọng là hành động giải thích, không phải người nghe.
Một chị lập trình ở Sài Gòn kể chị có một con gấu bông nhỏ trên bàn. Đồng nghiệp đi ngang thấy chị thì thầm với con gấu thì biết là đừng làm phiền, chị đang gỡ lỗi.
Vì sao nói ra lại thấy lỗi?
Khi bạn đọc mã trong đầu, não đi rất nhanh và tự lấp đầy những khoảng trống. Bạn nhìn một dòng, não bảo dòng này lấy danh sách khách hàng, và bạn lướt qua. Nhưng dòng đó có thật sự lấy danh sách khách hàng không, hay chỉ lấy khách hàng đang hoạt động? Não không dừng lại để kiểm tra.
Khi nói ra thành lời, bạn buộc phải đi chậm. Bạn phải chọn từ, phải nói trọn câu. Dòng này lấy danh sách khách hàng... khoan, có điều kiện gì ở đây, à, chỉ những khách đã xác nhận thư. Nhưng khách mình đang thử thì chưa xác nhận. Lỗi nằm đó.
Nói ra cũng buộc bạn phải giải thích vì sao. Dòng này làm gì là một chuyện. Vì sao nó cần ở đây là chuyện khác. Khi không trả lời được câu vì sao, bạn vừa tìm ra một giả định mình chưa bao giờ kiểm tra.
Người nghe, dù là người thật hay con vịt, tạo ra một áp lực nhẹ: bạn phải nói cho rõ để người ta hiểu. Chính áp lực đó làm tư duy của bạn sắc lại.
Cách làm cho có hiệu quả
Bắt đầu từ trên cùng, từ chỗ dữ liệu đi vào. Nói rõ dữ liệu vào trông như thế nào, cụ thể từng giá trị. Không nói một danh sách đơn hàng, mà nói một danh sách có ba đơn, đơn đầu có hai sản phẩm.
Đi từng dòng, nói dòng đó làm gì với dữ liệu, và dữ liệu sau dòng đó trông thế nào. Đừng nhảy cóc. Đặc biệt đừng nhảy qua những dòng mà bạn nghĩ là hiển nhiên đúng, vì lỗi thích trốn ở đó nhất.
Khi gặp một lời gọi hàm, dừng lại hỏi: mình có chắc hàm này làm đúng điều mình nghĩ không? Mình đã đọc nó chưa hay chỉ đoán theo tên? Nhiều lỗi nằm ở chỗ hàm có tên nghe giống việc mình cần, nhưng làm hơi khác.
Nếu làm một mình, hãy nói thành tiếng thật hoặc viết ra. Nghĩ trong đầu không có tác dụng như vậy, vì não lại chạy nhanh và lấp chỗ trống.
Viết câu hỏi cũng là một con vịt
Một biến thể rất hiệu quả là viết câu hỏi để nhờ giúp. Khi bạn chuẩn bị đăng câu hỏi lên diễn đàn hoặc nhắn cho đồng nghiệp, hãy viết thật kỹ: mình đang làm gì, mong đợi gì, thực tế ra sao, mình đã thử những gì.
Rất thường xuyên, trong lúc viết phần mình đã thử những gì, bạn nhận ra còn một thứ chưa thử. Thử nó, và lỗi được giải quyết trước khi bấm gửi. Câu hỏi chưa bao giờ được gửi đi, nhưng nó đã làm tròn nhiệm vụ.
Ngay cả khi phải gửi, một câu hỏi được viết kỹ sẽ nhận câu trả lời nhanh và chính xác hơn nhiều. Người giúp bạn không phải đoán, không phải hỏi lại.
Trợ lý AI cũng có thể đóng vai con vịt, với một ưu điểm là nó có thể đặt câu hỏi ngược lại. Nhưng hãy cẩn thận: đôi khi nó vội đưa ra lời giải trước khi bạn kịp tự suy nghĩ, và bạn mất đi phần có giá trị nhất của việc giải thích.
Không chỉ dùng khi có lỗi
Phương pháp này không chỉ để gỡ lỗi. Trước khi bắt tay viết một chức năng phức tạp, hãy giải thích cho con vịt mình định làm thế nào. Những chỗ bạn ấp úng là chỗ thiết kế còn mù mờ, và sửa thiết kế lúc này rẻ hơn nhiều so với sửa mã sau này.
Khi xem lại mã của chính mình trước khi gửi cho đồng nghiệp, hãy giải thích nó cho con vịt. Bạn sẽ phát hiện những chỗ đặt tên khó hiểu, những đoạn thừa, những trường hợp chưa xử lý.
Khi học một khái niệm mới, hãy thử giải thích nó cho con vịt như giải thích cho một đứa em. Chỗ nào bạn không giải thích được đơn giản là chỗ bạn chưa thật sự hiểu.
Con vịt cao su có lẽ là công cụ rẻ nhất trong nghề lập trình. Nó không cần cài đặt, không cần cập nhật, không bao giờ hết hạn. Nó chỉ cần bạn chịu nói chậm lại.
Câu hỏi thường gặp
Phương pháp con vịt cao su có tác dụng thật không?
Có, nhiều người làm nghề xác nhận từ kinh nghiệm của mình. Việc giải thích thành lời buộc bạn đi chậm, nói rõ từng bước và lộ ra những giả định chưa kiểm tra, vốn là nơi lỗi hay trốn.
Có nhất thiết phải dùng con vịt không?
Không. Người nghe có thể là đồng nghiệp, chậu cây, hoặc một trang giấy. Điều quan trọng là hành động giải thích rõ ràng từng bước, không phải người nghe.
Vì sao giải thích cho đồng nghiệp thì tự tìm ra lỗi?
Vì khi giải thích, bạn phải nói trọn vẹn và chậm hơn khi nghĩ trong đầu, nên vấp phải chỗ mình giả định sai. Đồng nghiệp không cần nói gì, sự lắng nghe của họ đã đủ.
Dùng trợ lý AI thay con vịt có được không?
Có thể, trợ lý còn biết hỏi ngược lại. Nhưng nên tự giải thích xong trước rồi mới đọc gợi ý của nó, để không bỏ qua phần tự suy nghĩ vốn là giá trị chính của phương pháp.
Ngoài gỡ lỗi, phương pháp này còn dùng vào việc gì?
Dùng để kiểm tra thiết kế trước khi viết mã, xem lại mã trước khi gửi đồng nghiệp, và kiểm tra mình đã thật sự hiểu một khái niệm mới hay chưa.
