Giới thiệu

Khi thực hiện các thay đổi trong mã nguồn của bạn, rất dễ dàng để vô tình làm hỏng chức năng hiện tại trong khi triển khai các tính năng mới hoặc sửa lỗi. Oracle trong Amp xuất sắc trong việc phân tích các thay đổi mã và xác định các lỗi tiềm ẩn mà có thể không rõ ràng từ một đánh giá diff đơn giản.

Hướng dẫn này sẽ đi qua một kịch bản thực tế nơi chúng ta sẽ thực hiện các thay đổi đối với một ứng dụng đơn giản, sau đó sử dụng Oracle để phát hiện và sửa bất kỳ lỗi nào trong chức năng cốt lõi.

Ứng dụng ví dụ của chúng ta

Để thực hiện hướng dẫn này, chúng ta sẽ sử dụng một API quản lý nhiệm vụ đơn giản. Đây là logic hoàn thành nhiệm vụ cốt lõi mà chúng ta muốn bảo vệ:

// server.js - Chức năng chính mà chúng tôi đang theo dõi
app.patch('/tasks/:id/complete', (req, res) => {
  const taskId = parseInt(req.params.id);
  const task = tasks.find(t => t.id === taskId);

  if (!task) {
    return res.status(404).json({ error: 'Nhiệm vụ không tồn tại' });
  }

  task.completed = true;
  task.completedAt = new Date();
  res.json(task);
});

Với mã trên, giả sử chúng ta đã cam kết phiên bản hoạt động này làm cơ sở trong git.

Thực hiện các thay đổi có thể gây ra lỗi

Theo quy trình phát triển thông thường, chúng ta sẽ lấy mã PoC cơ sở và bắt đầu cải tiến nó. Giả sử chúng ta đang tìm cách thêm khả năng chỉnh sửa nhiệm vụ và cải thiện tính xác thực. Dưới đây là những thay đổi chính mà chúng ta có thể thực hiện đối với logic hoàn thành:

// Hàm xác thực cải tiến (MỚI)
function validateTask(title, priority) {
  const validPriorities = ['low', 'medium', 'high', 'urgent'];
  if (!title || title.trim().length === 0) return 'Tiêu đề là bắt buộc';
  if (priority && !validPriorities.includes(priority)) return 'Độ ưu tiên không hợp lệ';
  return null;
}

// Cập nhật chức năng hoàn thành nhiệm vụ với xác thực mới
app.patch('/tasks/:id/complete', (req, res) => {
  const taskId = parseInt(req.params.id);
  const task = tasks.find(t => t.id === taskId);

  if (!task) {
    return res.status(404).json({ error: 'Nhiệm vụ không tồn tại' });
  }

  // MỚI: Ngăn chặn việc hoàn thành nhiều lần
  if (task.completed) {
    return res.status(409).json({ error: 'Nhiệm vụ đã hoàn thành' });
  }

  task.completed = true;
  task.completedAt = new Date().toISOString(); // Đã thay đổi định dạng
  res.json(task);
});

Với những thay đổi này, chúng ta sẽ cam kết các thay đổi trong git, có thể thực hiện thủ công hoặc qua Amp:

Sử dụng Oracle để phát hiện lỗi

Bây giờ chúng ta muốn đảm bảo rằng những thay đổi của chúng ta không làm hỏng chức năng hoàn thành nhiệm vụ cốt lõi. Hãy yêu cầu Oracle phân tích các thay đổi của chúng ta. Đây là prompt của chúng ta cho Amp, sẽ kích hoạt Oracle bắt đầu phân tích:

Sử dụng oracle để xem xét các thay đổi của commit cuối cùng. Tôi muốn đảm bảo rằng logic thực tế cho việc hoàn thành nhiệm vụ không thay đổi và vẫn hoạt động như trước đây.

Sau đó, trong Amp, chúng ta sẽ thấy Oracle bắt đầu công việc của mình.

Phản hồi của Oracle: Không phát hiện lỗi

Trong trường hợp mã mà chúng ta đã thêm, chúng ta biết rằng logic cho việc hoàn thành nhiệm vụ vẫn nguyên vẹn và không gặp vấn đề về lỗi. Đầu ra của Oracle xác nhận điều này:

Phản hồi của Oracle: Phát hiện lỗi

Nhưng nếu những thay đổi của chúng ta đã giới thiệu một lỗi? Hãy tưởng tượng rằng chúng ta đã vô tình thêm thay đổi vấn đề này vào mã của mình:

// Phiên bản có vấn đề làm hỏng việc hoàn thành nhiệm vụ
app.patch('/tasks/:id/complete', (req, res) => {
  const taskId = req.params.id; // BUG: Thiếu parseInt()
  const task = tasks.find(t => t.id === taskId);

  if (!task) {
    return res.status(404).json({ error: 'Nhiệm vụ không tồn tại' });
  }

  task.completed = true;
  task.completedAt = new Date().toISOString();
  res.json(task);
});

Thay đổi dường như nhỏ này tạo ra một lỗi nghiêm trọng mà dễ dàng bị bỏ qua trong việc xem xét mã. Khi một yêu cầu đến /tasks/1/complete, req.params.id trả về chuỗi "1", không phải số nguyên 1. Các ID nhiệm vụ của chúng ta được lưu trữ dưới dạng số nguyên trong mảng.

Dòng tasks.find(t => t.id === taskId) bây giờ so sánh số nguyên 1 với chuỗi "1". Do sự so sánh nghiêm ngặt của JavaScript (===), so sánh này luôn trả về false, khiến hàm không thể tìm thấy bất kỳ nhiệm vụ nào, bất kể nó có tồn tại hay không. Hãy sử dụng Amp để đẩy mã này lên git.

Đây chính xác là loại lỗi tinh vi mà Oracle xuất sắc trong việc phát hiện: một thay đổi có vẻ vô hại nhưng hoàn toàn làm hỏng chức năng thông qua các tương tác hệ thống kiểu. Nếu không chạy mã và kiểm tra nó, các reviewer có thể không nhận thấy điều này ngay lập tức. Như một dòng phòng ngừa lỗi bổ sung, hãy một lần nữa chạy Oracle để chứng minh rằng nó có thể tìm thấy loại lỗi này:

Bây giờ, chúng ta có thể thấy rằng Oracle đã phát hiện ra vấn đề và cũng đã đưa ra một đề xuất sửa lỗi. Vì Oracle là chỉ đọc, chúng ta sẽ cần yêu cầu đại lý Amp sửa lỗi này cho chúng ta.

Sử dụng Amp để sửa lỗi đã phát hiện

Khi Oracle phát hiện một lỗi, chúng ta có thể ngay lập tức yêu cầu Amp sửa nó. Trong trường hợp cụ thể của chúng ta ở trên, chúng ta có thể sử dụng prompt sau:

Oracle đã phát hiện lỗi trong việc hoàn thành nhiệm vụ do thiếu parseInt(). Vui lòng sửa vấn đề này trong khi giữ lại tất cả các cải tiến khác mà chúng ta đã thực hiện trong commit cuối cùng.

Từ đây, Amp bắt đầu công việc sửa chữa lỗi:

Amp sau đó khôi phục chuyển đổi kiểu đúng, kiểm tra endpoint đã sửa, và sau đó cam kết sửa lỗi vào git.

Sau đó, Amp đưa ra một thông báo cuối cùng cho chúng ta biết rằng mã đã được cam kết và sửa chữa. Điều này cho thấy cách chúng ta có thể sử dụng Oracle để xác định các lỗi tiềm năng và cách sử dụng Amp để giải quyết chúng, đảm bảo mọi thứ hoạt động như mong muốn.

Thực hành tốt nhất cho việc phát hiện lỗi

Mặc dù Oracle rất thông minh, vẫn có một số thực hành tốt nhất khi phát hiện lỗi mà bạn sẽ muốn ghi nhớ. Oracle hiệu quả nhất khi bạn:

1. Cụ thể về chức năng cần kiểm tra: Thay vì "kiểm tra lỗi", hãy chỉ định "kiểm tra rằng logic xác thực người dùng không thay đổi."
2. Tập trung vào các đường dẫn quan trọng: Ưu tiên kiểm tra logic kinh doanh cốt lõi, mã nhạy cảm về bảo mật và các tính năng thường xuyên sử dụng.
3. Sử dụng sau các thao tác tái cấu trúc lớn: Oracle xuất sắc trong việc phát hiện những thay đổi tinh vi trong các thao tác tái cấu trúc phức tạp.
4. Kết hợp với kiểm thử: Sử dụng phân tích Oracle cùng với bộ kiểm thử hiện có của bạn để có sự bao quát toàn diện.
5. Hỏi các câu hỏi theo dõi: Nếu Oracle phát hiện vấn đề, hãy hỏi về các đề xuất sửa chữa cụ thể hoặc phân tích tác động.

Khi nào sử dụng Oracle cho phân tích lỗi

Tình huống lý tưởng:

• Sau các thao tác tái cấu trúc lớn
• Khi sửa đổi các tiện ích chung hoặc logic kinh doanh cốt lõi
• Trước khi triển khai các sửa chữa quan trọng đến sản xuất
• Khi nhiều nhà phát triển đã làm việc trên mã liên quan

Ít phù hợp hơn cho:

• Các thay đổi đơn giản, tách biệt
• Các tính năng hoàn toàn bổ sung không ảnh hưởng đến mã hiện có
• Các thay đổi đã có sự bao phủ kiểm thử toàn diện

Oracle chuyển đổi việc phát hiện lỗi thành một quy trình phân tích có hệ thống, giúp phát hiện các vấn đề trước khi chúng đến sản xuất.