Có người forward tài liệu API của một supplier rồi hỏi tích hợp cái này mất bao lâu. Câu hỏi hoàn toàn hợp lý, hỏi với thiện chí, và thường là người hỏi đang phải trả lời lại cho một người khác nữa. Chỗ khó chịu là: cái tài liệu đó — dù viết kỹ tới đâu — gần như là thứ ít thông tin nhất trong cả gói, và đọc nó nhanh hơn cũng không làm câu trả lời tới sớm hơn.
Mình đã làm đủ số lần để biết con số ước lượng được cấu thành từ cái gì, và nó không được cấu thành từ danh sách endpoint. Khoảng 150 supplier code chạy trên chừng 90 tích hợp khác nhau trên nền tảng mình đang làm; riêng hotel là 75 code trên 31 module. Danh sách endpoint thì lần nào cũng gần như cùng một tài liệu. Phần chênh lệch nằm ở chỗ khác.
Lượt đọc đầu tiên thật ra đang tìm gì
Khi mở tài liệu của một supplier mới, mình không đếm endpoint. Mình đang cố trả lời năm câu hỏi, và thường thì không câu nào được trả lời trong tài liệu cả.
Đây là pattern offer nào? Bọn mình có hai, ghi hẳn thành tài liệu, vì mô hình của các supplier khác nhau thật. Ở pattern A, supplier trả về một token duy nhất đặt được N phòng. Ở pattern B, giá từng phòng độc lập, và một offer cho lượt search hai phòng chưa hề tồn tại cho tới khi mình materialise nó thành ma trận tổ hợp hợp lệ. Nếu supplier khớp một trong hai, module là một hình dạng đã biết và ước lượng chủ yếu là thời gian gõ. Nếu nó không khớp cái nào — một cách thứ ba để mô tả thế nào là một cái phòng, hoặc một mức giá chỉ hợp lệ khi đi kèm một cú gọi khác của chính supplier đó — thì việc đầu tiên không phải là code, mà là một buổi bàn thiết kế; mà bàn thiết kế thì không có thời lượng, chỉ có thành phần tham dự.
Book có idempotent không? Không phải "có field reference không" — mà là gửi đúng một request book hai lần thì ra một đơn hay hai đơn, và sau một cú timeout thì supplier có nói cho mình biết là ra cái nào không. Nếu câu trả lời là không, tích hợp mọc thêm nguyên một hệ con: một đường đối soát, đủ sức đi hỏi lại — sau một cú gọi không bao giờ trả về — rằng tiền đã chạy hay chưa. Đường đó thường tốn công ngang cái luồng đẹp mà nó đang bảo vệ, và nó vô hình trong mọi buổi demo.
Lỗi nằm ở đâu? Có supplier dùng status code. Có supplier trả HTTP 200 kèm lỗi nằm trong body, khiến ý kiến của tầng transport về cú gọi đó trở nên vô giá trị, và bắt mọi response phải qua một lượt đọc thứ hai theo cách riêng của từng supplier. Đó là một chi phí đã biết — bọn mình có sẵn những module làm đúng việc đó — nhưng nó đổi nghĩa của câu "xử lý lỗi xong rồi", và đổi từ trước khi có dòng code nào.
Sandbox có giống production không? Một sandbox trả về dăm ba khách sạn tĩnh thì cho biết định dạng trên đường truyền, và không cho biết gì về hành vi khi gặp catalogue thật: phân trang chỉ xuất hiện khi vượt một ngưỡng, rate limit, phân bố độ trễ mà mình phải nhét vừa dưới deadline search 30 giây. Sandbox có thể làm một tích hợp trông như đã xong từ rất lâu trước khi nó xong.
Certification chạy theo lịch của ai? Certification đẩy một bộ testcase riêng của từng provider đi hết luồng và sinh ra một bộ bằng chứng — request và response của từng testcase, cộng cú gọi lên upstream — để đối tác ngồi review. Việc review là của họ. Việc xếp lịch cũng là của họ. Đoạn đó trên timeline không phải một ước lượng kỹ thuật, và coi nó như ước lượng kỹ thuật chính là cách một cái plan trượt vì những lý do không engineer nào dịch chuyển được.
Câu trả lời hai pha
Nên mình không đưa ra một cái deadline. Mình đưa hai thứ.
Thứ nhất, một pha đọc có biên: một lát thời gian ngắn, cố định, mà sản phẩm đầu ra không phải code mà là một hình dạng — đây là pattern offer nào, book có idempotent không, lỗi nằm ở đâu, sandbox đáng tin tới mức nào, và lịch certification thuộc về ai. Có biên là cố ý, vì kiểu hỏng của câu "để em xem đã" là nó nở ra cho tới khi có người hỏi lại.
Thứ hai, một con số ước lượng chỉ tồn tại sau pha đó, và luôn đi kèm những rủi ro được gọi tên — những thứ nếu xảy ra thì con số đổi. Gọi tên rủi ro mới là phần làm cho ước lượng dùng được với người phải lên kế hoạch quanh nó: "nếu hoá ra cần thêm đường đối soát thì cộng thêm phần việc đó" là thứ một người làm plan cầm được. Một con số trần trụi thì không.
Vì sao đệm số tệ hơn giải thích
Phương án hấp dẫn hơn là đoán đại một con số rồi nhân lên. Đệm số hỏng theo một kiểu rất cụ thể: nó giấu mất việc mình đang ở ca nào. Một con số đệm mà cuối cùng dư dả thì trông như giấu bài, còn một con số đệm mà vẫn vỡ thì đã tiêu hết uy tín để đổi lấy không gì cả. Cả hai kết cục đều không dạy ai được điều gì về supplier đó, và lần ước lượng sau lại bắt đầu từ tờ giấy trắng y hệt.
Giải thích hình dạng thì sống sót qua cả hai kết cục. Nếu supplier hoá ra khớp gọn pattern A, người đọc thấy được vì sao nó về sớm. Nếu nó cần một buổi bàn thiết kế, họ đã biết trước đó là nhánh có thể xảy ra, vì nhánh đó đã được gọi tên từ trước khi nó xảy ra.
Vì sao ca bình thường lặp lại được thật
Không có nghĩa là tích hợp nào cũng là một ẩn số. Lý do câu trả lời hai pha dùng được là vì một nhánh của nó thật sự lặp đi lặp lại, và nó lặp lại được nhờ một quyết định cấu trúc: mỗi supplier một module, viết theo một contract cố định, đăng ký bằng code trong một registry duy nhất. Hành vi riêng của supplier có đúng một chỗ để nằm, nên ca "bình thường" bị chặn biên bởi cái contract, chứ không bởi việc ai đó còn nhớ bao nhiêu về lần tích hợp trước.
Đó là thứ làm cho ước lượng thành thật chứ không phải phòng thủ. Không phải "cái này mất bao lâu cũng được". Mà là "nếu là ca bình thường thì hình dạng đã biết và khối lượng đã biết; còn đây là những thứ sẽ làm nó không còn là ca bình thường".
Con số mình không có
Mình chưa bao giờ công bố phân bố thời gian thật sự của các lần tích hợp, và cũng không có cái phân bố nào đang nằm sẵn trong một file spreadsheet nào đó. Ngày bắt đầu trên tracker không phải ngày việc thật sự bắt đầu, còn "xong" thì có vài định nghĩa đều hợp lý — merge xong, certify xong, live dưới một switch thật — và mỗi định nghĩa cho ra một phân bố khác nhau. Mình tính ra được một con số. Mình sẽ không tin nó, và người lên kế hoạch dựa vào nó cũng không nên tin.
Nên vị trí thành thật là: mình nói được ước lượng phụ thuộc vào những gì, chặn biên được thời gian đi tìm hiểu những cái đó, và gọi tên được những thứ sẽ làm nó dịch. Cái mình không làm được là nói cho bạn con số trung vị, vì ở đây chưa ai đo nó cả.