Bản chất của kỹ thuật phần mềm: Quản trị sự phức tạp thay vì chỉ viết code

Có một sự hiểu lầm về kỹ thuật phần mềm mà AI đang làm cho ngày càng trở nên rõ ràng: chúng ta thường nhầm lẫn giữa việc viết mã (code) và xây dựng phần mềm.

Có một sự chồng chéo ở một số khía cạnh, nhưng chúng không phải là một.

Viết mã nghĩa là chuyển đổi một ý tưởng thành các chỉ dẫn mà máy tính có thể thực thi. Xây dựng phần mềm nghĩa là quyết định xem những chỉ dẫn nào cần tồn tại ngay từ đầu, chúng nên tương tác với nhau như thế nào, những ràng buộc nào là quan trọng, chi phí cho các quyết định đó là bao nhiêu, những đánh đổi nào có thể chấp nhận được, và làm thế nào để hệ thống tạo ra có thể phát triển mà không sụp đổ dưới chính các ràng buộc và hạn chế của nó.

Hãy bắt đầu từ một tiền đề cơ bản: AI là một công cụ thiết yếu vì nó cực kỳ giỏi trong vấn đề đầu tiên.

Vấn đề thứ hai mới là nơi kỹ thuật phần mềm thực sự bắt đầu.

Phần khó nhất chưa bao giờ là việc gõ mã.

Hãy xem xét một yêu cầu kỹ thuật tương đối thông thường.

Chúng ta cần xử lý các sự kiện đầu vào và cập nhật một số dữ liệu.

Và đây là một vài câu hỏi đầu tiên nảy sinh trong một cuộc thảo luận kỹ thuật:

… và cứ thế tiếp tục.

Những câu hỏi này hầu như không liên quan gì đến cú pháp.

Việc lựa chọn ngôn ngữ lập trình rất quan trọng, vì nó ảnh hưởng đến sự thông thạo của đội ngũ, hiệu suất của đội ngũ, hiệu suất của hệ thống, tính an toàn, khả năng bảo trì, công cụ hỗ trợ và các đặc tính vận hành, nhưng nó không trả lời được các câu hỏi nền tảng.

Phần khó nhất là chọn kiến trúc đại diện cho tập hợp các thỏa hiệp phù hợp.

Và hiếm khi có một câu trả lời đúng cho tất cả mọi trường hợp.

1 vấn đề có thể có N giải pháp đúng hoàn toàn khác nhau.

Điều này đặc biệt rõ ràng khi phần mềm tồn tại trong một doanh nghiệp.

Hãy tưởng tượng hai công ty yêu cầu đội ngũ kỹ thuật của họ xây dựng thứ nghe có vẻ giống hệt nhau.

Các yêu cầu của họ có thể trông giống hệt nhau trên giấy tờ.

Nhưng:

Giải pháp ấn tượng về mặt kỹ thuật cho công ty này có thể là một giải pháp thiếu trách nhiệm đối với công ty kia.

Đây là lý do tại sao kiến trúc không thể bị rút gọn thành việc đặt câu hỏi:

Cách tốt nhất để triển khai X là gì?

Câu hỏi đúng thường gần với:

Với những ràng buộc này, đội ngũ này, doanh nghiệp này, cơ sở hạ tầng này, ngân sách này, những rủi ro này và sự phát triển dự kiến của sản phẩm, đâu là cách phù hợp nhất để triển khai X vào hôm nay?

Đó là một câu hỏi hoàn toàn khác biệt.

AI tạo ra các giải pháp. Các kỹ sư chịu trách nhiệm về các đánh đổi.

Sự khác biệt này đang trở nên ngày càng quan trọng vì cách AI đang được các tổ chức phần mềm áp dụng.

AI cực kỳ hữu ích cho việc phát triển phần mềm. Chúng ta sử dụng nó như một công cụ tăng tốc: tạo mã boilerplate, khám phá các API, đề xuất các cách triển khai, tìm lỗi tiềm ẩn, giải thích mã lạ, tạo các bài kiểm thử, so sánh các phương pháp hoặc đơn giản là giảm bớt khối lượng công việc cơ học cần thiết để biến một ý tưởng thành mã chạy được.

Nhưng có một xu hướng nguy hiểm là mở rộng khả năng này thành một thứ gì đó rộng lớn hơn nhiều:

ủy quyền chính khả năng đánh giá kỹ thuật.

Bạn có thể:

Tuy nhiên, sự tồn tại của một câu trả lời không có nghĩa là vấn đề kỹ thuật cơ bản đã được giải quyết.

Vấn đề thực sự là quyết định đúng đắn phụ thuộc vào ngữ cảnh, thường là một lượng ngữ cảnh khổng lồ, cần hàng giờ, hàng ngày hoặc thậm chí hàng tuần để phân tích, hiểu và đánh giá, thường liên quan đến nhiều phòng ban trong cùng một tổ chức, và thường để lại những vùng xám khó chính thức hóa và có thể trở thành thách thức khi cần thay đổi trong tương lai.

Đây là cách thế giới thực vận hành: một phần ngữ cảnh đó tồn tại trong tài liệu. Phần lớn thì không.

Nó tồn tại trong các cuộc trò chuyện với khách hàng. Trong lịch sử của sản phẩm. Trong kỹ năng của đội ngũ kỹ thuật. Trong các sự cố vận hành từ ba năm trước. Trong các ràng buộc ngân sách. Trong thời hạn. Trong các nghĩa vụ hợp đồng. Trong hành vi kỳ lạ của một hệ thống cũ (legacy system) mà không ai muốn đụng vào. Trong việc biết rằng một khách hàng có khả năng sẽ yêu cầu một tính năng cụ thể nào đó sau sáu tháng nữa.

Và đôi khi nó chỉ đơn giản tồn tại trong kinh nghiệm: nhận ra rằng một kiến trúc thanh lịch về mặt lý thuyết sẽ trở thành một cơn ác mộng vận hành đối với đội ngũ được kỳ vọng sẽ duy trì nó.

Bạn không thể coi tất cả những điều này là một chi tiết nhỏ mà bằng cách nào đó sẽ được nắm bắt bằng cách thêm một đoạn văn khác vào câu lệnh (prompt) AI.

Không có kiến trúc nào mà không có sự đánh đổi.

Kỹ thuật phần lớn là kỷ luật của việc quyết định xem bạn sẵn sàng chấp nhận những vấn đề nào. Ngay cả khi bạn không làm việc ở quy mô FAANG, các dự án của bạn vẫn có thể cần xử lý đủ dữ liệu để việc đưa ra các quyết định kỹ thuật đúng đắn trở nên thiết yếu nhằm duy trì hiệu suất đầy đủ, mà không cần phải đổ tiền vào phần cứng đắt đỏ để bù đắp cho những thiếu sót của hệ thống.

Ngay cả những lựa chọn "đơn giản" cũng đi kèm với các yếu tố cần được xem xét: