Sửa (fix) trong phát triển phần mềm: nó là gì, các giai đoạn và cách sửa lỗi

“Sửa” trong phát triển phần mềm nghĩa là gì

Sửa (fix) — khắc phục một lỗi trong mã chương trình, cấu hình hoặc dữ liệu. Thuật ngữ này bắt nguồn từ tiếng Anh “to fix” và là một trong những từ phổ biến nhất trong từ vựng của lập trình viên. Một bản sửa có thể đơn giản — sửa lỗi chính tả trong một dòng — hoặc phức tạp, ảnh hưởng đến kiến trúc của toàn bộ mô-đun.

Động từ “fix” có hai nghĩa: ngoài việc sửa lỗi, nó còn có nghĩa là “ghi lại các thay đổi trong hệ thống kiểm soát phiên bản” (từ tiếng Anh “commit/fix”). Trong cả hai trường hợp, kết quả đều giống nhau — mã trở nên tốt hơn trước đó. Trong cộng đồng chuyên nghiệp, sự khác biệt giữa các từ là tối thiểu và cả hai được sử dụng như các từ đồng nghĩa hoàn toàn.

Khả năng sửa lỗi đúng cách là một trong những kỹ năng chính của nhà phát triển. Lỗi là không thể tránh khỏi trong bất kỳ dự án nào và tốc độ sửa lỗi ảnh hưởng trực tiếp đến chất lượng sản phẩm và sự hài lòng của người dùng. Một cách tiếp cận có hệ thống bao gồm một quy trình rõ ràng: tái hiện, chẩn đoán, viết kiểm thử, sửa, thực hiện xem xét mã.

Vòng đời của lỗi: từ phát hiện đến sửa

Vòng đời của lỗi là một chuỗi các trạng thái mà một lỗi trải qua từ khi được phát hiện cho đến khi được loại bỏ hoàn toàn. Hiểu được chu kỳ này giúp tổ chức quá trình sửa lỗi và không bỏ qua các bước quan trọng. Trong một quy trình điển hình, một lỗi trải qua năm giai đoạn chính.

Phát hiện và ghi nhận

Giai đoạn đầu tiên là phát hiện lỗi, có thể xảy ra thông qua kiểm thử, giám sát lỗi, phản hồi từ người dùng hoặc báo cáo sự cố tự động. Lỗi được ghi lại trong trình theo dõi với các bước tái hiện, môi trường, hành vi mong đợi và thực tế. Mô tả lỗi tốt là nền tảng cho một bản sửa nhanh chóng.

Tái hiện và chẩn đoán

Nhà phát triển tái hiện lỗi trong môi trường của họ, làm theo các bước trong mô tả. Nếu lỗi không tái hiện một cách ổn định, cần có thêm dữ liệu: nhật ký, bản sao bộ nhớ, bản ghi màn hình. Sau khi tái hiện, chẩn đoán bắt đầu — tìm nguyên nhân gốc rễ trong mã. Trình gỡ lỗi, ghi nhật ký và phân tích hiệu năng thường được sử dụng ở giai đoạn này.

Viết kiểm thử và sửa

Trước khi sửa, nên viết một kiểm thử tái hiện lỗi — điều này đảm bảo rằng bản sửa thực sự hoạt động và ngăn ngừa hồi quy trong tương lai. Sau khi kiểm thử thất bại với lỗi mong đợi, nhà phát triển viết mã sửa. Kiểm thử phải vượt qua sau khi sửa và được thêm vào bộ kiểm thử hồi quy.

func testLoginWithInvalidCredentials() {
    let result = AuthService().login(
        email: "wrong@test.com",
        password: "wrong"
    )
    XCTAssertEqual(result, .failure(.invalidCredentials))
}

Xem xét mã và xác minh

Bản sửa được gửi đi xem xét mã — một đồng nghiệp kiểm tra xem bản sửa có đúng không, không làm hỏng các mô-đun liên quan và tuân thủ các tiêu chuẩn mã. Sau khi xem xét, bản sửa trải qua kiểm thử hồi quy. Trong chu kỳ lý tưởng, lỗi không được coi là đã đóng cho đến khi các kiểm thử được vượt qua và các thay đổi được người xem xét chấp nhận.

Triển khai và xác minh

Bản sửa được đưa vào nhánh chính và được triển khai lên production. Sau khi triển khai, nhóm xác minh lỗi trên môi trường production và theo dõi các chỉ số: liệu số lượng lỗi tương ứng trong báo cáo sự cố có giảm không. Lỗi được đóng trong trình theo dõi với phiên bản mà nó đã được sửa.

Hotfix và bugfix: khi nào và chọn cách tiếp cận nào

Hotfix là bản sửa khẩn cấp cho một lỗi nghiêm trọng đang ảnh hưởng đến người dùng trên production. Bản sửa này được thực hiện ngoài chu kỳ phát triển thông thường: một nhánh riêng được tạo từ nhánh release, thay đổi tối thiểu được thực hiện, nhánh được kiểm thử và triển khai ngay lập tức. Sau hotfix, các thay đổi phải được hợp nhất vào nhánh phát triển chính.

Bugfix là bản sửa theo kế hoạch trải qua vòng đời đầy đủ: từ ghi nhận đến xem xét mã và kiểm thử hồi quy. Bugfix là một phần của sprint thông thường và không yêu cầu triển khai khẩn cấp. Sự khác biệt giữa hotfix và bugfix nằm ở mức độ khẩn cấp và quy trình, không phải ở độ phức tạp của thay đổi.

Khi nào cần hotfix

Hotfix là cần thiết khi một vấn đề chặn chức năng chính được phát hiện trên production: cổng thanh toán không hoạt động, xác thực thất bại, người dùng thấy màn hình trống. Trong những trường hợp này, mỗi giờ ngừng hoạt động đều gây thiệt hại về tiền bạc và lòng tin. Hotfix phải tối thiểu — chỉ thay đổi mục tiêu loại bỏ vấn đề, không tái cấu trúc mã liên quan.

Khi nào bugfix là đủ

Bugfix phù hợp cho các lỗi không nghiêm trọng: lỗi trực quan, sự cố không nghiêm trọng trên các màn hình không chính, sự không chính xác trong dữ liệu phân tích. Các bản sửa này trải qua chu kỳ xác minh đầy đủ và được bao gồm trong bản phát hành theo lịch trình. Bugfix theo kế hoạch giúp tránh hồi quy mà một thay đổi vội vàng có thể gây ra.

Quy trình thực tế: cách sửa lỗi đúng cách

Một quy trình sửa lỗi đúng đắn không chỉ là viết mã, mà còn là một tập hợp các kỷ luật làm cho việc sửa lỗi an toàn và bền vững. Hãy xem xét trình tự các hành động cần tuân theo cho mỗi bugfix, bất kể độ phức tạp của nó.

Tái hiện lỗi cục bộ

Trước khi viết mã, hãy tái hiện lỗi trong môi trường phát triển của bạn. Nếu không tái hiện được, bạn không thể xác minh bản sửa có hoạt động không. Sử dụng cùng dữ liệu như người dùng — sao chép cấu hình, cờ tính năng, phiên bản API. Nếu lỗi không tái hiện được cục bộ, hãy thêm ghi nhật ký tạm thời trên staging.

Viết một kiểm thử thất bại do lỗi

Một thực hành tốt là viết kiểm thử trước mà tái hiện lỗi và thất bại. Điều này phục vụ hai mục đích: thứ nhất, bạn chứng minh lỗi tồn tại, và thứ hai, sau khi sửa, kiểm thử vượt qua, xác nhận việc sửa. Kiểm thử vẫn còn trong cơ sở mã như là biện pháp bảo vệ chống hồi quy.

@Test
fun testCartTotalWithPromotion() {
    val cart = Cart().apply {
        addItem(Item("T-shirt", 29.99))
        addPromotion(Promotion("10OFF"))
    }
    Assert.assertEquals(26.99, cart.total())
}

Thực hiện sửa đổi tối thiểu

Thay đổi tối thiểu là nguyên tắc chính của bugfix. Đừng tái cấu trúc mã xung quanh, đừng sửa các lỗi khác trong cùng một commit. Mỗi commit chỉ nên giải quyết một vấn đề. Điều này đơn giản hóa việc xem xét mã, khôi phục khi cần và hiểu lịch sử thay đổi. Một thay đổi — một commit.

Xác minh bản sửa hoạt động và không làm hỏng các phần khác

Sau khi viết bản sửa, hãy chạy toàn bộ bộ kiểm thử hồi quy. Nếu bản sửa ảnh hưởng đến một mô-đun dùng chung, hãy kiểm tra cả các kiểm thử của các mô-đun liên quan. Chạy trình lint và kiểm tra mã đáp ứng các tiêu chuẩn của dự án. Chỉ sau đó mới tạo Pull Request.

Công cụ theo dõi và các thực hành tốt nhất

Hệ thống theo dõi lỗi là một phần không thể thiếu của quy trình sửa lỗi. Chúng giúp không bỏ sót bất kỳ lỗi nào, chỉ định người chịu trách nhiệm, theo dõi trạng thái và thu thập thống kê. Việc chọn công cụ phụ thuộc vào quy mô nhóm và quy trình, nhưng chức năng cơ bản thì tương tự: tạo tác vụ, vòng đời, ưu tiên, tích hợp với VCS.

Các công cụ phổ biến

Jira là hệ thống phổ biến nhất cho các dự án doanh nghiệp, hỗ trợ quy trình làm việc linh hoạt, trường tùy chỉnh và tích hợp với Bitbucket/GitHub. GitHub Issues là trình theo dõi tích hợp sẵn, thuận tiện cho các nhóm nhỏ và vừa, tích hợp với Pull Requests. Linear là trình theo dõi hiện đại với giao diện tối giản và tốc độ cao, phổ biến trong các startup.

Các thực hành tốt nhất cho việc sửa lỗi

Thứ nhất: sửa nguyên nhân, không phải triệu chứng. Nếu ứng dụng bị sập do nil, đừng bọc toàn bộ mã trong if let — hãy hiểu tại sao giá trị trở thành nil. Thứ hai: bản sửa phải bao gồm một kiểm thử chứng minh việc sửa. Thứ ba: không sửa hai lỗi trong một commit — điều này làm phức tạp việc khôi phục. Thứ tư: thêm liên kết đến tác vụ trong trình theo dõi vào mô tả commit.

• Sử dụng định dạng conventional commits: fix(auth): handle nil token
• Luôn bao gồm liên kết đến issue trong mô tả commit
• Kiểm tra các kiểm thử vượt qua trước và sau khi sửa
• Đối với hotfix, hãy tạo nhánh riêng từ nhánh release, không phải develop
• Đừng quên hợp nhất hotfix vào develop sau khi triển khai