- Trong quá trình theo dõi bug của một thư viện mã nguồn mở, đã phát sinh vấn đề trình gỡ lỗi không hoạt động
- Dù mã đã được thực thi, vẫn xuất hiện hiện tượng breakpoint bị bỏ qua, nên đã thử tìm vấn đề bằng cách khác
- Đã thử chẩn đoán theo đường vòng như thêm log output, nhưng không thu được insight như mong muốn
- Cuối cùng, khi sửa lỗi cấu hình của debugger, có thể quan sát chi tiết hoạt động của chương trình và nhờ đó giải quyết được bug
- Từ trải nghiệm mải mê giải quyết vấn đề mà bỏ qua lỗi của chính công cụ, tác giả nhấn mạnh rằng lập trình viên cần sửa công cụ trước thì mới có thể giải quyết vấn đề hiệu quả
Vấn đề phát sinh khi chẩn đoán bug
- Trong quá trình tìm bug của thư viện mã nguồn mở đang được duy trì, xuất hiện hiện tượng debugger bỏ qua breakpoint
- Dù chắc chắn mã đã thực thi đến dòng đó, chương trình vẫn chạy xong mà không dừng lại
- Vì quá tập trung vào việc giải quyết vấn đề, tác giả đã bỏ qua lỗi của debugger và thử các cách tiếp cận khác
- Đã thử sửa mã và chẩn đoán bằng cách thêm log, nhưng không thu được thông tin hữu ích
Sửa debugger và giải quyết vấn đề
- Quyết định xử lý lỗi của debugger, và hoàn tất việc sửa bằng một thay đổi cấu hình chỉ một dòng
- Sau khi sửa, có thể quan sát chi tiết hoạt động của chương trình
- Dựa trên thông tin đó, đã giải quyết bug thành công
Nhận ra và bài học
- Nhận ra tình huống mang tính nghịch lý: sự nhiệt tình sửa bug lại khiến tác giả bỏ qua vấn đề của công cụ
- Trải nghiệm trực tiếp việc hiệu quả giải quyết vấn đề giảm đi khi công cụ không hoạt động đúng cách
- Điều cần thiết với lập trình viên là thói quen kiểm tra và sửa công cụ trước khi xử lý vấn đề
- Khép lại bằng câu “Fix your tools”, như một thông điệp nhắc mọi lập trình viên về tầm quan trọng của công cụ
1 bình luận
Ý kiến trên Hacker News
Tôi đã có 30 năm kinh nghiệm, và dạo này các công cụ phát triển bị hỏng quá nhiều
Tôi viết code trên Linux bằng Clio, và suốt nhiều năm nay bug ngày càng tệ hơn
Giờ thì tôi chỉ kiểu “không được thì thôi vậy” rồi bỏ qua. Đời ngắn lắm, không có dư thời gian để sửa cả code của người khác
Khi cố sửa một vấn đề thì rốt cuộc lại rơi vào “yak shaving”
Cứ định xử lý một chuyện nhỏ là hàng loạt việc lặt vặt khác lại nối tiếp nhau
Có thể xem video liên quan ở đây
Đôi khi dọn dẹp công cụ và thư viện xong thì năng suất tăng bùng nổ, lúc khác thì cứ hardcode thẳng lại nhanh hơn
AI có giúp mài giũa công cụ, nhưng đồng thời cũng làm phạm vi công việc phình ra nên cuối cùng vẫn tốn chừng ấy thời gian cho việc quản lý công cụ
Cuối cùng đây là vấn đề trì hoãn mang tính cảm xúc (procrastination). Hoặc là không muốn nghĩ về toàn bộ cấu trúc nên cứ lặp đi lặp lại mấy chỉnh sửa nhỏ, hoặc ngược lại cứ trì hoãn thiết kế tổng thể rồi chỉ chăm chăm chỉnh công cụ chi tiết
Thật ra đó cũng là quá trình xử lý ma sát và bất tiện cần thiết
Nhưng vẫn phải luôn kiểm tra xem sự bất tiện đó có thực sự cần hay không
Bỏ ra 10–15 phút để tự động hóa hoặc rút ngắn một việc lặp đi lặp lại thực chất là mua thời gian cho tương lai
Cuối cùng thì nợ kỹ thuật sớm muộn gì cũng phải trả, nên cần tập thói quen trả dần từng chút một
Kỹ thuật rốt cuộc là chuỗi liên tục của việc mài rìu
Tôi thích cách tiếp cận của Kent Beck: “Hãy làm cho thay đổi trở nên dễ dàng trước, rồi mới thực hiện thay đổi dễ dàng đó”
Cảm giác cải thiện code còn thỏa mãn hơn nhiều so với chỉ thêm tính năng
AI không thấy có gì lạ khi lặp lại cùng một đoạn code nhiều lần, nên không tạo được cấu trúc hay tái sử dụng
Thực tế hơn là đang làm giữa chừng thấy cùn thì mài lại
Họ cứ nói “Giờ bận lắm, không có thời gian mài rìu đâu!” rồi tiếp tục làm việc một cách kém hiệu quả
Tôi rất ấn tượng với câu kiểu như: “Ham muốn sửa bug lại che mất sự thật rằng cần sửa công cụ trước”
Hiện tượng này cũng được bàn tới trong cuốn Why Greatness Cannot Be Planned của Kenneth Stanley
Đây là lời khuyên rất hay. Tôi cũng cố thực hành mỗi ngày
Nhưng lời khuyên tiếp theo là “Giờ thôi sửa công cụ đi, hãy sửa vấn đề thật sự” thì lại không dễ làm theo
Tôi cũng thường xuyên rơi vào tình huống này
Sửa những ma sát nhỏ sẽ tiết kiệm thời gian về sau, nhưng cũng có cái bẫy là cứ mày mò công cụ mãi không dứt
Điều thật sự khó là biết lúc nào nên nói “thế này là đủ rồi” và bước tiếp
Công cụ là thứ tạo ra hiệu ứng nhân lên cho nỗ lực
Nhưng rất khó tìm được điểm cân bằng giữa ‘yak shaving’ và lao động thủ công không cần thiết
Nếu định dùng cùng một công cụ trong dài hạn, thì ngay cả cải thiện 1% cũng có hiệu ứng tích lũy lớn, nên có lẽ phải nghiêng về phía yak shaving nhiều hơn ta tưởng
Bài học lớn nhất là các công cụ all-in-one đa phần đều không ra gì
Tôi đã thử đủ loại công cụ no-code như Make, Airtable, n8n cho pipeline nội dung, nhưng đến một quy mô nhất định thì cái nào cũng vỡ
Cuối cùng tự gọi API bằng script Python lại ổn định hơn hẳn
Giải pháp thật sự không phải là sửa một công cụ phức tạp, mà là thay nó bằng công cụ đơn giản và minh bạch hơn
Tự nhìn luồng chạy của code bằng debugger là cực kỳ hữu ích
Nó giúp hiểu trực quan hơn nhiều so với phân tích tĩnh
Nếu cứ liên tục đổi biến hoặc breakpoint thì rất dễ bỏ lỡ bản chất của vấn đề
Chỉ nên dùng debugger như công cụ để kiểm chứng giả thuyết. Nếu không sẽ rơi vào cảm giác “tưởng như đang tiến triển”
Nếu thích những bài như thế này thì tôi đùa rằng đừng bao giờ cài Emacs