NỘI DUNG BÀI VIẾT
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 đó.
Lời kết
Năng lực tạo ra bởi tập hợp các thói quen nên việc cải thiện các thói quen sẽ khiến cho năng lực của chúng ta tăng lên. Đó là suy nghĩ của tôi. Tiếp theo là do những rào cản tâm lí nên bản thân việc cải thiện các thói quen cũng thường không mấy dễ dàng. Cải thiện xong rồi, cũng không phải ngay lập tức đạt đến trình độ siêu nhân ngay được.
Nhưng đừng bao giờ nghĩ rằng mình vô dụng. Điều ảnh hưởng nhất đến kết quả cuối cùng của bạn là việc bạn có nghĩ được rằng : con đường học những điều mới là con đường hạnh phúc, hay không.
Tham khảo khóa học lập trình web 6 tháng, đảm bảo 100% công việc đầu ra!
Nguồn: https://topdev.vn/blog/nhung-thoi-quen-xau-kim-ham-su-tien-bo-cua-lap-trinh-vien/
