Từ chuyện trần nhà ngấm nước và hai cái xô

Mọi chuyện bắt đầu từ … hai cái xô hứng nước trong ga tàu điện ngầm.

Chuyện là, gần văn phòng mình có một quán Việt Nam khá ngon. Mỗi lần đi ăn, mình và mấy ông đồng nghiệp lại phải đi bộ ngang qua ga tàu điện ngầm.

Một hôm nọ, mình thấy có người để 2 cái xô ngay trạm tàu điện, giữa con đường đông người qua lại. Đi ngang qua thì thấy nước rõ tóc tóc từ trên nóc xuống.

Chuyện nếu chỉ có vậy thì không cũng chẳng có gì để nói. Xây dựng thì bị thấm ướt, hư hỏng là chuyện thường, hư thì sửa thôi!

Thời gian thấm thoắt thoi đưa, thu qua đông lại. Đồng nghiệp đi ăn với mình, ông thì đã chuyển công ty, ông thì vợ đẻ; thế nhưng mỗi lần đi ngang qua ga tàu, hai cái xô hứng nước và hai tấm biển vẫn còn đó, đập thẳng vào mắt mình!

Tại sao?? Tại sao ở một đất nước phát triển như Singapore, một nơi dân tình siêng năng cày cuốc từ 9h sáng tới 7-8h tối mới về tới nhà; mà có thể để 2 cái xô chình ình như vậy không sửa hơn cả năm trời??

Hãy cùng mình tìm câu trả lời qua bài viết nhé!

Đến chuyện anh kĩ sư phần mềm đi fix bug

Ủa, đang nói chuyện cái xô sao bỗng dưng nói chuyện phần mềm rồi? Cua khét lẹt vậy, hai thứ đó liên quan gì với nhau đâu??

Ấy vậy mà có đấy! Nhìn ga tàu điện ngầm, nước nhỏ tong tong, có 2 cái xô hứng nước, mình bỗng dưng nhớ đến những con bug và “hot fix” của dân lập trình tụi mình khi làm ra phần mềm.

Với một số lỗi phức tạp, ta thường sẽ có 2 cách fix:

• Cách thứ nhất là tìm tận gốc vấn đề rồi sửa, giống như chữa bệnh tận gốc. Cách này đôi khi sẽ khó, lâu hơn
• Cách thứ hai là sửa ở tầng ngọn phía người dùng; giống như đau đầu chỉ uống thuốc giảm đau nhưng không chữa. Cách này thường sẽ dễ và nhanh hơn

Ví dụ, ta lấy dự liệu từ stream của back-end để thực hiện tính toán. Lâu lâu dữ liệu bị sai, hiện số âm hoặc có vấn đề.

• Cách xử lý đúng đắn sẽ là kiểm tra lỗi và sửa trực tiếp bên back-end để có dữ liệu đúng.
• Tuy nhiên, ta có thể “hot fix” bằng cách chỉ sửa front-end, check nếu dữ liệu sai thì bỏ qua, dữ liệu đúng thì mới tính.

Hoặc ví dụ bạn làm front-end, lỡ code JavaScript sida, dùng framework lô nên web của chúng ta bị memory leak ở phía front-end, dùng app lâu sẽ bị crash hoặc làm trình duyệt bị đơ.

• Cách xử lý đúng đắn sẽ là truy tìm nguyên nhân memory leak và sửa, test để đảm báo nó không hiện lại
• Cách “hotfix” là set cho browser tự động refresh sau … 5 hoặc 10 phút. Page được tải lại từ đầu, sắp memory leak thì refresh rồi, lo gì nữa

Thông thường, người ta thường chọn cách fix từ gốc. Tuy nhiên, vì nhiều lý do như thời gian gấp gấp, bug ít gặp, developer lười, đôi khi ta cũng chọn cách “hot fix” trước, sau đó quay lại fix bug “đàng hoàng” sau!

Tại sao hai cái xô “trường tồn” với thời gian?

Quay lại chuyện 2 cái xô và câu hỏi đầu tiên ở đầu bài nha!

Có thể ban đầu mấy anh kĩ sư định dùng 2 cái xô để “hot fix”, sau đó sẽ sửa trần nhà lại sau. Tuy nhiên, do bị task dí đồn dập, anh engineer phải OT sml nên suýt quên luôn 2 cái xô.

Thế rồi, thời gian đằng đẳng trôi. Đến lúc and engineer có thời gian, nhìn lại 2 cái xô nhếch nhác, quyết định xắn tay áo lên fix thì lại … lười. Anh nghĩ rằng: Kệ, để vậy cũng được rồi, đâu ảnh hưởng tới tàu chạy hay mấy người quay lại đâu! Nhìn hơi nhếch nhác tí thôi!

Đấy, đó là lý do 2 cái xô tồn tại gần như “vĩnh cửu” tại nhà ga nọ.

Kết – về những con bug không bao giờ được fix

Trong ngành lập trình cũng vậy, bug là chuyện không thể tránh khỏi. Tuy nhiên, không phải bug nào cũng được sửa đàng hoàng.

Có thể ta chỉ sửa một cách tạm bợ, cho nó chạy được. Sau khi thấy nó chạy ổn, ta bỏ qua không để ý đến nữa luôn. Thoạt nhìn thì không có vấn đề gì, nhưng biết đâu lại có tác dụng phụ về sau thì sao!

Giống như 2 cái xô vậy, dù nó không gây ảnh hưởng đến việc đi làm, không làm nước tràn hay làm ai trượt ngã; nhưng nó sẽ gây mất hình ảnh của ga tàu, của đất nước, gây khó khăn cho người khiếm thị.

Vì thế, khi cần làm một chức năng, có bug cần fix, hãy dùng hết khả năng để giải quyết vấn đề một cách rốt ráo. Nếu được, gặp bug thì hãy fix từ gốc chứ đừng “hotfix” nhé.

Có đôi khi, những hotfix “tạm thời” sẽ trở thành vĩnh viễn; trở thành technical debt cản trở dự án trong tương lai đấy.

Nói nhỏ nè. bạn hãy xem lại code và bug trong các ứng dụng mình viết, trong sản phẩm mình đang làm xem. Có thể có không chỉ có một, mà đến tận vài cái xô nằm đấy, không bao giờ được sửa đấy!

P/S: Để theo dõi bài viết trên Tôi Đi Code Dạo, nhớ Subscribe Chat Bot của tụi mình nha. Bot của Code Dạo sẽ gửi bạn những bài viết cực kì hay ho về kĩ năng mềm và cứng, kinh nghiệm trong ngành vào thứ 4 hàng tuần nhé!