Laravel

Biểu đồ log-log: đường ngoại suy chấm chấm kết thúc gần 10 ms, hai đường đo thật không index bỏ xa nó (MariaDB 10.11 ở 968 ms và 13.0 ở 148 ms tại 1M dòng), vạch gạch 300 ms, và một đường phẳng dưới 1 ms cho trường hợp có index

Tôi viết ngưỡng thêm index thành con số, rồi tự đo lại và thấy nó lệch 15 đến 100 lần

Bạn đã từng ký duyệt một tài liệu thiết kế. Trong đó thế nào cũng có một câu kiểu “khi vượt X thì làm Y”. Có ai từng sinh thử đúng X dòng để xem con số đó có đúng như nó nói không? Cuối tháng trước, tôi duyệt một thiết kế cho phép tra cứu trên một cột không có index. Bảng chứa cột đó không thuộc team tôi. Tôi viết điều kiện để sửa lại thành một câu có hai con số: “khi bảng vượt khoảng 1.000.000 dòng, hoặc p95 của truy vấn lọc theo voucher vượt 300 ms, thì gửi yêu cầu thêm index non-unique cho team sở hữu.” Câu đó có đúng một nhiệm vụ: đưa phương án “ship mà không thêm index” qua vòng review thiết kế. Nó biến lời hứa “sẽ thêm sau” thành một điều kiện mà người review có thể ký. Và nó đã hoàn thành nhiệm vụ đó. ...

Một merge commit có hai cha, và một nhánh thứ ba đẩy thêm một dòng vào file đã resolve

Merge chỉ có đúng hai cha. Một dòng lấy từ nhánh thứ ba làm sập toàn bộ route API

Trong 17 tiếng 55 phút, mọi route dưới /api/* trên staging đều trả về lỗi fatal. Lần merge gây ra chuyện đó lên nhánh lúc 17:18 chiều; bản fix chấm dứt nó lên lúc 11:13 sáng hôm sau. Con số này lấy từ repo riêng và log server, bạn không kiểm chứng được, nên cứ đọc nó như lời kể của tôi. Bản thân lần merge rất bình thường: một nhánh feature vào staging, một conflict, ở file đăng ký HTTP middleware. Conflict là thật, hai bên cùng thêm một dòng ở đúng một vị trí. Thứ hỏng không phải là conflict. Thứ hỏng là cách conflict được “giải quyết”, rồi cách kết quả được kiểm và được coi là xong. ...

Hai bảng có id auto-increment trùng nhau, file import trỏ vào bảng này còn code đọc bảng kia

Import sửa nhầm dòng suốt nhiều năm vì hai bảng có id trùng nhau

Tính năng import điều chỉnh quota chương trình khuyến mãi từ file bảng tính đã chạy trên production nhiều năm. Lần kiểm thử thủ công nào cũng giống nhau: tải một file lên, mở chương trình ra, thấy một quota đã đổi, đóng ticket. Handler này không có một test tự động nào. Nó đang sửa nhầm dòng. Không phải thỉnh thoảng, mà về cấu trúc: lần chạy nào mà hai id trùng nhau thì lần đó sửa sai, và trên staging thì chúng trùng thật. Trong những năm đó nó đã đụng vào bao nhiêu dòng trên production, tôi chưa đo và sẽ không đoán ở đây. Thứ tôi chỉ ra được là cơ chế, vì sao ba lớp bảo vệ khác nhau đều để nó đi qua, và một test duy nhất mà nếu có từ ngày đầu thì đã bắt được. ...

Câu lệnh SELECT FOR UPDATE tan thành chuỗi rỗng trên driver sqlite

Cái lock tôi đánh rơi khi refactor, và 1184 test xanh không hề hay biết

QA gửi đúng một dòng: chưa có test chạy đồng thời trên kho tồn khuyến mãi. Tôi mở file ra, định viết bốn cái test rồi đóng ticket trong buổi chiều. Nhưng cái khóa mà bốn test đó sinh ra để bảo vệ thì đã biến mất khỏi code từ lúc nào không hay. Chuyện gì có thể hỏng ở đây Hệ thống là phần backend của mảng khuyến mãi. Giả sử một mã hàng có 200 sản phẩm trong kho: nhiều chương trình khuyến mãi cùng lấy hàng từ đúng 200 cái đó. Trước khi một chương trình giữ chỗ cho một đơn, service phải làm ba việc theo thứ tự: đọc xem kho còn bao nhiêu, trừ đi phần các chương trình khác đã giữ, rồi ghi phần của mình. ...