Bản chất của phát triển phần mềm: Tại sao tính năng đơn giản lại chiếm chưa đầy 20% khối lượng công việc?

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Tính năng hiển thị trên giao diện người dùng thường chỉ chiếm khoảng 16% tổng bề mặt API của một sản phẩm.
• 84% còn lại là sự kết nối phức tạp với thế giới bên ngoài: hệ thống định danh, thanh toán, tích hợp bên thứ ba và các quy tắc bảo mật.
• Việc đo lường bề mặt API thông qua phân tích tĩnh giúp lập trình viên có cái nhìn thực tế hơn về khối lượng công việc thực sự thay vì chỉ nhìn vào bề nổi của tính năng.

Khi bạn nhận được yêu cầu xây dựng một tính năng đơn giản như "Hỏi trải nghiệm người dùng", bạn thường nghĩ đến điều gì? Một form nhỏ, một vài trường dữ liệu và một nút gửi? Nếu bạn tin rằng đó là toàn bộ câu chuyện, thì có lẽ bạn đã đánh giá thấp sự phức tạp của hệ thống hiện đại. Thực tế, đằng sau một yêu cầu tưởng chừng đơn giản lại là một mạng lưới các endpoint và kết nối API chằng chịt mà ngay cả những kỹ sư dày dạn kinh nghiệm cũng phải ngỡ ngàng khi nhìn vào dữ liệu thực tế.

Giải mã bề mặt API: Khi tính năng chỉ là phần nổi của tảng băng

Trong quá trình phân tích các hệ thống phần mềm hiện đại, chúng ta thường thấy một mô hình lặp lại. Lấy ví dụ về một công cụ khảo sát, hệ thống không chỉ đơn thuần lưu trữ dữ liệu. Nó cần kết nối với hàng loạt dịch vụ ngoại vi để đảm bảo tính vận hành:

• Dịch vụ lưu trữ ảnh: Như Unsplash, để người dùng tùy biến giao diện.
• Hệ thống quản lý phiên bản: Như GitHub Releases API, để kiểm tra cập nhật ứng dụng.
• Dịch vụ quản trị doanh nghiệp: Như Formbricks Cloud, phục vụ kiểm tra bản quyền và báo cáo sử dụng.
• Nền tảng CRM: Để quản lý vòng đời khách hàng thông qua email.

Sự phức tạp này không chỉ giới hạn ở các công cụ khảo sát. Khi thực hiện quét trên các dự án mã nguồn mở khác như Documenso, kết quả cho thấy hệ thống cần tới 116 endpoint và 148 cuộc gọi ngoại vi chỉ để thực hiện một tác vụ ký tài liệu. Điều này cho thấy rằng, trong kỷ nguyên phát triển phần mềm hiện đại, việc xây dựng hệ thống đánh giá LLM chuẩn Production hay các ứng dụng SaaS đều đòi hỏi sự đầu tư hạ tầng khổng lồ.

Tỷ lệ vàng trong phát triển sản phẩm

Thông qua phương pháp phân tích tĩnh (static analysis) trên các commit cụ thể, chúng ta có thể định lượng hóa khối lượng công việc. Dưới đây là bảng so sánh tỷ lệ bề mặt API giữa tính năng người dùng và hạ tầng kết nối:

Lưu ý: Con số 84% này bao gồm các lớp trung gian, quy tắc trình duyệt, cổng thanh toán và các phiên bản API cũ không thể loại bỏ do yêu cầu tương thích ngược. Đây chính là lý do tại sao việc tối ưu hóa quy trình phát triển phần mềm lại quan trọng đến vậy.

Đánh giá & Lời khuyên Thực tiễn

Từ góc độ của một Tech Lead, việc hiểu rõ tỷ lệ này giúp bạn lập kế hoạch dự án chính xác hơn.

• Ưu điểm: Giúp quản lý kỳ vọng của khách hàng và stakeholder về thời gian phát triển. Khi bạn biết rằng 84% công việc là "kết nối với thế giới", bạn sẽ không bao giờ cam kết hoàn thành một tính năng phức tạp trong vài ngày.
• Nhược điểm: Dễ dẫn đến tình trạng "over-engineering" nếu không kiểm soát tốt số lượng các dịch vụ bên thứ ba.
• Phạm vi ứng dụng: Phù hợp cho các team đang xây dựng sản phẩm SaaS, nơi việc tích hợp là yếu tố sống còn. Nếu bạn đang xây dựng ứng dụng hướng sự kiện đầu tiên với Apache Kafka, hãy chuẩn bị tinh thần cho một bề mặt API lớn tương tự.

Mẹo hay: Hãy sử dụng các công cụ phân tích tĩnh để quét repository của bạn định kỳ. Việc phát hiện sớm các endpoint thừa thãi sẽ giúp giảm đáng kể chi phí bảo trì sau này, tương tự như cách bạn tối ưu hóa API Dry-Run cho các DeFi Bot.

Câu hỏi thường gặp (FAQ)

Tại sao bề mặt API lại lớn hơn nhiều so với tính năng thực tế?

Vì phần mềm hiện đại không hoạt động cô lập. Nó cần giao tiếp với hệ thống định danh, thanh toán, lưu trữ, và các dịch vụ bên thứ ba để đảm bảo tính bảo mật và khả năng mở rộng.

Làm thế nào để giảm thiểu sự phức tạp này?

Bạn nên áp dụng kiến trúc microservices hoặc modular monolith, đồng thời sử dụng các bộ lọc (middleware) để quản lý các cuộc gọi ngoại vi một cách tập trung thay vì rải rác khắp codebase.

Có nên loại bỏ các endpoint cũ không?

Việc loại bỏ cần thận trọng. Nếu SDK của khách hàng vẫn đang gọi các endpoint đó, việc xóa bỏ sẽ gây ra lỗi nghiêm trọng. Hãy thực hiện theo lộ trình deprecation rõ ràng.

Kết luận

Phát triển phần mềm không chỉ là viết code cho tính năng, mà là xây dựng một hệ sinh thái bền vững. Việc nhận thức được rằng tính năng chỉ chiếm 16% khối lượng công việc sẽ thay đổi cách bạn tiếp cận dự án. Hãy tập trung vào việc tối ưu hóa hạ tầng kết nối để đảm bảo sản phẩm của bạn luôn ổn định. Nếu bạn quan tâm đến việc xây dựng hệ thống quy mô lớn, đừng quên theo dõi các bài viết chuyên sâu tại hi_dev để cập nhật những xu hướng công nghệ mới nhất.