Cách an toàn để đưa một hệ thống cũ sang kiến trúc hay công nghệ mới là thay thế từng phần trong khi hệ thống cũ vẫn chạy, chứ không dừng lại viết lại toàn bộ. Martin Fowler đặt tên cách làm này theo hình ảnh cây si, cây đa mọc bám quanh một cây chủ: rễ mới lớn dần, bao quanh, tới lúc cây cũ không còn cần nữa. Trong phần mềm, các tính năng mới và tính năng được chuyển đổi dần dần chạy trên phần mới, đến khi phần cũ chỉ còn trống rỗng và được gỡ đi.
Trợ lý AI làm cho cách tiếp cận này nhanh hơn ở nhiều khâu: lập bản đồ hệ thống cũ, đề xuất lát cắt nên chuyển trước, viết mã cho phần mới, viết công cụ so kết quả giữa hai bên. Nhưng AI cũng khiến cám dỗ viết lại toàn bộ trở nên mạnh hơn bao giờ hết, vì sinh mã mới quá dễ. Bài này giải thích vì sao nên cưỡng lại cám dỗ đó và làm từng phần thế nào.
Vì sao "để AI viết lại hết từ đầu" là cái bẫy
Với trợ lý AI, viết lại một ứng dụng nhỏ trong vài ngày trông hoàn toàn khả thi. Bản mới gọn gàng, dùng công nghệ hiện đại, chạy được giao diện chính. Vấn đề là hệ thống cũ không chỉ là phần giao diện chính. Nó chứa hàng trăm quy tắc nghiệp vụ nhỏ tích tụ qua nhiều năm: một khách hàng đặc biệt được giảm giá theo cách riêng, một loại hoá đơn phải làm tròn khác, một báo cáo cuối năm mà kế toán cần đúng định dạng. Những quy tắc đó thường không được ghi ở đâu ngoài mã, và người viết lại, dù là người hay AI, sẽ bỏ sót.
Khi viết lại toàn bộ, hệ thống cũ vẫn phải tiếp tục được sửa lỗi và thêm tính năng trong lúc chờ, nên bản mới luôn phải đuổi theo một mục tiêu đang chạy. Ngày chuyển đổi trở thành một cú nhảy lớn: mọi thứ đổi cùng lúc, có lỗi thì khó biết do đâu, quay lại thì tốn kém. Thay thế từng phần tránh được cả hai vấn đề: mỗi lát cắt nhỏ chuyển xong là chạy thật, có lỗi thì phạm vi hẹp, và hệ thống cũ teo dần thay vì phải chạy song song mãi.
Mẫu cây si hoạt động thế nào
Một lớp chặn phía trước. Đặt một điểm nhận mọi yêu cầu trước khi tới hệ thống cũ: bộ định tuyến của máy chủ web, một cổng giao diện lập trình, hay chỉ là một tệp định tuyến trong ứng dụng. Lớp này quyết định yêu cầu nào đi vào phần cũ, yêu cầu nào đi vào phần mới.
Chuyển từng lát cắt. Chọn một phần nhỏ, chẳng hạn một trang hay một nhóm giao diện lập trình, viết lại trên phần mới, rồi đổi lớp chặn để chuyển yêu cầu của phần đó sang. Phần còn lại vẫn chạy trên hệ thống cũ như chưa có gì xảy ra.
Đường lui luôn sẵn. Lát cắt mới có lỗi thì đổi lớp chặn quay lại hệ thống cũ, mất vài phút chứ không phải vài ngày.
Dữ liệu là phần khó nhất. Nếu phần mới và phần cũ dùng chung cơ sở dữ liệu, việc chuyển đơn giản hơn nhiều. Nếu phần mới cần cơ sở dữ liệu riêng, phải tính cách đồng bộ hai chiều trong giai đoạn chuyển tiếp, đây thường là chỗ tốn công nhất của cả dự án.
Gỡ phần cũ. Khi một vùng của hệ thống cũ không còn nhận yêu cầu nào, theo dõi thêm một thời gian rồi xoá. Bước này hay bị quên, để lại hai hệ thống chạy song song vô thời hạn.
Chọn lát cắt đầu tiên cùng AI
Lát cắt đầu tiên quyết định dự án có được tin tưởng tiếp hay không. Nó nên nhỏ, có giá trị thấy được, và ít dính líu. Quy trình gợi ý:
- Nhờ AI lập danh sách các vùng chức năng của hệ thống cũ cùng mức phụ thuộc giữa chúng, dựa trên bản đồ dự án và kết quả công cụ phân tích phụ thuộc nếu có.
- Với mỗi vùng, nhờ AI ước lượng ba thứ: số bảng dữ liệu nó ghi vào, số vùng khác gọi tới nó, mức độ được người dùng dùng thường xuyên. Bạn kiểm lại bằng mã và log.
- Chọn vùng ghi ít bảng, ít bị gọi tới, nhưng đủ được dùng để thấy kết quả. Trang chỉ đọc như tra cứu, báo cáo, danh sách thường là ứng viên tốt cho lát cắt đầu.
- Viết ra định nghĩa xong của lát cắt: phần mới trả kết quả giống phần cũ với cùng đầu vào, lớp chặn đã chuyển, theo dõi một thời gian không có lỗi, phần cũ tương ứng đã đánh dấu chờ gỡ.
- Đưa định nghĩa đó vào yêu cầu gửi cho AI khi viết phần mới, để nó biết thước đo là giống hệt hành vi cũ, không phải cải tiến.
Câu cuối cần nhấn mạnh. Khi viết phần mới, AI và cả người đều muốn sửa luôn những chỗ bất hợp lý của bản cũ. Hãy ghi lại những chỗ đó vào danh sách riêng. Lát cắt đầu tiên chỉ nhằm chứng minh chuyển được mà không ai nhận ra; cải tiến làm sau, khi đã có lưới an toàn ở phía mới.
So kết quả hai bên: công cụ quan trọng nhất của cả dự án
Làm sao biết phần mới cư xử giống phần cũ? Cách thuyết phục nhất là chạy cùng một yêu cầu qua cả hai và so kết quả. Với trang chỉ đọc, việc này đơn giản: một tập lệnh gửi cùng danh sách yêu cầu tới hai địa chỉ, chuẩn hoá phần thay đổi theo thời gian, rồi so từng phản hồi. AI viết nhanh loại tập lệnh này và giúp đọc các khác biệt khi chúng xuất hiện.
Với thao tác ghi dữ liệu, phải cẩn thận hơn. Một cách là chạy phần mới ở chế độ bóng: yêu cầu thật vẫn đi qua phần cũ và ghi dữ liệu thật, đồng thời một bản sao yêu cầu được gửi tới phần mới chạy trên cơ sở dữ liệu thử, kết quả hai bên được ghi lại để so. Cách này cần thiết kế cẩn thận để phần bóng không gửi thư, không gọi cổng thanh toán, không ghi gì ra ngoài.
Mọi khác biệt tìm được là thông tin quý: hoặc là lỗi của phần mới, hoặc là một quy tắc nghiệp vụ ẩn trong phần cũ mà chưa ai ghi lại. Ghi mỗi quy tắc tìm được vào tài liệu và thành kiểm thử ở phía mới. Sau vài lát cắt, bạn sẽ có thứ hệ thống cũ chưa từng có: bản mô tả quy tắc nghiệp vụ đã được kiểm chứng.
Những gì giao cho AI, những gì giữ cho người
Dự án chuyển đổi kéo dài nhiều tháng. Phân vai rõ giúp tận dụng AI mà không trao cho nó những quyết định nó không đủ thông tin để đưa ra.
| Việc | AI làm tốt | Người phải giữ |
|---|---|---|
| Lập bản đồ hệ thống cũ | Đọc mã, liệt kê vùng, vẽ sơ đồ dạng chữ | Xác nhận bằng log và hỏi người vận hành |
| Chọn thứ tự lát cắt | Ước lượng phụ thuộc, đề xuất phương án | Quyết định theo ưu tiên kinh doanh và rủi ro |
| Viết mã phần mới | Sinh mã theo khuôn đã chọn, viết kiểm thử | Rà mã, quyết định kiến trúc, giữ quy ước nhóm |
| So kết quả hai bên | Viết tập lệnh so, tóm tắt khác biệt | Phán định khác biệt là lỗi hay quy tắc nghiệp vụ |
| Đổi lớp chặn và gỡ phần cũ | Viết cấu hình, liệt kê những gì cần gỡ | Chọn thời điểm, theo dõi, chịu trách nhiệm |
Cột cuối có một điểm chung: những việc cần bối cảnh ngoài mã, như ưu tiên kinh doanh, thói quen người dùng, rủi ro chấp nhận được. AI không có các bối cảnh đó trừ khi bạn đưa vào, và kể cả khi đưa vào, trách nhiệm vẫn là của người.
Ví dụ giả định: trang tra cứu đơn hàng là lát cắt đầu
Một công ty phân phối nhỏ có hệ thống quản lý đơn viết bằng PHP từ hơn mười năm trước, chạy trên một máy chủ duy nhất. Nhóm quyết định chuyển dần sang một khung web hiện đại. Lát cắt đầu được chọn là trang tra cứu trạng thái đơn hàng cho nhân viên bán hàng: chỉ đọc, dùng hằng ngày, đọc từ ba bảng.
Lớp chặn là cấu hình máy chủ web: mọi đường dẫn bắt đầu bằng tiền tố tra cứu được chuyển sang ứng dụng mới, phần còn lại giữ nguyên. Ứng dụng mới đọc cùng cơ sở dữ liệu bằng tài khoản chỉ có quyền đọc. Trợ lý AI viết phần lớn mã của trang mới theo khuôn nhóm đã chọn, kèm kiểm thử.
Phần mất thời gian nhất lại là tập lệnh so kết quả. Chạy năm trăm mã đơn qua cả hai trang, tập lệnh tìm ra mười bảy đơn hiển thị trạng thái khác nhau. AI giúp nhóm các khác biệt: mười lăm đơn do bản cũ coi một giá trị trạng thái hiếm là "đang giao" trong khi bản mới hiểu là "huỷ", hai đơn do khác biệt cách hiển thị giờ. Cả hai là quy tắc ẩn mà không ai nhớ. Sau khi sửa, trang mới chạy song song một tuần, rồi lớp chặn được bật hẳn. Trang cũ được đánh dấu chờ gỡ, và hai quy tắc tìm được trở thành dòng đầu tiên trong tài liệu nghiệp vụ.
Khi nào không cần làm gì cả
Không phải hệ thống cũ nào cũng cần chuyển đổi. Một ứng dụng nội bộ chạy ổn, ít thay đổi, có người hiểu và sửa được khi cần, có thể tiếp tục chạy nhiều năm. Lý do chính đáng để chuyển thường là: công nghệ nền đã hết hỗ trợ bảo mật, không còn tuyển được người làm, hoặc mỗi tính năng mới tốn công gấp nhiều lần so với hợp lý. "Mã trông cũ" hay "AI viết lại được nhanh" không phải lý do đủ.
Nếu có lý do chính đáng, hãy bắt đầu nhỏ và đo kết quả sau lát cắt đầu: mất bao lâu, phát hiện bao nhiêu quy tắc ẩn, người dùng có nhận ra gì không. Con số đó cho bạn và người ra quyết định một ước lượng thực tế cho phần còn lại, thay vì một kế hoạch lạc quan viết trước khi chạm vào mã.
Câu hỏi thường gặp
Strangler fig pattern là gì?
Đây là cách thay thế hệ thống cũ từng phần: đặt một lớp chặn phía trước, chuyển dần từng tính năng sang phần mới, hệ thống cũ teo dần rồi được gỡ bỏ. Tên gọi lấy từ loại cây si, cây đa mọc bám và bao quanh cây chủ, do Martin Fowler đặt.
Có AI rồi thì viết lại toàn bộ có nhanh hơn không?
Phần viết mã nhanh hơn, nhưng phần khó nhất của viết lại là tìm ra mọi quy tắc nghiệp vụ ẩn trong hệ thống cũ, chuyển dữ liệu và chuyển người dùng. AI không làm biến mất các phần đó, nên rủi ro của một cú chuyển lớn vẫn còn nguyên.
Lát cắt đầu tiên nên lớn cỡ nào?
Đủ nhỏ để hoàn thành trong vài tuần và quay lại được trong vài phút nếu có lỗi. Trang chỉ đọc, báo cáo, tra cứu thường là lựa chọn tốt vì không ghi dữ liệu và dễ so kết quả hai bên.
Phần mới và phần cũ có nên dùng chung cơ sở dữ liệu không?
Giai đoạn đầu dùng chung giúp đơn giản hoá rất nhiều. Tách cơ sở dữ liệu là một bước riêng, làm sau khi đã chuyển đủ các tính năng đọc ghi một nhóm bảng. Tách sớm buộc phải đồng bộ hai chiều, phức tạp và dễ lỗi.
Làm sao thuyết phục quản lý chọn cách chuyển từng phần?
Đưa ra kế hoạch lát cắt đầu tiên với thời gian ngắn và kết quả đo được. Sau lát cắt đó, bạn có số liệu thật về tốc độ và rủi ro, thuyết phục hơn mọi ước lượng cho một dự án viết lại toàn bộ.