trieu.dev.da
Nguyễn Thanh Triều
Không đọc error message, không đọc log
Error message của ngôn ngữ lập trình, hay error message của thư viện đều có nhiệm vụ là chỉ ra chỗ sai bằng văn bản con người có thể hiểu được, viết bởi con người. Tuy nhiên, những lập trình viên tiến bộ chậm thường không đọc những cái đó. Họ chỉ ý thức được là có lỗi xảy ra.
Nếu là code trên IDE thì có thể kích chuột để jump ngay đến câu lệnh lỗi. Nhưng nếu làm trên vim hoặc Web browser thì việc đọc hiểu log message, và jump đến câu lệnh lỗi là nhiệm vụ của người lập trình.
Không đọc, cũng không jump đến câu lệnh lỗi nên màn hình error thường bị switch đi trong tích tắc. Trong khi pair programming với vài người, họ switch màn hình nhanh đến nỗi tôi còn tưởng họ đang thử độ phản ứng của mắt với vật thể chuyển động.
Kết quả là họ ngồi nhìn chằm chằm vào code họ vừa viết, tìm xem có lỗi chính tả, lỗi font nào không bằng cách ngó đi ngó lại method name.
Vấn đề là error message vừa nãy đâu có nói là method name có lỗi, hoặc không tồn tại.
Một khi không đọc error message thì phạm vi có thể phát sinh lỗi là vô hạn. Tuy nhiên, họ chỉ luôn nghĩ được là mình “viết sai một cái gì đó”.
Cách sửa
Tất nhiên là đọc error message và tìm hiểu ý nghĩa của từng message một.
Thêm vào đó, tôi giúp họ lí giải mối liên hệ giữa error message và môi trường. Đồng thời, hướng dẫn họ tạo ra những đoạn code nhỏ để tái hiện các lỗi đó (snippet) có thể dùng cho sau này và dự trù các case tương tự có thể xảy ra.
Vấn đề tâm lí
Có thanh niên nói “Em sợ tiếng Anh lắm, nhìn cứ như mật mã”. Có điều, ngữ pháp của các error message chỉ dừng ở mức học sinh cấp Hai, mà tôi biết là cậu ta thừa sức hiểu.
Cũng phải công nhận một thực tế là muốn hiểu những lỗi liên quan đến ngôn ngữ lập trình và framework thì phải hiểu cấu trúc và từ ngữ chuyên ngành của chúng. Điều này khó.
Nhưng như vậy không có nghĩa là ngôn ngữ hoặc framework đó “không thân thiện” mà vì bản thân error message không phải sinh ra chỉ để hiển thị những lỗi liên quan đến code người lập trình viết.
Vì vậy ta cần theo sát cả framework, cả ngôn ngữ lập trình, và cả code. Có như vậy ta mới có thể móc nối error message và vấn đề cần giải quyết với nhau.
Để có thể tự mình làm như vậy, hàng ngày cần tự tạo thói quen tìm hiểu những thứ đó cho mình. Nếu không cho dù đến bao giờ chăng nữa, error message cũng vẫn mãi chỉ là những “mật mã” mà thôi.
Không biết cách đào sâu vấn đề
Có lỗi xảy ra, nghĩa là chúng ta có thể tìm ra manh mối để giải quyết vấn đề bằng cách xem xét phần code bị báo lỗi.
Ở đó có lỗi, nghĩa là ít nhất thì code đã chạy được cho đến đó.
Hơn thế nữa, nguyên nhân lỗi phát sinh rất có thể là do ảnh hưởng của những gì mà chúng ta đã nhập vào.
Chẳng hạn, bằng cách dùng printf để debug, chúng ta có thể biết nhập cái gì vào module, biến đổi nó ra sao thì sẽ sinh ra lỗi. Thông qua việc đó, chúng ta sẽ hiểu khái quát vấn đề, sau đó tuần tự thử các bước chạy của chương trình là có thể chỉ ra được cụ thể phần nào bị lỗi.
Tuy nhiên, người không biết cách đào sâu vấn đề thường cho chương trình chạy với tâm lí là sẽ chạy ngon và check code với tâm lí “đáng ra nó phải chạy ngon”. Họ thường không quan tâm đến thứ tự các bước chạy của chương trình, cách làm việc của họ chẳng khác nào lần mò trong đám mây.
Trong một vài trường hợp, họ sẽ mãi “ngẩn ngơ” vì không hiểu sai từ đâu. Họ không có trong tay một chiến thuật để tìm ra chỗ sai nên sẽ nhanh chóng rơi vào trạng thái người ta vẫn gọi là “quay cuồng”.
Cách sửa
Sau khi xảy ra lỗi, trước khi họ làm một động tác gì tôi đều yêu cầu họ trả lời câu hỏi này trước “Bây giờ chúng ta cần làm gì?”. Cụ thể, tôi muốn họ nêu ra phương pháp tìm ra chỗ sai. Tôi giúp họ xây dựng phương pháp đó bằng cách hỏi những câu như “Code chạy ngon đến đoạn nào?”. Sau khi tìm ra một manh mối gì đó, tôi lại hỏi “Thông tin này có ý nghĩa gì?”, “Có cần thay đổi phương pháp không?”.
Tôi muốn họ ý thức được là mình cần đào sâu có mục tiêu đàng hoàng, chứ không phải là lần mò trong đám mây.
Vấn đề tâm lí
Đối với một chương trình, việc xảy ra lỗi là một minh chứng cho việc “đã gần hoàn thiện”. Tại sao? Vì nó thường chỉ cho ta sáng tỏ một điều mà trước đây ta không quan tâm, chỉ cho ta biết giả thiết mà ta đã tạo ra là sai, và chỉ cho ta hành động tiếp theo mà ta phải làm là sửa nó. Ta đã có định hướng.
Tuy nhiên, đối với những progammer không giỏi đào sâu vấn đề thì thường có xu hướng bị “ngây người” vì họ luôn nghĩ rằng “Đáng ra phải chạy ngon rồi chứ nhỉ?”. Và sau đó họ lại nghĩ “Toi rồi, sai hết rồi”.
Có thể nói rằng họ không bao giờ test những cái mà chắc sẽ thất bại, trong khi giá trị cao nhất của việc test là sau khi thất bại, nó sẽ cho ta một thông tin hữu ích nào đó.
Tôi bảo họ chạy thử thì họ thường nói “Lỗi là cái chắc” và không làm. Còn khi miễn cưỡng làm rồi chương trình không chạy thì họ bảo “Đấy, thấy chưa?”.
Thực tế là lỗi ở môi trường chạy thật thì không được phép, nhưng ở môi trường test thì sẽ chẳng có ai phàn nàn gì cả, thậm chí còn có ích.
Tôi nghĩ họ cần được tự mình trải nghiệm và lí giải những điều đó.
Thói quen tốt
Dựa vào những thói quen xấu đã nói ở trên, chúng ta có thể biết được đâu là thói quen tốt.
Ngoài ra, còn vài thói quen mà tôi nghĩ là tốt như :
Thói quen tốt thường được hỗ trợ bởi công cụ tốt. Chẳng hạn mỗi khi học ngôn ngữ mới, tôi đều tìm kiếm code formatter của ngôn ngữ đó.
Ngoài ra, tôi có coding style của mình - không muốn ấn quá nhiều phím, nên tôi chọn IDE có chức năng tự động nhập space cho tôi.
Boy scout policy
Có một tổ chức gọi là boy scout có phương châm là : nhặt hết rác trên các đoạn đường mình đi qua. Cũng như vậy, người lập trình cần có phương châm sửa hết lỗi của những code liên quan đến phần mình làm. Dĩ nhiên không đọc cẩn thận thì sẽ không sửa được, nhưng dù không sửa thì đọc code thôi cũng là có ích rồi.
Làm như vậy thì tự nhiên sẽ ngày càng hiểu sâu về code hơn, và code tổng thể sẽ đẹp hơn.
Học vài ngôn ngữ
Nhiều khi vấn đề ở ngôn ngữ này ta có thể lí giải được trong khi học ngôn ngữ khác. Và nhiều khi, một khái niệm nghe có vẻ lạ, thực ra chỉ là đem từ ngôn ngữ khác vào.
Thế nên, việc học nhiều ngôn ngữ sẽ giúp ta lập trình mau thuần thục hơn.
Học kiến thức một cách tổng thể
Như bài trước tôi đã viết, kiến thức về background, về lịch sử ngôn ngữ, và vài ba bài tập ta đọc ở đâu đó sẽ khiến cho chất lượng code của ta tăng lên.
Nếu mỗi ngày ta không gặm nhấm một ít kiến thức, không có cách hiểu về cú pháp, về sample của riêng ta thì kiến thức sẽ không còn là kiến thức mà chỉ dừng ở mức mẹo vặt vì ta không biết ứng dụng chúng sang những trường hợp khác. Cứ thế, ta sẽ chỉ mãi mãi chạy theo những mẹo vặt để giải quyết vấn đề mà thôi.
Error message của ngôn ngữ lập trình, hay error message của thư viện đều có nhiệm vụ là chỉ ra chỗ sai bằng văn bản con người có thể hiểu được, viết bởi con người. Tuy nhiên, những lập trình viên tiến bộ chậm thường không đọc những cái đó. Họ chỉ ý thức được là có lỗi xảy ra.
Nếu là code trên IDE thì có thể kích chuột để jump ngay đến câu lệnh lỗi. Nhưng nếu làm trên vim hoặc Web browser thì việc đọc hiểu log message, và jump đến câu lệnh lỗi là nhiệm vụ của người lập trình.
Không đọc, cũng không jump đến câu lệnh lỗi nên màn hình error thường bị switch đi trong tích tắc. Trong khi pair programming với vài người, họ switch màn hình nhanh đến nỗi tôi còn tưởng họ đang thử độ phản ứng của mắt với vật thể chuyển động.
Kết quả là họ ngồi nhìn chằm chằm vào code họ vừa viết, tìm xem có lỗi chính tả, lỗi font nào không bằng cách ngó đi ngó lại method name.
Vấn đề là error message vừa nãy đâu có nói là method name có lỗi, hoặc không tồn tại.
Một khi không đọc error message thì phạm vi có thể phát sinh lỗi là vô hạn. Tuy nhiên, họ chỉ luôn nghĩ được là mình “viết sai một cái gì đó”.
Cách sửa
Tất nhiên là đọc error message và tìm hiểu ý nghĩa của từng message một.
Thêm vào đó, tôi giúp họ lí giải mối liên hệ giữa error message và môi trường. Đồng thời, hướng dẫn họ tạo ra những đoạn code nhỏ để tái hiện các lỗi đó (snippet) có thể dùng cho sau này và dự trù các case tương tự có thể xảy ra.
Vấn đề tâm lí
Có thanh niên nói “Em sợ tiếng Anh lắm, nhìn cứ như mật mã”. Có điều, ngữ pháp của các error message chỉ dừng ở mức học sinh cấp Hai, mà tôi biết là cậu ta thừa sức hiểu.
Cũng phải công nhận một thực tế là muốn hiểu những lỗi liên quan đến ngôn ngữ lập trình và framework thì phải hiểu cấu trúc và từ ngữ chuyên ngành của chúng. Điều này khó.
Nhưng như vậy không có nghĩa là ngôn ngữ hoặc framework đó “không thân thiện” mà vì bản thân error message không phải sinh ra chỉ để hiển thị những lỗi liên quan đến code người lập trình viết.
Vì vậy ta cần theo sát cả framework, cả ngôn ngữ lập trình, và cả code. Có như vậy ta mới có thể móc nối error message và vấn đề cần giải quyết với nhau.
Để có thể tự mình làm như vậy, hàng ngày cần tự tạo thói quen tìm hiểu những thứ đó cho mình. Nếu không cho dù đến bao giờ chăng nữa, error message cũng vẫn mãi chỉ là những “mật mã” mà thôi.
Không biết cách đào sâu vấn đề
Có lỗi xảy ra, nghĩa là chúng ta có thể tìm ra manh mối để giải quyết vấn đề bằng cách xem xét phần code bị báo lỗi.
Ở đó có lỗi, nghĩa là ít nhất thì code đã chạy được cho đến đó.
Hơn thế nữa, nguyên nhân lỗi phát sinh rất có thể là do ảnh hưởng của những gì mà chúng ta đã nhập vào.
Chẳng hạn, bằng cách dùng printf để debug, chúng ta có thể biết nhập cái gì vào module, biến đổi nó ra sao thì sẽ sinh ra lỗi. Thông qua việc đó, chúng ta sẽ hiểu khái quát vấn đề, sau đó tuần tự thử các bước chạy của chương trình là có thể chỉ ra được cụ thể phần nào bị lỗi.
Tuy nhiên, người không biết cách đào sâu vấn đề thường cho chương trình chạy với tâm lí là sẽ chạy ngon và check code với tâm lí “đáng ra nó phải chạy ngon”. Họ thường không quan tâm đến thứ tự các bước chạy của chương trình, cách làm việc của họ chẳng khác nào lần mò trong đám mây.
Trong một vài trường hợp, họ sẽ mãi “ngẩn ngơ” vì không hiểu sai từ đâu. Họ không có trong tay một chiến thuật để tìm ra chỗ sai nên sẽ nhanh chóng rơi vào trạng thái người ta vẫn gọi là “quay cuồng”.
Cách sửa
Sau khi xảy ra lỗi, trước khi họ làm một động tác gì tôi đều yêu cầu họ trả lời câu hỏi này trước “Bây giờ chúng ta cần làm gì?”. Cụ thể, tôi muốn họ nêu ra phương pháp tìm ra chỗ sai. Tôi giúp họ xây dựng phương pháp đó bằng cách hỏi những câu như “Code chạy ngon đến đoạn nào?”. Sau khi tìm ra một manh mối gì đó, tôi lại hỏi “Thông tin này có ý nghĩa gì?”, “Có cần thay đổi phương pháp không?”.
Tôi muốn họ ý thức được là mình cần đào sâu có mục tiêu đàng hoàng, chứ không phải là lần mò trong đám mây.
Vấn đề tâm lí
Đối với một chương trình, việc xảy ra lỗi là một minh chứng cho việc “đã gần hoàn thiện”. Tại sao? Vì nó thường chỉ cho ta sáng tỏ một điều mà trước đây ta không quan tâm, chỉ cho ta biết giả thiết mà ta đã tạo ra là sai, và chỉ cho ta hành động tiếp theo mà ta phải làm là sửa nó. Ta đã có định hướng.
Tuy nhiên, đối với những progammer không giỏi đào sâu vấn đề thì thường có xu hướng bị “ngây người” vì họ luôn nghĩ rằng “Đáng ra phải chạy ngon rồi chứ nhỉ?”. Và sau đó họ lại nghĩ “Toi rồi, sai hết rồi”.
Có thể nói rằng họ không bao giờ test những cái mà chắc sẽ thất bại, trong khi giá trị cao nhất của việc test là sau khi thất bại, nó sẽ cho ta một thông tin hữu ích nào đó.
Tôi bảo họ chạy thử thì họ thường nói “Lỗi là cái chắc” và không làm. Còn khi miễn cưỡng làm rồi chương trình không chạy thì họ bảo “Đấy, thấy chưa?”.
Thực tế là lỗi ở môi trường chạy thật thì không được phép, nhưng ở môi trường test thì sẽ chẳng có ai phàn nàn gì cả, thậm chí còn có ích.
Tôi nghĩ họ cần được tự mình trải nghiệm và lí giải những điều đó.
Thói quen tốt
Dựa vào những thói quen xấu đã nói ở trên, chúng ta có thể biết được đâu là thói quen tốt.
- Đầu tư thời gian để đọc code và hiểu code.
- Luôn có xu hướng dùng kiến thức để đơn giản hóa vấn đề trước mắt
- Không sợ lỗi, luôn dùng test code để tìm kiếm thông tin, manh mối
- Luôn hành động với mục đích rõ ràng để từng bước một giải quyết vấn đề
Ngoài ra, còn vài thói quen mà tôi nghĩ là tốt như :
- Cải tiến công cụ và tự động các hóa quy trình
- Boy scout policy
- Học vài ngôn ngữ
- Học kiến thức một cách tổng thể
Thói quen tốt thường được hỗ trợ bởi công cụ tốt. Chẳng hạn mỗi khi học ngôn ngữ mới, tôi đều tìm kiếm code formatter của ngôn ngữ đó.
Ngoài ra, tôi có coding style của mình - không muốn ấn quá nhiều phím, nên tôi chọn IDE có chức năng tự động nhập space cho tôi.
Boy scout policy
Có một tổ chức gọi là boy scout có phương châm là : nhặt hết rác trên các đoạn đường mình đi qua. Cũng như vậy, người lập trình cần có phương châm sửa hết lỗi của những code liên quan đến phần mình làm. Dĩ nhiên không đọc cẩn thận thì sẽ không sửa được, nhưng dù không sửa thì đọc code thôi cũng là có ích rồi.
Làm như vậy thì tự nhiên sẽ ngày càng hiểu sâu về code hơn, và code tổng thể sẽ đẹp hơn.
Học vài ngôn ngữ
Nhiều khi vấn đề ở ngôn ngữ này ta có thể lí giải được trong khi học ngôn ngữ khác. Và nhiều khi, một khái niệm nghe có vẻ lạ, thực ra chỉ là đem từ ngôn ngữ khác vào.
Thế nên, việc học nhiều ngôn ngữ sẽ giúp ta lập trình mau thuần thục hơn.
Học kiến thức một cách tổng thể
Như bài trước tôi đã viết, kiến thức về background, về lịch sử ngôn ngữ, và vài ba bài tập ta đọc ở đâu đó sẽ khiến cho chất lượng code của ta tăng lên.
Nếu mỗi ngày ta không gặm nhấm một ít kiến thức, không có cách hiểu về cú pháp, về sample của riêng ta thì kiến thức sẽ không còn là kiến thức mà chỉ dừng ở mức mẹo vặt vì ta không biết ứng dụng chúng sang những trường hợp khác. Cứ thế, ta sẽ chỉ mãi mãi chạy theo những mẹo vặt để giải quyết vấn đề mà thôi.