Quy tắc đầu tiên trong lập trình: Nó luôn là lỗi của bạn
Bạn đã biết cái cảm giác đó. Nó đã xảy ra với tất cả chúng ta tại một thời điểm nào đó: bạn đã nghiền ngẫm đoạn code đó hàng tá lần và vẫn không thể tìm thấy một vấn đề ở trong nó. Nhưng có một vài bug hoặc lỗi mà bạn dường như không thể tống khứ nó đi được. Có lẽ là có một cái gì đó sai sót với chiếc máy tính mà bạn đang lập trình trên đó, hoặc với hệ điều hành mà bạn đang chạy, hoặc là những công cụ và các thư viện mà bạn đang sử dụng. Nhất định là như vậy rồi!
Các lỗi trong phần mềm thì phần lớn là nguyên nhân do code của bạn!
Dù cho bạn có tuyệt vọng đến mức nào đi chăng nữa thì cũng đừng hành động theo cách đó. Hành xử theo cách đó là bạn đang lừa dối mình và tin vào tà thuật của tính toán và lập trình bởi sự trùng hợp ngẫu nhiên. Hay nói ngắn gọn hơn, là một sự mù quáng.
Những bug khó hiểu này cứ lặp đi lặp lại khiến bạn gặp nhiều khó khăn và cảm thấy nản lòng, nhưng đừng cho phép sự tuyệt vọng khiến bạn lạc lối. Yếu tố quan trọng đểtrở thành một lập trình viên khiêm tốn đó là nhận ra rằng bất cứ khi nào có một vấn đề với code mà bạn đã viết, thì nó luôn luôn là lỗi của bạn. Điều này chính là phần tổng kết trong cuốn sách nổi tiếng The Pragmatic Programmer có tên là “Select Isn’t Broken”:
Trong hầu hết các dự án, phần code mà bạn đang debugging có thể là một sự pha trộn của code và ứng dụng được viết bởi bạn và những người khác trong nhóm dự án của bạn, các sản phẩm của hãng thứ ba (cơ sở dữ liệu, kết nối, các thư viện đồ họa, các giao tiếp đặc biệt hoặc các thuật toán, và nhiều thứ khác) và môi trường nền tảng (hệ điều hành, các thư viện hệ thống, và các trình biên dịch).
Có thể có một bug tồn tại trong hệ điều hành, trong trình biên dịch, hoặc một sản phẩm của hãng thứ ba– nhưng bạn đừng nghĩ đến hướng này đầu tiên. Phần nhiều là bug đó tồn tại trong cái ứng dụng mà đang trong quá trình phát triển. Việc giả sử rằng code của ứng dụng đó bị sai trong quá trình triệu gọi một thư viện thì có ích lợi nhiều hơn là cho rằng chính bản thân thư viện đó bị lỗi. Thậm chí nếu vấn đề đó nằm trong một sản phẩm của hãng thứ ba đi nữa, thì bạn sẽ vẫn phải loại trừ trong code của mình trước khi thông báo bug cho hãng đó.
Chúng tôi từng làm việc trên một dự án mà một kỹ sư kỳ cựu đã tin chắc rằng một lời triệu gọi hệ thống bị lỗi là do nguyên nhân của hệ điều hành Solaris. Không có điều gì có thể thuyết phục và không có logic nào có thể thay đổi được suy nghĩ của anh ta (thực tế là tất cả những ứng dụng networking khác cùng thể loại đang hoạt động rất tốt). Anh ta đã dành nhiều tuần liền để viết một giải pháp khắc phục, và vì một số lý do kỳ quặc, đã dường như không thể khắc phục được vấn đề đó. Cuối cùng anh ta bắt buộc phải ngồi xuống và đọc kỹ tài liệu về phần triệu gọi đó, và anh ta khám phá ra vấn đề rồi sửa nó chỉ trong ít phút. Bây giờ chúng tôi thường sử dụng cụm từ “select is broken” như là một lời nhắc nhở nhẹ nhàng bất cứ khi nào mà một thành viên trong nhóm chúng tôi bắt đầu đổ lỗi cho hệ thống là nguyên nhân chính gây ra lỗi.
Mặt trái của việc sở hữu code đó là bạn phải chịu trách nhiệm cho phần code đó. Cho dù vấn đề trong phần mềm của bạn là gì đi chăng nữa– thậm chí có vẻ như không phải do code của bạn– thì nên luôn luôn giả sử rằng vấn đề đó nằm trong code của bạnvà hành động theo hướng đó. Nếu bạn muốn trở thành chủ thể phần mềm của mình, thì hãy chịu trách nhiệm đầy đủ cho tất cả những sự hỏng hóc của nó. Thậm chí dù về mặt kỹ thuật mà nói thì bạn không phải làm như vậy. Nhưng đó là cách bạn sẽ nhận được sự tôn trọng và tin cậy. Bạn chắc chắn sẽ không nhận được sự tôn trọng hoặc tin cậy bằng cách không ngừng đổ lỗi lên người khác, lên những công ty khác, hoặc những tài nguyên khác.
Theo thống kê cho thấy một kết quả khó tin đó là hiếm khi có bất kỳ bug hoặc lỗi trong phần mềm của bạn mà không phải là lỗi của chính bản thân bạn. Trong cuốn sách kinh điển Code Complete của tác giả nổi tiếng Steve McConnell đã trích dẫn hai nghiên cứu để chứng minh điều đó:
Có hai nghiên cứu được tiến hành [vào năm 1973 và 1984] đã tìm thấy rằng, trong tổng số các lỗi được báo cáo, thì xấp xỉ 95% là nguyên nhân bởi các lập trình viên, 2% là bởi các hệ thống phần mềm (trình biên dịch và hệ điều hành), 2% là bởi một số phần mềm khác, và 1% là bởi phần cứng. Các hệ thống phần mềm và các công cụ phát triển ngày nay được sử dụng bởi nhiều người hơn so với những năm 1970s và 1980s, vì vậy theo suy đoán của tôi là, ngày nay, thậm chí tỷ lệ % lỗi do nguyên nhân các lập trình viên còn cao hơn.
Bất cứ vấn đề nào xảy ra với phần mềm của bạn, thì bạn hãy nhận lấy trách nhiệm. Bắt đầu rà soát trong code của bạn, và điều tra xa hơn và xa hơn ra ngoài cho tới khi bạn có một bằng chứng dứt khoát của nơi mà vấn đề đó trú ngụ. Nếu vấn đề đó nằm trong một phần code khác mà bạn không thể kiểm soát, thì bạn sẽ không chỉ học được những kỹ năng gỡ rối và chẩn đoán thiết yếu, mà bạn cũng sẽ có một dấu vết chứng cứ để làm cơ sở cho tuyên bố của mình. Điều này chắc chắn là phải làm nhiều việc hơn so với hành động chỉ nhún vai rồi trỏ ngón tay của bạn để đổ lỗi vào hệ điều hành, vào những công cụ, hoặc framework– nhưng nó cũng đem lại một cảm giác tin cậy và tôn trọng mà bạn sẽ không thể nào có được thông qua việc trỏ tay đổ lỗi và tìm cách thoái thác.
Nếu bạn thực sự được truyền cảm hứng để trở thành một lập trình viên khiêm tốn, thì bạn đừng bao giờ ngần ngại mà nói rằng “hey, đây là lỗi của tôi– và tôi sẽ tìm cách khắc phục nó.”
ITZone via vinacode