Steven
Steven8 phút đọc

Một bản phát hành 127 commit thực chất là gì

GeekBye v1.7.0 là 127 commit trong mười một ngày. Nhìn từ ngoài, nó giống như một trăm chuyện lặt vặt. Nhìn từ bên trong, đó là hai tính năng lớn được bện vào nhau — và một trong hai được xây sai chỗ, rồi bị gỡ ra và dựng lại giữa chừng bản phát hành. Đây là giải phẫu của một bản phát hành lớn.

Kỹ thuật
Bản phát hành
Kiến trúc
Bản phát hành GeekBye
Một bản phát hành 127 commit thực chất là gì

Có một phiên bản của bài blog này chỉ đơn giản liệt kê mọi thứ trong GeekBye v1.7.0 — một màn hình chính được thiết kế lại, một luồng hiệu chỉnh, một thanh bên có thể thu gọn, các thiết lập mới, và cứ thế tiếp diễn. Nó sẽ chính xác và nó sẽ chẳng dạy bạn được gì. Bởi câu chuyện thật thà về một bản phát hành 127 commit không phải là bản danh sách. Mà là hình dáng của nó.

Đây là hình dáng đó. Một trăm hai mươi bảy commit nghe như một trăm hai mươi bảy chuyện lặt vặt. Gần như không bao giờ đúng vậy. v1.7.0 là hai tính năng lớn, được xây song song trên các nhánh tồn tại lâu trong khoảng mười một ngày, rồi bện vào nhau ở đoạn cuối. Hiểu một bản phát hành lớn nghĩa là hiểu hai sợi đó — và cái chỗ duy nhất mà chúng tôi xây một thứ sai vị trí rồi phải gỡ nó ra giữa lúc đang bay.

Sợi thứ nhất: hiệu chỉnh

Sợi thứ nhất là hiệu chỉnh — một bài đánh giá bằng giọng nói do AI thực hiện về kỹ năng giao tiếp của bạn. Bạn bắt đầu một cuộc gọi trực tiếp với một "huấn luyện viên sự nghiệp" AI, đi qua một tập các giai đoạn có cấu trúc (khởi động, hành vi, giao tiếp kỹ thuật, phản ứng dưới áp lực, đặt mục tiêu), và ở cuối bạn được chấm điểm trên sáu chiều: sự tự tin, sự rõ ràng, tính cụ thể, mức độ gắn kết, sự điềm tĩnh, tính liên quan. Bên dưới, nó còn đo cả những chỉ số phát ngôn cụ thể — nhịp nói của bạn, tần suất từ đệm, những khoảng ngừng của bạn đọc lên như có chủ đích hay như đang lưỡng lự.

Đầu ra không phải một điểm số, mà là một điểm khởi đầu. Hiệu chỉnh cho ra các điểm mạnh, các vùng cần phát triển của bạn, và — quan trọng nhất — một độ khó được đề xuất để bắt đầu luyện tập. Nó hiệu chỉnh nơi mà sản phẩm nên gặp bạn. Mỗi kỹ năng quay lại dưới dạng một thẻ phản hồi có thể mở rộng, kèm một bản tóm tắt, một gợi ý cụ thể, và một câu được trích thẳng từ chính cuộc gọi của bạn làm ví dụ. Đây là tính năng mà toàn bộ trải nghiệm luyện tập còn lại được dựng lên trên đó.

Sợi thứ hai: cả một cửa sổ mới

Sợi thứ hai là một cuộc thiết kế lại premium — và gọi nó là thiết kế lại thì còn nói giảm đi. Nó không phải một lớp áo mới cho các màn hình sẵn có; thực chất nó là một cửa sổ ứng dụng thứ hai, được dựng ra qua sáu giai đoạn tường minh: một thanh bên kiểu Notion có thể thu gọn, một dropdown ở phần đầu thay thế danh sách phiên cũ, điều hướng kiểu trình duyệt với lịch sử và breadcrumb, và các bản dựng lại premium cho Home, Profiles, Meetings và Settings.

Hai tính năng lớn. Đó mới là 127 commit thực sự nói lên. Và phần khó nhất khi phát hành chúng không phải là viết ra cái nào — mà là việc bện lại. Hai nhánh phụ thuộc lẫn nhau; một nhánh được merge vào nhánh kia, và nhánh hiệu chỉnh đã phải kéo nhánh main vào bốn lần riêng biệt chỉ để khỏi trôi ra khỏi nhịp trong khi cuộc thiết kế lại dịch chuyển bên dưới nó. Số lượng commit không phải là chi phí của một bản phát hành lớn. Các nhánh tồn tại lâu và thứ tự tích hợp mới là.

Phần đáng đọc: chúng tôi đã xây hiệu chỉnh sai chỗ

Đây là sai lầm, và nó là một sai lầm hay bởi nó quá phổ biến.

GeekBye có một quy tắc kiến trúc cứng rắn: mọi thao tác AI đều nằm ở backend. Client là một lớp vỏ mỏng nói chuyện với một máy chủ. Ai cũng biết điều này.

Vậy mà hiệu chỉnh ban đầu lại được xây trong cơ sở dữ liệu cục bộ của client. Một bảng riêng, một bản migration cơ sở dữ liệu, một repository 254 dòng, các trình xử lý IPC, và một kho 515 dòng câu hỏi đánh giá — tất cả nằm trên máy của người dùng. Nó chạy được. Nó cũng lặng lẽ vi phạm chính cái hợp đồng mà cả ứng dụng được xây dựng trên đó.

Ba ngày sau, một commit xóa 680 dòng trên tám tệp để dời tất cả sang backend, nơi dữ liệu hiệu chỉnh trở thành một mô hình phía máy chủ đúng nghĩa, và logic câu hỏi cùng việc chấm điểm trở thành mối lo của máy chủ. Một commit khác xóa thẳng kho câu hỏi 515 dòng ở phía client. Bản diff gần như buồn cười: một dòng thêm vào, sáu trăm tám mươi dòng bị xóa.

Chẳng ai đặt ra mục tiêu viết 680 dòng mã bỏ đi. Nó xảy ra theo cách mà kiểu này luôn xảy ra: lối tắt phía client ở ngay đó, dựng thử cục bộ thì nhanh hơn, và "để sau chúng ta sẽ dời sang backend" cảm giác vô hại. Nhưng khi kiến trúc của bạn đã nói cho bạn biết nguồn chân lý nằm ở đâu, xây nó ở bất kỳ nơi nào khác không phải là một lối tắt — đó là việc làm lại mà bạn đã tự đặt lịch sẵn cho chính mình. Bài học đọng lại: đặt nó ở nơi hợp đồng nói, ngay từ lần đầu, kể cả khi bản cục bộ dựng lên nhanh hơn.

Lỗi mà chỉ có tích hợp mới tìm ra

Thêm một biên nhận nữa, vì nó là kiểu thất bại đặc trưng của các bản phát hành lớn. Một khi hiệu chỉnh và bộ điều hướng mới được nối lại với nhau và thực sự chạy, ứng dụng bắt đầu chạm một giới hạn tần suất — các lỗi HTTP 429 — mà không có lý do rõ ràng nào.

Nguyên nhân thuần túy nằm ở tích hợp. Trạng thái hiệu chỉnh đang được fetch ở cấp component, nên mỗi lần điều hướng lại fetch lại nó — và strict mode của React, vốn cố tình gọi effect hai lần trong lúc phát triển để làm lộ lỗi, lại nhân đôi điều đó thêm lần nữa. Kết quả là bốn đến tám yêu cầu hiệu chỉnh giống hệt nhau nổ ra cho mỗi lần đổi màn hình, đủ để chạm bộ giới hạn tần suất của máy chủ. Cách sửa đã gộp việc fetch lại thành vài lệnh gọi khi mount.

Bạn không thể tìm ra lỗi này khi kiểm thử riêng hiệu chỉnh, hay riêng bộ điều hướng. Nó chỉ tồn tại ở đường nối — nơi hai tính năng độc lập ai cũng đúng gặp nhau. Đó là khoản thuế mà một bản phát hành lớn thu: chặng cuối không phải là xây các tính năng, mà là khám phá tất cả những gì chỉ vỡ ra khi chúng cuối cùng ở chung một phòng.

Ba điều mà một bản phát hành lớn đã dạy

  1. Một bản phát hành 127 commit là hai hoặc ba chủ đề lớn, chứ không phải một trăm chuyện nhỏ. Hãy tìm các sợi. Công việc — và rủi ro — nằm ở cách chúng bện lại với nhau, chứ không phải ở con số.
  2. Đặt nguồn chân lý ở nơi hợp đồng nói nó thuộc về, ngay từ lần đầu. Chúng tôi đã xóa 680 dòng để dời hiệu chỉnh từ client sang backend. Lối tắt cục bộ là việc làm lại mà bạn đã đặt lịch trước; kiến trúc đã nói cho bạn câu trả lời rồi.
  3. Tích hợp làm lộ ra những thất bại mà kiểu làm cô lập không thể. Cơn bão 429 sống ở đường nối giữa hai tính năng đúng và chỉ xuất hiện khi chúng chạy cùng nhau. Hãy dành ngân sách cho một lượt tích hợp, chứ không chỉ kiểm thử theo từng tính năng.

Đây là người anh em ở thời v1 của một câu chuyện mà chúng tôi sẽ kể lại ở quy mô lớn hơn nhiều — xem một phiên bản 2 thực sự đòi hỏi những gì: 206 commit của những trạng thái thật thà (v2.0.0), nơi cùng một chân lý "một con số lớn thực ra là vài ý tưởng lớn" diễn ra xuyên suốt cả cuộc viết lại v2. Về chương trước trong câu chuyện v1, xem cách phát trực tiếp một báo cáo mà không bị nhấp nháy (v1.6.13); và cho toàn bộ vòng cung, xem giải phẫu việc xuất xưởng phần mềm đến độ hoàn hảo.

Bài Viết Liên Quan

Gỡ Backend Ra Khỏi Đường Đi Của Upload
Steven
Steven10 phút đọc

Gỡ Backend Ra Khỏi Đường Đi Của Upload

GeekBye quay lại màn hình của bạn và lưu video vào Google Drive của bạn. Phiên bản đầu tiên đẩy mọi bản ghi qua chính máy chủ của GeekBye trên đường tới đó; một bản phát hành sau, tập tin đi thẳng từ máy của bạn tới Drive, và backend bị giáng xuống thành thứ chỉ giữ một con trỏ. Phần thú vị là cái phiên bản «trực tiếp, có thể tiếp tục» ấy thực ra chứa ít code đến mức nào — vì khả năng tiếp tục đến từ việc xóa đi một proxy, chứ không phải từ việc viết ra một cái.

Kỹ thuật
Kiến trúc
Desktop
Một codebase, hai ứng dụng: cách white-label mà không cần fork
Steven
Steven6 phút đọc

Một codebase, hai ứng dụng: cách white-label mà không cần fork

GeekBye và Pavleur là hai ứng dụng desktop mang thương hiệu khác nhau được build từ một repository duy nhất — không fork, không nhân đôi codebase. Đây là bộ máy build-time giúp một codebase biên dịch ra hai sản phẩm, và cái bug một dòng khiến ứng dụng thứ hai của chúng tôi tự giới thiệu bằng cái tên sai.

Kỹ thuật
Kiến trúc
Build
Sự Im Lặng Vốn Chịu Tải
Steven
Steven10 phút đọc

Sự Im Lặng Vốn Chịu Tải

Hai bản phát hành cuối cùng của GeekBye v1 đều xoay quanh cùng một sự thật khó chịu: phiên âm thời gian thực trên một mạng thật không phải là không mất mát, và nước đi trung thực là thôi giả vờ rằng nó như vậy. v1.8.20 giữ một bản sao của mỗi audio chunk trên đĩa trước khi bỏ nó trong một lần kết nối lại, và bắt đầu đánh dấu các khoảng trống trong transcript ra thành tiếng. v1.9.0 thôi gửi im lặng để tiết kiệm bandwidth — rồi phát hiện ra im lặng chính là tín hiệu chính xác mà bộ phiên âm dùng để biết một câu đã kết thúc. Hai bản phát hành về cái giá của việc vứt đồ đi.

Kỹ thuật
Audio
Độ tin cậy