- Gỡ lỗi về bản chất là một năng lực bắt buộc đối với lập trình viên
- Trong gỡ lỗi, tư duy về cách tiếp cận vấn đề là điều quan trọng
- Gỡ lỗi là quá trình lần tìm nguyên nhân của vấn đề dựa trên tình huống và dữ liệu đã cho
- Tác giả gọi điều này là trực giác
- Trực giác là việc kết nối kiến thức mình biết với vấn đề
- Kinh nghiệm đóng vai trò như lối tắt giúp kiến thức chuyển hóa thành trực giác
- Khi cần tìm nguyên nhân của những hành vi ngoài dự kiến, lập trình viên sẽ theo bản năng thu hẹp dần các khả năng có thể xảy ra
- Tác giả cho rằng việc thu hẹp từng khả năng một dựa trên các nguyên tắc sẽ hiệu quả hơn
- Giới thiệu bốn bước để tìm ra vấn đề
- Thứ nhất, nghi ngờ
- Mọi thứ như mã nguồn, log, thông báo lỗi, dữ liệu giám sát, yêu cầu, phần cứng... đều là thông tin để giải quyết vấn đề
- Nên lập checklist
- Thứ hai, phân loại
- Trong số thông tin đã thu thập, hãy chia ra điều mình biết và điều mình chưa rõ
- Những thông tin được sàng lọc ngay ở giai đoạn thu thập là nhờ trực giác nhỏ
- Tác giả phân loại thành bốn nhóm: lỗi logic, lỗi ở công nghệ phụ thuộc, lỗi ở công nghệ nền tảng, và lỗi vật lý
- Thứ ba, học hỏi
- Hãy tìm ra những khoảng trống kiến thức và học dựa trên thông tin đã thu thập
- Thứ tư, kết nối
- Dựa trên thông tin, hãy lập giả thuyết về vấn đề và tiến hành thử nghiệm
- Nếu trong quá trình này xuất hiện góc nhìn mới, hãy dùng vòng lặp phản hồi bằng cách quay lại bốn bước
- Những nội dung đã giới thiệu ở trên là cách hữu ích để rèn luyện trực giác đã nhắc tới
- Nếu bạn chưa có nguyên tắc gỡ lỗi của riêng mình, có thể xây dựng dựa trên bài viết này hoặc tạo mới; sẽ còn tốt hơn nếu bạn chia sẻ thêm các mẹo hay
7 bình luận
Tôi rất đồng cảm. Và có vẻ như bài viết đã tổng hợp, sắp xếp khá tốt rồi đưa ra một cách tiếp cận mang tính khái quát cho việc debug.
Trên thực tế, trong quá trình debug, rất nhiều nguyên nhân và kiến thức nền khác nhau đan xen với nhau một cách phức tạp, nên tôi nghĩ quá trình thu hẹp trọng tâm để tìm ra manh mối cần thiết trong đó là thực sự rất quan trọng.
Bài viết nói rằng trong quá trình ấy cần mài giũa trực giác và khả năng thấu insight; dường như để theo cảm giác mà xác định đâu là nguyên nhân, và nên bắt đầu điều tra xoay quanh đâu, thì trực giác được tôi luyện từ kinh nghiệm và cảm nhận chiếm một phần rất lớn ở đây.
Tôi đồng cảm. Tôi đã muốn diễn đạt rõ trực giác mà bạn nói đến, nhưng nghĩ rằng xuyên suốt cả bài, thống nhất dùng “insight” thay cho trực giác có lẽ sẽ tốt hơn.
Tôi nghĩ rằng có người làm được suy luận và có người thì không.
Chắc là vào khoảng 30 năm trước.
Các đàn anh thường nói rằng làm IT khoảng 3 năm thì năng lực của mọi người sẽ trở nên ngang nhau.
Giờ nghĩ lại thì ....
Liệu việc kết nối thông tin sẽ tự nhiên hơn nếu xem đó là lĩnh vực của suy luận hoặc chứng minh logic, thay vì của trực giác? Khi đã lặp đi lặp lại việc chứng minh đến mức thuần thục, có thể các bước trung gian được lược bỏ và đáp án hiện ra ngay giống như khi thuộc lòng bảng cửu chương nên trông như trực giác, nhưng tôi nghĩ vẫn nên phân biệt hai điều đó.
Về phần còn lại như nghi ngờ, phân loại và học tập, tôi đồng ý vì tôi đã trải nghiệm rằng chúng được cải thiện khi kinh nghiệm và kiến thức nền tích lũy dần.
Tôi đọc lại bài một lần nữa rồi xin bổ sung.
Có vẻ như định nghĩa về trực giác mà tác giả đưa ra khác với định nghĩa về trực giác đang được dùng phổ biến trong xã hội. Tôi hiểu rằng định nghĩa thông thường của trực giác là hiểu vấn đề mà không cần quá trình suy nghĩ nào. Khi đọc bài, có lúc tôi tự hỏi liệu mình đã hiểu sai ý nghĩa của trực giác hay không nên đã phải kiểm tra lại. Tôi cũng nghĩ điều này không phải là mâu thuẫn với luận điểm tổng thể rằng debugging cần có một quy trình suy nghĩ sao? Nếu debugging thật sự là công việc có thể được thực hiện hoàn toàn bằng trực giác, thì chẳng phải lập luận rằng khi debugging hoàn toàn không cần kiểm tra log hay dữ liệu, cũng không cần quản lý cấu hình, cũng phải đúng hay sao?
Xin chào. Cảm ơn bạn đã quan tâm đến bài viết.
Như bạn nói, nhìn chung trực giác có nghĩa là nắm bắt đối tượng mà không cần một hoạt động tư duy trực tiếp. Tuy vậy, tôi không nghĩ rằng trong trạng thái thực sự không có bất kỳ kiến thức nào thì có thể đi đến đáp án đúng được.
Trước hết, nếu viết ra suy nghĩ của tôi về từ "trực giác", thì khi nói về debug, tôi thường nghe đồng nghiệp nói hoặc chính mình cũng từng nói những câu như "tự nhiên nghĩ ra", "không hiểu sao nhưng có vẻ chỗ đó là vấn đề". Tôi xem phần đó là trực giác. Khi không bỏ qua những ý nghĩ chợt xuất hiện ấy mà kiểm tra từng cái một, cuối cùng tôi nhận ra rằng mình đã từng có kinh nghiệm với phần đó hoặc hiểu khá rõ kiến thức liên quan. Vì vậy tôi đã dùng từ "trực giác", và vì có thể gây hiểu nhầm nên tôi đã thêm câu "trực giác là việc kết nối những kiến thức tôi biết với vấn đề".
Vì vậy, để trả lời một vài thắc mắc bạn nêu theo suy nghĩ của tôi,
Về ý "mâu thuẫn với luận điểm tổng thể rằng debug cần có quy trình tư duy", thì trực giác mà tôi diễn đạt trong bài được mô tả là việc lược bỏ mà không cần suy nghĩ nhiều đối với những điều đã từng trải nghiệm hoặc đã biết. Do đó, không phải là không cần quy trình tư duy, mà tôi muốn diễn đạt nó như một công cụ giúp suy nghĩ nhanh hơn.
Tiếp theo, với ý "nếu debug thực sự là công việc có thể được thực hiện hoàn toàn bằng trực giác, thì chẳng phải lập luận rằng khi debug hoàn toàn không cần kiểm tra log, dữ liệu hay quản lý cấu hình cũng phải đúng sao?", thì tôi không hề nói rằng có thể thực hiện hoàn toàn bằng trực giác. Ngược lại, tôi đã thêm câu "debug là quá trình tìm ra nguyên nhân của vấn đề dựa trên tình huống và dữ liệu được cung cấp". Tuy nhiên, tôi cho rằng hầu như sẽ không có nhà phát triển nào mỗi lần debug cũng đi qua đầy đủ quy trình suy luận bốn bước mà bài viết đề cập. Nếu có một mức độ kinh nghiệm và kiến thức nhất định, cũng sẽ có những trường hợp họ lược bỏ theo phán đoán của mình. Những thứ như log, dữ liệu mà bạn nhắc tới, theo tôi, nếu đã có kinh nghiệm hoặc kiến thức thì chúng đóng vai trò gợi nhớ lại, còn nếu chưa có kinh nghiệm hoặc kiến thức thì chúng đóng vai trò hỗ trợ suy luận. Vì vậy, ngay cả để có được thứ trực giác mà bài viết nhắc tới, đây cũng là những thông tin quan trọng không thể thiếu.
Tôi nghĩ bản thân từ "trực giác" được dùng trong bài này có thể khá mơ hồ. Có lẽ cách tổ chức bài viết hay phần triển khai ý của tôi chưa đủ tốt để thể hiện suy nghĩ đó. Trước mắt, tôi định sẽ chỉnh sửa những phần còn chưa cụ thể. Tuy nhiên, việc thay thế từ "trực giác" có phải là lựa chọn tốt hay không thì tôi vẫn chưa thể kết luận. Ngay từ khi viết bài, tôi đã xem "trực giác" là từ khóa cốt lõi nên chưa nghĩ ra từ nào khác để thay thế. Nếu bạn có ý kiến hay, tôi sẽ rất cảm kích nếu bạn chia sẻ. :)
Nếu bổ sung ở phần mở đầu phần giải thích nền về việc gỡ lỗi cần cả trực giác lẫn suy luận, và ở phần thân bài thêm cách tìm vấn đề cùng mối liên hệ giữa trực giác/suy luận, thì có thể nâng cao tính hoàn chỉnh của bài viết.
Trước khi thay đổi
Sau khi thay đổi
Mở đầu
Thân bài (quy trình gỡ lỗi)