Ghi chép kỹ thuật, bài học rút ra từ hệ thống thật.
· 4 phút đọc
Ở phần lớn hệ thống, kết cục đắt nhất của một bài test là màu đỏ. Ở hệ thống booking thì là màu xanh — test pass nghĩa là vừa đặt một thứ có thật. Cách để vẫn test được trọn luồng: một luật chọn offer kiêm luôn cơ chế an toàn, và một gói bằng chứng — chứ không phải dấu tích xanh — làm thứ đối tác thật sự ngồi review.
· 4 phút đọc
Tám gateway service, một nhánh tích hợp chung, và một cú đẩy lên production luôn là hành động có chủ đích, gom theo đợt, với một con người đứng ở nút bấm. "Đơn vị release là cả cụm, không phải từng repo" trông như thế nào khi nó phải chạy hàng tuần, thay vì nằm yên trong danh sách nguyên tắc.
· 8 phút đọc
Không phải chuyện "AI viết code hộ". Phần có ích là biến khoảng 70 quy trình vốn chỉ nằm trong đầu một người thành những lệnh ai cũng chạy được, với cái nguy hiểm thì dán nhãn và có cổng chặn. Đây là hình dạng của nó, bằng những con số mình đếm được thật.
· 5 phút đọc
"Tức là gọi API của người khác hả" — câu tóm tắt mình nghe nhiều nhất về công việc của mình, và nó sai theo một cách đáng để mổ xẻ. Khoảng 150 supplier code trên chừng 90 tích hợp, hai pattern offer được ghi thành tài liệu, hai mô hình thực thi sau cùng một contract, và những supplier trả 200 kèm lỗi bên trong — một vòng quanh việc này thật sự gồm những gì, và vì sao nó là kiến trúc.
· 5 phút đọc
Không phải phần cơ khí của tích hợp — mà là cái domain nằm dưới nó. Tồn kho đổi ngay giữa search và book, giá có hạn sử dụng, chính sách huỷ là dữ liệu chứ không phải một cái cờ, năm dòng sản phẩm có hình dạng khác nhau thật, và nguồn hàng là công ty khác. Phần khó nằm ở thứ mình đang bán, không nằm ở cách mình gọi nó.
· 5 phút đọc
Ngày đầu với một supplier mới, mình không viết dòng code nào. Có một danh sách câu hỏi cố định — auth và cách xoay credential, search một nhịp hay hai nhịp, offer có định danh gì và sống được bao lâu, book có idempotent không và nếu không thì tra bằng gì, lỗi nằm ở đâu, chính sách có cấu trúc không, mô hình rate ngụ ý pattern nào — và các câu trả lời quyết định hình dạng của module. Con số ước lượng đi ra từ lượt đọc đó, không đi ra từ số endpoint.
· 4 phút đọc
Mọi cuộc điều tra booking đều bắt đầu giống nhau: ticket đưa cho mình một chuỗi ký tự — client reference, booking id, trace-id, hay PNR — kèm một ý kiến rất chắc chắn về chuyện lỗi của ai. Phương pháp dùng được thì nhàm chán và lần nào cũng vậy: điều hướng cái định danh, mở rộng nó, dựng timeline, rồi mới được phép có giả thuyết.
· 5 phút đọc
Một danh sách những thứ là contract mà nhìn không giống contract — một định danh client cầm giữa hai lần gọi, một mã lỗi đã ghi thành tài liệu, và ba nghĩa khác nhau của thiếu field, field rỗng và field null. Vì sao thêm thì gần như miễn phí còn bỏ đi là một đợt release phối hợp qua những repo mình không deploy, và giữ cho mọi thứ chạy được thì tốn thật những gì.
· 5 phút đọc
Kỹ thuật review sau một năm review cho sáu người: ba thứ một lượt review thật sự đang kiểm, một thứ nó không dùng để làm, vì sao mỗi comment giờ tự nói ra nó có chặn hay không, và bốn câu hỏi mình hỏi với mọi thay đổi đụng tới tiền hoặc state. Chưa từng đo thời gian review hay tỉ lệ lỗi — thứ đếm được là cái các lượt review để lại.
· 5 phút đọc
Không ai học được chín mươi cái gì cả. Người ta học một hình dạng rồi học phần ngoại lệ — nên một contract module cố định và hai pattern offer có tài liệu vừa là kiến trúc vừa là tài liệu onboarding. Tuần đầu thật ra là: chạy trọn luồng booking một lần, đọc hết một module supplier từ đầu tới cuối, rồi sửa một thứ nhỏ trên supplier thứ hai.
· 4 phút đọc
Cái gì thật sự thay đổi khi công việc chuyển từ "viết tính năng" sang dẫn một team sáu kỹ sư và ôm một release train đa repo. Đơn vị công việc trở thành một quyết định thay vì một cái diff, review thôi không còn là thứ chen ngang, và cách nhanh nhất để mất một tuần hoá ra là trả lời miệng một câu hỏi thay vì viết câu trả lời ra.
· 5 phút đọc
Mặc định là một relational store, Redis, một queue, Node và TypeScript — không phải vì chúng là công cụ tốt nhất trên lý thuyết, mà vì 3 giờ sáng không phải lúc để đi học các kiểu hỏng của một datastore. Rồi tới đúng một lần cái lựa chọn lạ là đúng, lập luận đàng hoàng, và bài test mình dùng để phân biệt hai tình huống đó.
· 5 phút đọc
Queue mua về đúng một thứ đáng tiền: một supplier chậm thôi làm phiền tất cả mọi người. Đổi lại nó thu tiền trả góp — thứ tự biến mất, retry biến idempotency thành việc của bạn, message hỏng vĩnh viễn phải có chỗ đi, và trạng thái công việc nằm rải ở ba chỗ có thể nói ngược nhau. Sổ ghi cả hai cột.
· 4 phút đọc
Bốn năm rưỡi trải qua backend, frontend và deployment — không phải để lấy huy hiệu, mà vì tool nội bộ không có kỹ sư nào khác. Mỗi phía của stack dạy gì cho phía kia, cái giá thật của sự trải rộng, và vì sao người dò được một request từ cái bảng React tới endpoint SOAP của supplier là người tìm ra được nó gãy ở đâu.
· 5 phút đọc
Làm tích hợp thì lỗi thường nằm trong một hệ mình không đọc được, nên log thôi làm công cụ debug và trở thành bằng chứng có thể phải đưa cho bên thứ ba. Điều đó đổi cách thiết kế bản ghi — bắt đúng cái đã bay đi, giữ body kể cả khi status là 200, bắn lại được — cùng ba ràng buộc để bằng chứng không tự biến thành sự cố.
· 4 phút đọc
Tài liệu như một đòn bẩy chứ không phải thủ tục giấy tờ, lập luận từ những hiện vật có thật: bảy mươi mấy runbook, mấy nghìn dòng prompt runbook, sơ đồ flow và user story viết ngược từ code ra, và một cái mục lục mà mỗi dòng đều mang mức sát thương của nó. Kèm cái mục mà site này cứ khăng khăng đòi — "chỗ mình không chắc" — và vì sao không có con số giờ-tiết-kiệm nào ở đây.
· 5 phút đọc
Một supplier là một tổ chức, không phải một cái endpoint. Certification là cuộc trao đổi với một người có lịch release riêng; bug mình tìm ra trong hệ của họ được sửa theo lịch của họ, nên cái report phải đủ tốt để họ xử lý mà không cần họp. Về bằng chứng như một cách giao tiếp, viết cho người không biết hệ của mình, và những ước lượng buộc phải chứa hàng đợi của người khác.
· 5 phút đọc
Câu hỏi đến trước khi có ai kịp đọc tài liệu API của supplier, mà tài liệu lại không phải chỗ chứa câu trả lời. Cái thật sự quyết định con số ước lượng — supplier thuộc pattern offer nào, book có idempotent không, lỗi nằm ở status code hay nằm bên trong một cái 200, sandbox có giống production không, và certification chạy theo lịch của ai — cùng câu trả lời hai pha mình đưa ra thay cho một cái deadline.
· 5 phút đọc
Dashboard ăn chính API của mình là bản review API nhanh nhất có thể có, và cái dạy được nằm ở chi tiết: một bảng mà mỗi dòng danh tính mang mấy chục cột supplier ID, ba lý do khác nhau khiến màn hình trống, một mã lỗi phải biến thành câu chữ người ta hành động được, và một màn hình tiền phải nói rõ số nào đang hiển thị và số nào bị trừ. Kèm phần nửa không ai lên kế hoạch — internal tool là một hệ thống production, người dùng ngồi ngay cạnh mình.
· 5 phút đọc
Những cái sai đắt tiền không phải là cái sai — mà là cái sai trông như đúng suốt nhiều tháng. Bốn thứ mình dựng cho chuyện đó: một chiến dịch mapping 11.953 dòng được viết sao cho rollback được từng dòng, và đã rollback thật; một file chi phí mà mỗi con số đều ghi rõ đo được hay ước lượng; một mục bắt buộc "những gì tôi không chắc"; và những agent có nhiệm vụ được ghi rõ là bác bỏ một kết luận chứ không phải xác nhận nó.
Đang hiện 10/20