Trong phần lớn lịch sử nhân loại, chúng ta đánh giá chất lượng code thông qua code review: ai đó đọc những gì bạn viết và đảm bảo nó sạch sẽ, chu đáo, nhanh, dễ hiểu và được kiểm thử tốt. Với các agent, cách tiếp cận đó khó có thể mở rộng; có quá nhiều code để bất kỳ ai đọc hết. Do đó, ngày càng nhiều hoạt động kiểm tra chất lượng phải diễn ra trong harness, môi trường và hệ điều hành xung quanh agent. Tôi vẫn đọc và review code, nhưng tôi rất có chủ đích về việc nơi nào tôi cảm thấy thoải mái khi dùng các ràng buộc làm công cụ kiểm tra.
Chất lượng phần mềm giờ đây phụ thuộc vào những ràng buộc bạn đặt ra xung quanh các agent của mình.
Danh sách của Guillermo là một phép thử tốt để xem bạn có đủ khả năng bỏ qua việc đọc code hay không. Hãy để ý rằng mỗi câu trả lời "có" thực chất đều nói lên mức độ rủi ro thấp đến nhường nào - không có người dùng, code dùng một lần, bản prototype. Khi rủi ro tăng lên, phải có thứ gì đó đọc code. Nếu không phải bạn đọc từng diff, thì đó phải là các ràng buộc.
Các ràng buộc định nghĩa những gì hệ thống được phép làm bằng cách áp các bài kiểm thử và ràng buộc xác định lên các đề xuất của agent. Chính bằng việc thiết lập và duy trì những ràng buộc này, chúng ta xây dựng các vòng lặp cung cấp phần mềm sản xuất chất lượng cao một cách đáng tin cậy, ngay cả khi các agent tạo ra hàng trăm nghìn hoặc hàng triệu thay đổi mỗi ngày.
Chúng tôi gọi những ràng buộc này là quality gates, và chúng có nhiều hình thức khác nhau.
Chúng bao gồm các bài kiểm thử đơn vị (unit tests), kiểm thử thuộc tính (property tests) và kiểm thử chấp nhận (acceptance tests) thông thường. Chúng bao gồm kiểm thử đột biến (mutation testing), trong đó chúng tôi tạo ra các biến thể của code, chạy chúng với cùng các bài kiểm thử và đảm bảo rằng mọi người không lén nhét vào những con bug mà chúng tôi đang bỏ sót. Chúng là các chỉ số về chất lượng code, chẳng hạn như độ phức tạp cyclomatic và độ dài dòng, giúp giữ cho mọi thứ dễ đọc.
Hai người có thể bất đồng về việc có nên đọc code hay không mà vẫn đồng ý về cơ chế. Guillermo thì đọc. Bob thì không đọc gì cả. Cả hai đều đang mô tả một thử thách - điểm khác biệt chỉ là có một con người ngồi bên trong nó hay không (Tôi không tán thành các quan điểm khác của Bob).
Các ràng buộc cũng đóng vai trò quan trọng trong việc xác định hệ thống sẽ chấp nhận và áp dụng những đề xuất nào làm thay đổi code. Vào thời điểm một đề xuất thay đổi di chuyển từ trình thông dịch đang chạy agent đến bộ điều khiển agent rồi ra production, chúng tôi đã thực hiện đủ các kiểm tra trên nó để tin chắc rằng nó an toàn để phát hành và tác động của thay đổi nằm gọn trong phạm vi của agent.
Một agent có thể đề xuất bất cứ điều gì. Các ràng buộc của bạn quyết định liệu một đề xuất có đủ an toàn, đúng đắn, đúng phạm vi và hữu ích để bạn và nhóm của mình phát hành hay không.
Mô hình này mang lại nhiều thứ, nhưng cũng bỏ sót nhiều phần, và những thiếu sót đó đáng để suy nghĩ ngay hôm nay. Một vấn đề là quyền tự chủ (autonomy); các agent có thể thực hiện tốt ý định của mình, nhưng có thể thất bại khi thiếu thông tin hoặc khi điều chúng cố làm còn mơ hồ. Điều này áp dụng cho cả bản thân nhiệm vụ lẫn cách nó được tham số hóa bởi harness, môi trường và các thành phần khác.
Nhiều lý do khiến con người không thể phát hành được code tuyệt vời cũng là những gì agent có thể gặp phải: môi trường mong manh không chịu được áp lực từ các script, các bản build bất định, thiếu quyền truy cập và các bài kiểm thử yếu. Điều này thúc đẩy việc xây dựng một môi trường tốt hơn, nơi cung cấp cho agent phản hồi đáng tin cậy, cho phép các chế độ thất bại ít gây thiệt hại và giúp dễ dàng tích lũy thành công từng bước.
Môi trường chúng ta hướng tới là nơi một agent có thể làm việc thực thụ, nhận được phản hồi mà nó có thể tin cậy, và thất bại mà không gây ra quá nhiều thiệt hại.
Một vấn đề quan trọng khác là lòng tin. Chúng ta không thể giao phó ý định một cách cả tin cho một thứ thông minh và mạnh mẽ như một agent hiện đại mà không kiểm tra tính đúng đắn. Chúng ta bắt đầu bằng sự tin tưởng, nhưng lòng tin đó phải được xây dựng bằng sự nỗ lực.
Một số ràng buộc định hình công việc trước khi nó bắt đầu. Một số ràng buộc khác đưa ra phản hồi trong khi agent đang làm việc. Số còn lại quyết định liệu đầu ra của nó có thể vượt qua ranh giới production hay không.
Có rất nhiều cách để mô hình hóa cách chúng ta đặt một cấu trúc xác minh bao quanh một hệ thống.
Theo kinh nghiệm của tôi, sẽ hữu ích nếu có một bộ kiểm tra rộng hơn, nhưng được lựa chọn có chủ đích, cho các ràng buộc của bạn thay vì chỉ dựa vào unit tests. Ý tưởng là mỗi bài kiểm tra có một trách nhiệm riêng biệt, có thể từ an toàn kiểu dữ liệu (type safety) và hiệu suất cho đến quét bảo mật ở giai đoạn cuối. Mọi người cũng có thể tự định nghĩa các ràng buộc của riêng mình, bao gồm các quy tắc kiến trúc mà các công cụ lint như ESLint có thể thực thi. Nhiều công cụ trong số này có các hook tích hợp sẵn để có thể kéo agent hoặc con người vào khi có sự cố.
Hiện tại, phần lớn sự khác biệt giữa đầu ra hữu ích của agent và đầu ra kém chất lượng (slop) vẫn phụ thuộc vào kỹ năng của đội ngũ vận hành vòng lặp.
AI mang lại cho chúng ta khả năng sinh code với khối lượng lớn và tốc độ cao, nhưng điều này cũng có nghĩa là con người ngày càng khó review từng thay đổi một. Thay vào đó, bạn phải có chủ đích về việc sự chú ý của họ sẽ được dồn vào đâu. Nếu bạn đặt một rào kiểm tra của con người vào một hệ thống vốn di chuyển với tốc độ máy móc, đừng ngạc nhiên nếu điều đó ảnh hưởng đến năng suất. Sự chú ý của con người là khan hiếm và quý giá, vì vậy chúng ta nên chủ động hướng nó vào những vấn đề tinh tế nhất đòi hỏi sự phán đoán của chúng ta. Những người ở khâu sau chỉ nên được kéo vào khi các rào chắn tự động cho ràng buộc bị phá vỡ.
"Code review" của con người trong tương lai sẽ trông rất khác biệt
Tính đúng đắn là một khía cạnh quan trọng, nhưng bạn có thể cũng quan tâm đến những khía cạnh khác, như khả năng bảo trì, hiệu suất, bảo mật, hiệu quả và tính dễ hiểu. Cũng giống như tính đúng đắn phân rã thành nhiều loại tín hiệu, các phần còn lại của chất lượng cũng vậy. Và dù số lượng ràng buộc chúng ta có là quan trọng, điều quan trọng hơn là liệu chúng có đủ thách thức để đáp ứng tiêu chuẩn chất lượng và mức độ sẵn sàng production của chúng ta hay không.
Chất lượng phần mềm không phải là một chỉ số duy nhất. Hãy coi nó như một tập hợp các tín hiệu có mức độ quan trọng khác nhau đối với bạn và nhóm của bạn.
Áp lực ngược (back-pressure) có thể được triển khai qua nhiều công cụ: trình biên dịch từ chối code không hợp lệ, các bài kiểm thử thất bại, các chính sách bảo mật chặn những thói quen xấu, CI từ chối triển khai. Lý tưởng nhất là nó tồn tại xuyên suốt vòng lặp, chứ không phải chỉ là một lần review duy nhất ở cuối mọi công việc.
Bản đồ của Dex Horthy về cùng một vòng lặp, trích từ Why Software Factories Fail. Khối màu xanh lá là luận điểm của anh ấy rằng hiện tại việc review của con người cần được đưa trở lại vòng lặp chứ không phải bị vòng lặp thay thế.
Các ràng buộc và áp lực ngược giúp agent phát hiện ra công việc kém chất lượng trước khi nó trở thành vấn đề
Điều gì xảy ra nếu chúng ta không thể áp dụng ràng buộc vì khối lượng thay đổi lớn hơn mức công cụ của chúng ta có thể xử lý? Chúng ta sẽ phải xây dựng một hàng đợi và dựa vào một hệ thống xác minh di chuyển với tốc độ của con người. Để mở rộng quy mô, chúng ta muốn đẩy càng nhiều thứ càng tốt vào vòng lặp xác minh trong suốt quá trình, chứ không phải chờ đến cuối. Nếu chúng ta có thể mở rộng quy mô trong các bài kiểm tra tự động của mình, chúng ta có thể tăng tốc độ và thông lượng của toàn bộ hệ thống phân phối. Nếu chúng ta hết chỗ trong vòng lặp xác minh, chúng ta cần phải làm một trong nhiều điều sau.
Thứ nhất, chúng ta có thể mở rộng hệ thống xác minh và tạo thêm năng lực để ràng buộc và đẩy lùi các thay đổi đến. Thứ hai, chúng ta có thể giảm tốc độ tạo ra các thay đổi mới của các agent để việc xác minh có thể bắt kịp khối lượng công việc. Thứ ba, chúng ta có thể hạ tiêu chuẩn chất lượng để việc xác minh không phản đối gay gắt như bình thường. Từ góc độ mở rộng quy mô, chúng ta cần sẵn sàng làm tất cả những điều này. Đồng thời, chúng ta không nên dừng lại mà không nhận ra rằng chúng ta thực sự có thể làm được nhiều hơn bằng cách nới lỏng ràng buộc ở một số hướng. Có lẽ chúng ta có thể tăng tốc độ tạo thay đổi của agent bằng cách cung cấp hàng loạt nhà phát triển agent hoặc các nhà máy phần mềm tự động để tạo ra các thay đổi mà không cần chờ chúng ta review từng cái.
Và ở một số nơi, chúng ta có thể muốn trao cho chúng nhiều tự do hơn, miễn là chúng ta giữ các ràng buộc chặt chẽ hơn ở những nơi khác. Bằng cách áp dụng các ràng buộc chặt chẽ hơn ở những nơi chúng ta quan tâm nhất, chúng ta có thể tối đa hóa thông lượng mà không hy sinh chất lượng. Trong suốt quá trình ra quyết định này, có rất nhiều lựa chọn. Rõ ràng nhất là chúng ta phải đánh đổi giữa các khía cạnh chất lượng khác nhau. Như chúng ta đã nhấn mạnh, bảo mật rất quan trọng, nhưng chúng ta cũng phải đánh đổi giữa việc cung cấp bảo mật và việc giao sản phẩm đúng hạn. Có một dải phổ từ đầu tập trung vào đổi mới đến đầu kia tập trung vào chất lượng. Trên hành trình đó, chúng ta phải lựa chọn vị trí mà mình muốn đứng trên dải phổ này.
Chúng ta muốn gửi phản hồi rõ ràng từ môi trường và hệ thống trở lại cho các agent hoặc đội ngũ của mình, để mọi người có thể tập trung vào những mối quan tâm mang tính chủ quan hơn như thẩm mỹ, ý định và kiến trúc. Nếu chúng ta có thể giúp con người ở trong phạm vi an toàn của các ràng buộc, chúng ta có thể tránh cho họ phải vất vả tìm hiểu xem mọi thứ đã sai ở đâu.
Chất lượng phần mềm không chỉ bao gồm tính đúng đắn. Chất lượng phần mềm còn có nghĩa là khả năng bảo trì, hiệu suất tốt, bảo mật, hiệu quả và dễ hiểu. Tất cả các ràng buộc giúp chúng ta đáp ứng những tiêu chuẩn này và giữ cho production vận hành trôi chảy đều tạo ra áp lực ngược trong đường ống phân phối của chúng ta.
Chúng ta cần đưa ra những quyết định có chủ đích về nơi áp dụng các ràng buộc mạnh và nơi gỡ bỏ hoặc nới lỏng chúng. Hãy áp dụng các ràng buộc mạnh ở những nơi chúng phục vụ cả hai mục tiêu này. Đừng duy trì chúng nếu chúng không phục vụ một hoặc cả hai mục tiêu. Hãy sẵn sàng nâng cao hoặc hạ thấp tiêu chuẩn tùy theo tình huống. Và hãy nhớ rằng chính các ràng buộc tại những điểm khác nhau trong hệ thống phần mềm là thứ làm cho chất lượng phần mềm có thể được thực thi.
Chúng ta nên áp dụng các ràng buộc mạnh ở những nơi chúng phục vụ tốt nhất mục đích kép này và cân nhắc gỡ bỏ hoặc nới lỏng những ràng buộc không phục vụ tốt mục đích nào. Chúng ta cũng nên sẵn sàng nâng hoặc hạ tiêu chuẩn chất lượng khi cần. Thực chất, chính những ràng buộc ở nhiều điểm khác nhau trong hệ thống phần mềm là thứ tạo nên sức nặng cho chất lượng. Trong nhiều trường hợp, chúng ta có thể tạo thêm áp lực ngược và nhiều ràng buộc hơn bằng cách triển khai các công cụ mới hoặc củng cố các công cụ hiện có. Tất cả những điều này đều có thể dùng để đẩy lùi hầu hết các yêu cầu thay đổi. Chúng ta muốn xây dựng chúng xuyên suốt toàn bộ đường ống.
Chúng ta không muốn chờ đến cuối đường ống khi hệ thống CI chỉ đơn giản nói với chúng ta rằng chúng ta không được phép triển khai nếu chưa sửa các vấn đề. Chúng ta muốn sử dụng những tín hiệu này càng sớm càng tốt, qua mọi con đường có thể. Ràng buộc cuối cùng trong hệ thống này là ràng buộc chúng ta đặt lên chính mình: đứng sau những quyết định và hành động mà chúng ta đã thực hiện để xây dựng và vận hành hệ thống. Nhưng giống như mọi ràng buộc khác, chúng ta cần có những sự đánh đổi thấu đáo về việc chúng ta muốn sự phán đoán của chính mình kiềm chế, tạo áp lực ngược và đóng vai trò kiểm tra cuối cùng đến mức nào.
Chất lượng nằm ở những ràng buộc chúng ta đặt xung quanh các agent của mình. Vì vậy, khi bạn đang suy nghĩ về chất lượng cho ứng dụng của riêng mình, hãy lấy phát biểu vấn đề này và xây dựng kế hoạch dựa trên ràng buộc của riêng bạn.
Nhắc đến chất lượng, các agent đang viết code của bạn. [Sonar](https://fandf.co/45bRKE8) cung cấp cho bạn các quality gate để giúp code sẵn sàng phát hành. Nó chạy cùng một bài kiểm tra hoàn chỉnh trên mỗi commit: phân tích sâu xuyên tệp (cross-file analysis), bản đồ xác định nơi rủi ro tập trung, và một quality gate giữ mọi con người và agent ở cùng một tiêu chuẩn.
Bài viết này được đánh giá là 100% do con người viết bởi Pangram 4.
