Sự đánh đổi trong Phần mềm

Mỗi lựa chọn thiết kế bạn đưa ra đều đóng lại một cánh cửa đối với một lựa chọn khác. Phần mềm hoạt động dựa trên sự đánh đổi. Bạn phải đưa ra những lựa chọn này một cách có chủ đích. Nếu không, bạn sẽ thực hiện chúng một cách vô ý.

Các sự đánh đổi phổ biến mà bạn gặp phải:

• Tính năng vs Hiệu suất Mã nguồn sạch (clean code) thường chạy chậm hơn. Mã nguồn nhanh thường khó đọc. Hãy sử dụng mã nguồn dễ đọc cho các tiến trình xử lý hàng loạt (batch processes) chạy một lần mỗi ngày. Hãy sử dụng mã nguồn đã được tối ưu hóa cho các luồng xử lý chạy hàng nghìn lần trong mỗi yêu cầu (request).

• Tính linh hoạt vs Tính đơn giản Các lớp trừu tượng (abstractions) phức tạp khiến mã nguồn khó hiểu. Hãy viết mã nguồn đơn giản nhất có thể mà vẫn hoạt động được. Hãy xây dựng nó sao cho bạn có thể mở rộng sau này.

• Khả năng mở rộng vs Chi phí Thiết kế để đáp ứng lưu lượng truy cập khổng lồ sẽ tốn nhiều tiền hơn ở hiện tại. Việc đo lường tốc độ tăng trưởng sẽ giúp bạn quyết định. Nếu bạn tăng trưởng 20% mỗi tháng, hãy lập kế hoạch cho tương lai. Nếu vốn thấp, hãy kiểm soát chi phí của mình.

• Bảo mật vs Khả năng sử dụng Bảo mật cực đoan có thể làm hỏng trải nghiệm người dùng. Chúng tôi đã từng bắt buộc sử dụng mã xác thực phần cứng (hardware tokens) cho một công cụ quản trị. Tỷ lệ đăng nhập thành công đã giảm từ 98% xuống còn 84%. Các kỹ sư đã bị khóa tài khoản trong các tình huống khẩn cấp. Chúng tôi đã chuyển sang thông báo đẩy (push notifications) trên điện thoại di động. Tỷ lệ thành công đã tăng trở lại mức 96%. Hãy hướng tới mức bảo mật hợp lý, thay vì bảo mật tối đa.

Cách để đưa ra quyết định tốt hơn:

  • Hãy xác định rõ ràng mục tiêu của bạn.
  • Đo lường dữ liệu thay vì đoán mò.
  • Bắt đầu với một giải pháp đơn giản.
  • Chỉ tối ưu hóa khi bạn có bằng chứng.
  • Ghi chép lại lý do tại sao bạn đưa ra lựa chọn đó.

Tôi đã từng cố gắng tối ưu hóa một bộ tuần tự hóa JSON (JSON serializer) để tiết kiệm vài micro giây. Nó đã gây ra một lỗi rò rỉ bộ nhớ (memory leak) tăng thêm 300 MB. Một công cụ phân tích hiệu năng (profiler) cho thấy I/O mạng mới là nút thắt cổ chai (bottleneck) thực sự. Hãy luôn sử dụng profiler trước khi bạn viết lại mã nguồn.

Nợ kỹ thuật (Technical debt) là có thật. Một lối tắt hôm nay sẽ tiêu tốn thời gian vào ngày mai. Khi chúng tôi tiếp nhận một dịch vụ lộn xộn, chúng tôi đã không thực hiện một cuộc viết lại lớn. Chúng tôi đã sử dụng những thay đổi nhỏ và liên tục. Chúng tôi đã nâng độ bao phủ kiểm thử (test coverage) từ 30% lên 78%. Điều này đã giúp giảm thời gian sửa lỗi từ 4 ngày xuống còn 1,2 ngày.

Sự đánh đổi không phải là vĩnh viễn. Hãy xem xét lại các quyết định của bạn. Kiểm tra xem các tối ưu hóa của bạn có còn quan trọng hay không. Việc làm việc có chủ đích sẽ ngăn chặn một hệ thống tầm thường ở mọi mặt.

Nguồn: https://dev.to/lavkeshdwivedi/software-tradeoffs-44e7

Cộng đồng học tập tùy chọn: https://t.me/GyaanSetuAi