Hãy sửa bất cứ bug nào sớm nhất có thể khi nó được phát hiện ra
Nếu bạn là lập trình viên, trong quá trình làm việc bạn phát hiện ra một bug hoặc trông thấy một đoạn code sai logic, có thể không ảnh hưởng ngay tới công việc của bạn, cách xử lý của bạn là gì ? Nếu ngay lập tức bạn sửa nó, thì xin chúc mừng, bạn là một lập trình viên tuyệt vời. Nếu bạn đã không sửa nó, hãy đọc bài dưới đây.
Hầu hết chúng ta biết câu nói “Việc hôm nay chớ để ngày mai”, câu chuyện như sau :
Một người nhà quê đi thăm vườn cam thấy nhiều gốc có sâu, không bắt sâu ngay tự hẹn hôm sau sẽ làm công việc đó. Hôm sau anh ta đau, phải nghỉ vài bữa, đến lúc khỏi thì gặp đám giỗ, xong đám giỗ thì có cơn giông, rồi tới công việc gấp khác, nên quên hẳn công việc bắt sâu, nửa tháng sau mới quay trở lại vườn cam thì cây nào cây nấy đã héo rũ cả rồi.
Mọi chuyện sẽ trở nên cực kì tồi tệ khi chúng ta phát hiện ra một lỗi lầm nhỏ mà không sửa chữa.
Thuyết Cửa Sổ Vỡ
Một câu chuyện khác, cũng nhắc tới việc trì hoãn mọi việc, và khiến chúng trở nên tồi tệ hơn, đó là Thuyết Cửa Sổ Vỡ (Broken Window Theory), lý thuyết như sau :
Trong những thành phố, một số tòa nhà thì rất sạch và đẹp, trong khi một số khác thì cũ kỹ và mục nát. Tại sao vậy? Các nhà nghiên cứu trong lĩnh vực tội phạm và sự đổ nát của thành phố đã khám phá ra một số nguyên nhân gây nên điều này, một trong số nguyên nhân khiến một tòa nhà sạch sẽ, nguyên vẹn và có người sống trở thành một tòa nhà bị bỏ hoang tàn tạ rất nhanh: đó là do một ô cửa sổ bị vỡ.
Một ô cửa sổ vỡ, bị để mặc không được sửa chữa trong một khoảng thời gian dài, tạo ra cho những cư dân trong tòa nhà đó một cảm giác của sự bỏ rơi — một cảm giác mà sức mạnh của nó ngày càng tăng lên dẫn đến người ta không thèm quan tâm về ngôi nhà đó nữa. Vì vậy sẽ có những ô cửa sổ khác bị vỡ. Mọi người bắt đầu vứt rác bừa bãi. Mấy tay trẻ trâu sẽ đến vẽ bậy các hình graffiti lên tường. Những sự phá hủy nghiêm trọng về cấu trúc bắt đầu xảy ra. Chỉ trong một thời gian ngắn, tòa nhà đó đã trở nên bị hư hại vượt quá cả mong muốn sửa chữa của người chủ của nó. Và cái cảm giác bỏ rơi dần trở thành hiện thực.
Thuyết “Ô Cửa Sổ Vỡ” (Broken Window Theory) này đã truyền cảm hứng cho các sở cảnh sát ở thành phố New York và nhiều thành phố lớn khác tập trung xử lý những vấn đề nhỏ trong trật tự để không xảy ra những vấn đề lớn. Và nó đã có hiệu quả: việc tập trung vào giải quyết những vấn đề nhỏ như cửa sổ vỡ, hình vẽ bậy bạ trên tường, và những sự vi phạm nhỏ nhặt khác đã làm giảm đáng kể số lượng các vụ phạm tội nghiêm trọng như giết người.
Đừng để “những ô cửa sổ vỡ” (thiết kế tồi, những quyết định sai lầm, hoặc code viết dở) mà không được sửa chữa. Hãy sửa bất cứ bug nào sớm nhất có thể khi nó được phát hiện ra. Nếu bạn không có đủ thời gian để có thể sửa chữa nó một cách đúng đắn, thì bạn hãy đánh dấu nó lại. Có lẽ bạn có thể comment cái đoạn code bị lỗi đó, hoặc hiển thị một thông điệp là “Not Implemented”, hoặc thay thế bằng một dữ liệu giả vào đó. Hãy làm một số hành động để ngăn ngừa nó bị phá hủy nhiều hơn và chỉ ra rằng bạn đang kiểm soát được tình hình.
Tôi đã từng nhìn thấy những hệ thống sạch sẽ, nhiều chức năng đã bị hư hỏng một cách nhanh chóng một khi các ô cửa sổ bắt đầu vỡ. Có những yếu tố khác có thể đóng góp vào sự hư hỏng của phần mềm, và chúng ta sẽ bàn về các yếu tố đó trong một phần khác, nhưng việc bỏ bê sẽ làm tăng tốc độ mục nát của phần mềm hơn bất kỳ những nhân tố nào khác.
Bạn có thể nghĩ rằng không một ai lại có đủ thời gian để cứ đi mà dọn dẹp tất cả những mảnh vỡ của một dự án. Nếu bạn còn tiếp tục nghĩ như vậy, thì tốt hơn bạn nên lên kế hoạch bỏ luôn nó, hoặc chuyển sang một vùng khác. Đừng để cho điều này xảy ra.
Tất cả những điều trên không chỉ đúng với nghành lập trình mà còn đúng với mọi lĩnh vực trong cuộc sống của bạn. Nếu nhận thấy vấn đề, hãy khắc phục nó ngay lập tức.
Nếu công việc trong ngày của bạn có một nhiệm vụ là nuốt một con cóc thối, thì ngay đầu ngày bạn hãy nhắm mắt nhắm mũi nuốt luôn nó đi, để thời gian còn lại mà làm việc khác nữa full-width
Đăng nhận xét