kiến thức 4 cấp độ lỗi của code và một số thủ thuật sửa lỗi debug

tu_do_quan_diem đã nói:

Cấp độ 4 của lỗi code là về code dependency và team structure. Viết phần này hơi khó nên tôi tóm tắt một tình huống bug như sau:

đội A sở hữu code A.

đội B thấy code đội A hay ho, sử dụng lại code của đội A bằng cách gọi trực tiếp code hoặc service của đội A (without A's consent).

Đội A có định hướng mới về sản phẩm, thay đổi code của họ --> break software của đội B.

Đội B bực mình đến gặp đội A, bảo "sao anh thay đổi code mà ko báo cho tôi?"

Đội A: "what the actual f*ck???"


Một ví dụ cơ bản trong thực tế: đội A và đội B là 2 đội trong một tập đoàn lớn. Đội A làm sản phẩm về web app, một trong các tính năng của web app của họ là in ra thời gian trong ngày (tuỳ thuộc vào user đang ở múi giờ địa lý nào).

Đội B làm một cái app khác về quản lí lịch hẹn. Họ ko biết cách lấy thời gian trong ngày theo vị trí địa lý sao cho đúng, nên make API call sang app của đội A để giải quyết phần lấy thời gian của user trong ngày.

Đội A đổi hướng sản phẩm, chuyển app của họ sang luôn hiển thị thời gian từ địa điểm ban đầu của người dùng --> Đội B một ngày kia phát hiện ra họ bị lỗi tính thời gian, người dùng đang đi du lịch ở Dubai mà múi giờ trả về là giờ Hà Nội.

Nhấp để mở rộng...

tu_do_quan_diem đã nói:

Tiếp cấp độ lỗi này.

Cấp độ 3:

API chạy cho ra kết quả đúng, nhưng có những hệ quả không lường (unexpected side effects).

Code kiểu này rất nguy hiểm vì API là hợp đồng duy nhất có giá trị bền vững đối với các bên gọi API. Phần implementation của API có thể thay đổi bất cứ lúc nào.

Một trong những bug nổi tiếng nhất về cái này là bug memory của Microsoft.

Đại khái Windows có một hàm là hàm trả lại bộ nhớ (free memory). Trước windows XP thì hàm này khi bạn gọi ko làm gì về phần bộ nhớ đã có, nên phần gọi API vẫn có thể dùng bộ nhớ đã xoá.

Đến khi windows cập nhật lên bản XP, họ đổi implementation của hàm này khiến cho bộ nhớ đã bị xoá ko còn sử dụng lại được gây ra lỗi trên game Sim City. Kết quả là đội windows phải viết lại hàm free bộ nhớ của họ kiểu như sau:
If play_sim_city():
use old memory deallocator
else:
use newmemory deallocator

Vậy lỗi ở đây là gì?
1) Các nhà sản xuất game sim City phá vỡ contract của memory deallocator, vẫn sử dụng memory sau khi xoá
2) Các lập trình viên microsoft chủ quan trong chuyện defend API của họ. Ko xoá đi phần bộ nhớ cũ trong implementation đầu tiên.

Một điểm quan trọng cần chú ý là nếu bạn là platform hoặc library developer, bạn ko thể trách customer bạn ngu được. "What can go wrong will go wrong" --> thế nên nhiệm vụ của bạn là phải foolproof cả API và implementation của bạn để tránh người dùng sử dụng sai.

Đọc thêm bài viết tiếng Anh sau của Joel Software: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/

Nhấp để mở rộng...

bribnt đã nói:

Write vào memory tốn hơi khá cycle chứ không phải ít đâu. Cỡ ~ 200 cycle / 1 cache line khi miss cache. CPU giờ có thể writeback, đưa tạm vào một write buffer nhưng cũng có giới hạn, cỡ đâu đó khoảng 60 entry, nếu số line phải write vượt quá số lượng này thì sẽ bị stalled.

Thời 2004 thì lại càng tệ hơn vì mấy cái công nghệ optimization kiểu này chưa/khó áp dụng được.

Nhấp để mở rộng...

skyfall đã nói:

Cái dở hơi này thì ko đội B nào dám ý kiến đội A đâu, nó chửi cho thối đầu

Nhấp để mở rộng...

tao_la_giang đã nói:

Ví dụ bạn đưa không hợp lý với tiêu đề rồi. Lập trình viên của MS tuân theo ANSI C/ISO C++ đấy chứ, việc sinh rác vào vùng nhớ đó sau khi giải phóng là phụ thuộc vào implementation detail của nhiều bên chứ bản thân chuẩn không yêu cầu (compiler, OS, v.v..). Chiếu theo chuẩn mà nói thì bản thân việc sinh rác mới là undefined behaviour.

(Cụ thể ca của đồng chí simcity thì đồng chí ấy sai lòi chứ chẳng phải MS, chẳng có lý do gì để MS phải đi fix cho duy nhất một trường hợp đặc biệt như vậy trong code base của Windows API cả. Cái này chắc rảnh mình tìm hiểu thêm chứ đọc qua thấy hơi hỏi chấm)

Ví dú đúng hơn với tiêu đề nên là như thế này: Một class có một hàm getA để lấy giá trị m_A, tuy nhiên trong qua trình get hàm này lại thực hiện tính toán thay đổi giá trị m_B nào đó. Khi ấy việc thay đổi m_B mới là side effects.

Nhấp để mở rộng...

tu_do_quan_diem đã nói:

Bọn Windows vẫn phải sửa mặc dù lỗi đúng là do bọn simcity chuối.

Lead windows ở Microsoft là Raymond Chen có một câu nổi tiếng như sau:

"Khi người dùng update X mà tích hợp giữa X & Y không hoạt động nữa thì người dùng chắc chắn sẽ đổ lỗi cho X, mặc dù lỗi thật có thể đến từ Y".

Ở đây X là Windows, Y là game simcity, thế nên người "vá lỗi" vẫn cứ phải là đội ngũ Windows nếu họ ko muốn ăn chửi từ người dùng "sao windows XP bản mới này kém ổn định thế nhỉ?"

Nhấp để mở rộng...

tao_la_giang đã nói:

Ừ, VD này cũng hơi cổ nên cũng khó kiếm, cả ngày nay cứ ngơi tay là mình kiếm mà không ra nhiều nguồn lắm. Nhưng dù sao thì VD đấy của bạn vẫn không rõ cho ý bạn nói, cái đó mới là thứ mình muốn nhấn mạnh.

Nhấp để mở rộng...