1.5K 33 196

Đã đăng vào thg 6 19, 2:39 SA 12 phút đọc

170

Xây dựng hệ thống quản lý tác vụ với Claude Code

Sau vài tháng làm việc với Claude Code trong một ứng dụng web phức tạp, tôi nhận ra mình thường xuyên lặp lại cùng một quy trình: đọc các issue trên Linear, phân rã chúng thành các phần có thể triển khai, rồi cẩn thận phối hợp các thay đổi trên API, ứng dụng web và các tác vụ nền.

Quy trình thủ công này tiêu tốn rất nhiều thời gian – thời gian mà tôi muốn dành cho các quyết định kiến trúc và giải các vấn đề thú vị. Vì vậy, tôi đã xây dựng một quy trình gồm hai lệnh đơn giản để xử lý phần việc hệ thống, nhường chỗ cho tôi tập trung vào các khía cạnh cần đến tư duy con người.

Thách thức: Mã nguồn thực tế thường rất lộn xộn

Khi làm việc với một ứng dụng có quy mô đáng kể, bạn sẽ phải đối mặt với:

Hơn 50 file có liên kết chặt chẽ giữa các service
Các mẫu kiến trúc cần đảm bảo tính nhất quán
Quy trình chạy nền (chúng tôi dùng Temporal.io)
Các thay đổi về API và lược đồ cơ sở dữ liệu
Yêu cầu kiểm thử trên nhiều thành phần khác nhau
Tích hợp với Linear, GitHub và quy trình triển khai

Khoảng cách giữa “đây là một issue trên Linear” và “đây là tính năng đã hoạt động” đòi hỏi rất nhiều công việc có tính hệ thống – quan trọng nhưng không sáng tạo.

Giải pháp: Hai lệnh tuỳ chỉnh

Tôi đã xây dựng hai lệnh hoạt động song song với nhau:

`breakdown-linear-issue` – Phân rã tác vụ

Lệnh này đọc một issue trên Linear và tạo ra kế hoạch triển khai. Nó tự động hóa giai đoạn phân tích mà tôi thường làm thủ công:

Phân tích mô tả issue và tiêu chí chấp nhận
Ánh xạ yêu cầu vào cấu trúc mã nguồn hiện tại
Xác định các file và dịch vụ cần thay đổi
Tạo chuỗi các tác vụ có thể triển khai
Ghi chú yêu cầu kiểm thử và các rủi ro có thể phát sinh

Kết quả là một file Markdown chứa các tác vụ cụ thể có thể được thực hiện độc lập.

`process-task` – Thực thi

Lệnh này nhận một file tác vụ và thực hiện:

Đọc đặc tả nhiệm vụ
Phân tích trạng thái hiện tại của các file liên quan
Thực hiện thay đổi theo đúng mẫu thiết kế của nhóm
Chạy test và sửa các lỗi cơ bản
Tạo commit với thông điệp mô tả rõ ràng

Ý tưởng cốt lõi: tách biệt giữa lập kế hoạch và thực thi.

Việc lập kế hoạch cần cái nhìn tổng thể, còn thực thi hiệu quả hơn khi tập trung vào từng phần riêng biệt.

Ví dụ thực tế: Thêm tính năng thông báo qua email

Hãy cùng xem tính năng tôi đã triển khai tháng trước.

Issue trên Linear: “Người dùng nên nhận email thông báo khi một số điều kiện được thỏa mãn, với tần suất khác nhau tùy theo cấp độ đăng ký.”

Bước 1: Phân tích chiến lược

/breakdown-linear-issue DEV-123

Lệnh này phân tích codebase và phát hiện rằng đây không chỉ đơn thuần là “thêm chức năng gửi email” mà liên quan đến:

Thay đổi lược đồ database (ngưỡng thông báo, tùy chọn người dùng)
Điều chỉnh workflow Temporal (tác vụ nền)
Thêm endpoint API để quản lý thông báo
Tích hợp với hệ thống mẫu email
Xác thực theo cấp độ đăng ký
Giới hạn tốc độ theo loại người dùng
Thêm UI trên frontend để cấu hình thông báo
Kiểm thử toàn diện trên mọi thành phần

Nó tạo ra 8 tác vụ riêng biệt với thứ tự phụ thuộc rõ ràng và phạm vi ước lượng.

Bước 2: Thực thi hệ thống

/process-task implement-notification-database-schema
/process-task implement-notification-workflow-system
/process-task implement-notification-api-endpoints
# ... và tiếp tục các task còn lại

Mỗi lệnh thực hiện phần việc của mình mà vẫn nhận thức được toàn bộ hệ thống.

Khi tạo API, nó tự động dùng middleware xác thực, mẫu kiểm tra dữ liệu, và chuẩn xử lý lỗi hiện có của chúng tôi.

Tại sao cách này hiệu quả?

1. Hiểu biết kiến trúc

Các lệnh này nắm rõ stack và quy ước của nhóm:

Fastify + Prisma + Temporal.io
Tích hợp với Auth0
Lớp trừu tượng dịch vụ
Yêu cầu test (>50% coverage API, >90% service)

2. Giữ ngữ cảnh

Không như AI hội thoại dễ quên bối cảnh, các lệnh này:

Nhớ phần đã được triển khai
Biết các thay đổi đang diễn ra
Hiểu tính năng nằm ở đâu trong roadmap tổng thể
Tuân thủ yêu cầu chất lượng mã nguồn cụ thể của nhóm

3. Kỷ luật trong thực thi

Quy trình 2 bước giúp tránh sai lầm phổ biến: nhảy vào code mà chưa hiểu đầy đủ vấn đề.

Bước phân tích buộc tôi phải cân nhắc toàn bộ phạm vi trước khi bắt đầu.

Quy trình tổng thể

Chu trình phát triển điển hình của tôi:

Linear issue được tạo (từ PM hoặc phản hồi người dùng)
Phân tích chiến lược: breakdown-linear-issue để hiểu toàn cảnh
Xem lại & điều chỉnh: tôi rà lại, thay đổi ưu tiên, chia nhỏ nếu cần
Thực thi có hệ thống: dùng process-task cho từng tác vụ con
Kiểm thử tích hợp: chạy bộ test E2E
Code review: tạo PR với đầy đủ ngữ cảnh

🔑 Tôi không thay thế tư duy kỹ sư, tôi hệ thống hóa cách thực thi tư duy đó.

Kỹ thuật triển khai (cho kỹ sư)

Các lệnh này hoạt động thông qua tích hợp MCP (Model Context Protocol) của Claude Code:

API Linear: đọc issue, cập nhật trạng thái
API GitHub: quản lý branch, PR, phân tích code
Bộ nhớ ngữ cảnh: duy trì hiểu biết xuyên suốt các lần gọi lệnh

Chúng không chỉ là script — mà là các workflow AI hiểu codebase cụ thể và thích ứng theo yêu cầu.

Hiệu quả ra sao?

1. Chất lượng phân rã tác vụ (`breakdown-linear-issue`)

Tôi theo dõi:

So sánh giữa kế hoạch ban đầu và triển khai thực tế
Liệu có bỏ sót thành phần lớn nào không
Ước lượng có chính xác không

Tỷ lệ thành công:

~95% đủ chính xác để triển khai trực tiếp

~5% còn lại thường do:

Các edge case lộ ra khi triển khai
Phụ thuộc vào hệ thống khác không rõ ràng trong issue

Thường thất bại ở:

Phức tạp frontend (responsive phức tạp)
Quyền truy cập/ủy quyền bị bỏ sót

Làm tốt ở:

Thay đổi database
Cấu trúc endpoint API
Phạm vi test

2. Chất lượng thực thi (`process-task`)

Tôi theo dõi:

Mức độ code tạo ra được dùng trực tiếp
Tỷ lệ pass test
Phản hồi từ code review

Tỷ lệ thành công lần đầu: ~85%

Sửa nhỏ (import thiếu, test chưa đúng): ~10%

Cần viết lại đáng kể: ~5%

Lần chạy thứ hai (qua Gemini review): đạt ~95% thành công

Làm tốt ở:

Tuân thủ mẫu sẵn có (auth, validation, error)
Viết test phù hợp và đầy đủ
Giữ sự nhất quán giữa các component

Gặp khó ở:

UI/UX không được mô tả rõ trong task

Đo lường tác động

Tôi bắt đầu theo dõi từ tháng đầu tiên:

1. Tốc độ phát triển

~1.5 tính năng/tuần (đơn giản)
1 tính năng/2 tuần (phức tạp)

~2 tính năng/tuần (đơn giản)
1.2 tính năng/tuần (phức tạp)

→ Tăng mạnh với tính năng tầm trung

2. Vòng review code

Trước: trung bình 2.3 vòng
Sau: 1.7 vòng

→ Ít comment kiểu “quên cập nhật test” hơn

3. Lỗi sản phẩm

Không thay đổi rõ rệt về tỷ lệ bug
Nhưng bug thường do logic nghiệp vụ, không phải do tích hợp

Nhìn nhận thực tế

Hệ thống này không phải phép màu. Nó giống như một lập trình viên junior cực kỳ tỉ mỉ:

Không bao giờ mệt khi làm checklist
Nhớ chính xác mọi quy ước trong code
Đôi khi “không thấy rừng vì mải nhìn cây”
Cần chỉ dẫn rõ ràng để làm việc hiệu quả

Giá trị lớn nhất: Sự nhất quán và kỹ lưỡng — chứ không phải sự sáng tạo.

Bức tranh lớn hơn

Không phải AI thay thế lập trình viên, mà là nâng tầm vấn đề chúng ta giải quyết.

Từ:

"Cấu trúc endpoint API này sao cho đúng?"
"Những file nào cần sửa?"
"Mình có cập nhật test chưa nhỉ?"

Đến:

"Trải nghiệm người dùng nào là hợp lý nhất?"
"Tính năng này nằm ở đâu trong chiến lược sản phẩm?"
"Kiến trúc nào bền vững nhất về lâu dài?"

Bắt đầu xây workflow riêng

Nếu bạn muốn xây dựng hệ thống tương tự:

Xác định điểm đau – quyết định nào lặp đi lặp lại? bạn hay quên điều gì?
Chuẩn hóa mẫu code – tài liệu hóa quyết định kiến trúc, chuẩn code, yêu cầu test
Xây dần từng bước – bắt đầu với các lệnh đơn giản, mở rộng khi bạn học thêm
Đo lường tác động – theo dõi tốc độ, tỷ lệ bug, chỉ số nhất quán

Mục tiêu không phải là hệ thống AI hoành tráng — mà là một công cụ khiến bạn trở thành kỹ sư hiệu quả hơn.

Kết luận

Claude Code không phải là phép màu.

Nhưng nếu bạn đầu tư thời gian dạy nó các mẫu code cụ thể và xây dựng các workflow có hệ thống, nó trở nên cực kỳ mạnh mẽ.

Các lệnh tôi xây dựng không chỉ là công cụ tăng năng suất — chúng là cách để mã hóa và mở rộng các thực hành tốt nhất trong kỹ thuật phần mềm.

Chúng giúp tôi làm việc có hệ thống hơn, kỹ lưỡng hơn, và nhất quán hơn.

Claude