Quy trình refractor code và tối ưu thời gian xử lý API

• Chương 1: Đặt vấn đề
• 1.1. Bối cảnh hệ thống
• 1.2. Mục tiêu của việc refactor và tối ưu API
• Chương 2: Nguyên tắc refactor code
• 2.1. Không thay đổi hành vi nghiệp vụ của hệ thống
• 2.2. Thực hiện refactor theo từng bước nhỏ
• 2.3. Đảm bảo khả năng kiểm thử sau khi refactor
• Chương 3: Triển khai
• 3.1. Triển khai refractor code
• 3.2. Cấu trúc promt và ví dụ

Chương 1: Đặt vấn đề

1.1. Bối cảnh hệ thống

Trong quá trình phát triển phần mềm, hệ thống API thường trải qua nhiều giai đoạn mở rộng chức năng, sửa lỗi và bổ sung nghiệp vụ. Việc thay đổi liên tục có thể dẫn đến:

- Logic xử lý trở nên phức tạp và khó bảo trì

- Code trùng lặp giữa nhiều module

- Query database không tối ưu

- Thời gian phản hồi API tăng dần theo thời gian

Các vấn đề này ảnh hưởng trực tiếp đến:

- Hiệu năng hệ thống

- Khả năng mở rộng

- Trải nghiệm người dùng

- Chi phí vận hành hệ thống

1.2. Mục tiêu của việc refactor và tối ưu API

Cải thiện hiệu năng

- Giảm thời gian phản hồi API

- Giảm tải cho database

Tăng khả năng bảo trì

- Tách rõ logic nghiệp vụ

- Giảm code trùng lặp

- Chuẩn hóa cấu trúc code

Tăng khả năng mở rộng hệ thống

- Dễ bổ sung chức năng mới

- Hạn chế ảnh hưởng dây chuyền khi thay đổi code

Đảm bảo tính ổn định

- Giữ nguyên behavior của API sau khi refactor

- Kiểm soát lỗi thông qua test và logging

Chương 2: Nguyên tắc refactor code

2.1. Không thay đổi hành vi nghiệp vụ của hệ thống

Nguyên tắc quan trọng nhất của refactor là không làm thay đổi logic nghiệp vụ hoặc kết quả xử lý của hệ thống. Mọi thay đổi trong quá trình refactor chỉ nhằm cải thiện cấu trúc code, giảm độ phức tạp và tăng hiệu năng.

Trước và sau khi refactor, API phải đảm bảo:

- Trả về cùng một cấu trúc dữ liệu

- Giữ nguyên logic xử lý nghiệp vụ

- Không làm thay đổi dữ liệu hệ thống

2.2. Thực hiện refactor theo từng bước nhỏ

Refactor nên được thực hiện theo các thay đổi nhỏ, có kiểm soát, thay vì thay đổi lớn trong một lần. Điều này giúp dễ dàng kiểm tra và phát hiện lỗi.

Quy trình thường bao gồm:

1. Xác định vấn đề trong code

2. Refactor một phần nhỏ của hệ thống

3. Kiểm thử lại chức năng

4. Đánh giá hiệu năng

5. Tiếp tục refactor các phần tiếp theo

Cách tiếp cận này giúp giảm rủi ro và đảm bảo hệ thống luôn hoạt động ổn định trong quá trình cải tiến.

2.3. Đảm bảo khả năng kiểm thử sau khi refactor

Sau mỗi lần refactor, cần thực hiện kiểm thử để đảm bảo hệ thống vẫn hoạt động đúng như trước. Việc kiểm thử có thể bao gồm:

• Kiểm thử chức năng API

• So sánh dữ liệu trả về trước và sau refactor

• Kiểm tra thời gian xử lý API

• Kiểm tra log hệ thống

Kiểm thử giúp phát hiện sớm các lỗi có thể phát sinh trong quá trình tái cấu trúc code.

Chương 3: Triển khai

3.1. Triển khai refractor code

1. Phân tích logic xử lý của hàm

Ở bước đầu tiên, cần yêu cầu công cụ AI hoặc lập trình viên thực hiện phân tích chi tiết logic xử lý của hàm cần tối ưu. Mục tiêu của bước này là:

- Hiểu rõ toàn bộ luồng xử lý của hàm

- Xác định các bước xử lý chính

- Phân tách các giai đoạn xử lý logic thành các phần độc lập

2. Đánh giá kết quả phân tích

Sau khi AI hoặc lập trình viên đưa ra kết quả phân tích, cần thực hiện bước đánh giá để xác nhận tính hợp lý của việc phân tách logic.

Việc đánh giá cần tập trung vào các yếu tố sau:

- Các phase có phản ánh đúng luồng xử lý của hệ thống hay không

- Mỗi phase có một trách nhiệm rõ ràng hay không

 - Có phase nào bị trùng lặp logic hay không

- Có phase nào quá lớn hoặc quá phức tạp hay không

Nếu kết quả phân tích được đánh giá là hợp lý và phù hợp với kiến trúc hệ thống, quy trình sẽ chuyển sang bước refactor mã nguồn.

3. Refactor mã nguồn theo các phase xử lý

Ở bước này, tiến hành tái cấu trúc mã nguồn dựa trên các phase đã được xác định ở bước phân tích.

Quy trình thực hiện gồm:

- Tạo các hàm riêng biệt tương ứng với từng phase xử lý đã được xác định trước đó.

- Di chuyển logic xử lý tương ứng từ hàm gốc sang các hàm mới được tạo.

- Đảm bảo mỗi hàm chỉ thực hiện một nhiệm vụ cụ thể trong quy trình xử lý.

- Bổ sung cơ chế ghi log thời gian xử lý của từng hàm để phục vụ việc đánh giá hiệu năng sau này.

4. Kiểm thử chức năng sau khi refactor

Sau khi hoàn thành việc refactor, cần thực hiện kiểm thử lại toàn bộ chức năng để đảm bảo:

- Logic xử lý không bị thay đổi

- Kết quả trả về của API vẫn giống với phiên bản trước khi refactor

- Không phát sinh lỗi nghiệp vụ hoặc lỗi hệ thống

5. Đánh giá thời gian xử lý của từng hàm

Sau khi hệ thống hoạt động ổn định với cấu trúc code mới, cần tiến hành đo lường và đánh giá thời gian xử lý của từng hàm đã được tách ra.

Thông tin thời gian xử lý được thu thập thông qua các log đã được bổ sung ở bước refactor.

Mục tiêu của bước này là:

- Xác định các hàm có thời gian xử lý lớn

- Xác định các điểm nghẽn hiệu năng trong hệ thống

- Ưu tiên các phần cần tối ưu trước

6. Lặp lại quy trình phân tích đối với các hàm có thời gian xử lý lớn

Đối với các hàm được xác định là chiếm nhiều thời gian xử lý, quy trình phân tích và refactor sẽ được áp dụng lại ở cấp độ chi tiết hơn.

3.2. Cấu trúc promt và ví dụ

3.2.1. Các bước thực hiện

Bước 1: Yêu cầu AI thực hiện yêu cầu sau: 
"Phân tích logic xử lý của hàm listDocumentsMainProcessDynamic, chia hàm thành các bước xử lý sau đó đề xuất phương án tối ưu thời gian xử lý"

Bước 2: Đánh giá kết quả phân tích của AI, nếu hợp lý chuyển sang bước 3

Bước 3: Yêu cầu AI thực hiện yêu cầu sau:  
"tôi đồng ý với 10 phases bạn phân tích,bây giờ tôi cần bạn refractor lại code của hàm listDocumentsMainProcessDynamic, với nguyên tắc như sau:
bạn hãy viết 10 func tương ứng với 10 phase, sau đó move các logic tương ứng vào 10 func đó. sau đó sửa lại hàm listDocumentsMainProcessDynamic để chỉ gọi 10 func bạn vừa tạo ra, đảm bảo logic xử lý như cũ và bổ xung các log time xử lý của từng func ở trong chính các func vừa tạo"

Bước 4: Test lại chức năng sau khi refractor

Bước 5: Đánh gia thời gian xử lý của từng func, ưu tiên các func chiếm tỉ trọng thời gian xử lý lớn

Bước 6: Thực hiện lại từ bước 1 đến bước 5 đối với từng func mà bước 5 chọn được

Bước 7: Thực hiện tối ưu từng func sau khi đã refractor

3.2.2. Kết quả

Trước khi refractor

Sau khi refractor