Biểu trưng ATRIMUT
ATRIMUT Công nghệ chính xác. Kết quả tin cậy.
VI RU 中文
Triết lý lập trình

Viết lại dự án từ đầu: vì sao mô hình quan trọng hơn công nghệ

Sau bài viết đầu tiên, tôi vẫn có cảm giác còn điều chưa nói hết. Tôi không yêu cầu viết lại bài ấy — làm vậy sẽ trái với điều tôi muốn nói — mà quyết định viết phần hai: về cuộc chạy đua theo cái mới.

Cỗ xe đang biến thành quả bí ngô; trên chiếc bàn bên cạnh là tờ giấy vẽ sơ đồ mô hình dữ liệu

“Hay là viết lại tất cả”

Trong bài viết đầu tiên, tôi đã nói rằng chương trình được tạo ra trên giấy. Lần này là câu chuyện xảy ra khi người ta bỏ qua tờ giấy ấy, nhưng lại rất muốn làm mọi thứ “theo cách mới”.

Kịch bản này quen thuộc với bất kỳ ai đã làm phát triển phần mềm hơn vài năm. Một đội ngũ mới bước vào dự án, tìm hiểu hệ thống, rồi chẳng bao lâu sau xuất hiện câu nói: “Hay là viết lại tất cả”.

Dĩ nhiên, công nghệ được đề xuất phải là thứ đang cực kỳ thời thượng. Thế kỷ trước, người ta đọc được nó trong sách; ngày nay, thường là vừa thấy trong một khóa học, hoặc đã dùng ở chỗ làm trước — và có vẻ dùng xong thì phải đổi việc.

Còn những câu hỏi như hệ thống làm gì, vì sao nó được thiết kế như vậy, hay tại sao bảng này lại liên kết với bảng kia, thì ít được đặt ra hơn nhiều. Người ta không nhìn vào gốc rễ.

Theo kịp xu hướng, nhưng đừng chạy đua

Tôi xin nói rõ ngay để khỏi bị xếp vào nhóm bảo thủ: theo kịp xu hướng, cập nhật thư viện và thay đổi công nghệ là điều cần thiết và đúng đắn. Mã nguồn không được cập nhật suốt nhiều năm cũng là một rủi ro: lỗ hổng bảo mật, người am hiểu hệ thống lần lượt rời đi, môi trường vận hành không còn tương thích.

Nhưng mọi việc đều cần sự hợp lý. Cập nhật là công cụ; mục tiêu là một hệ thống hoạt động được và giải quyết bài toán kinh doanh.

Vỏ đẹp nhưng thiếu phần cốt lõi

Nếu không hiểu miền nghiệp vụ, nhiều nhất bạn chỉ tạo được một lớp vỏ đẹp bằng công nghệ mới: giao diện nhanh, quy trình build hiện đại, các thành phần gọn gàng.

Mọi thứ đều ổn cho đến lúc phải đưa chức năng thực sự vào lớp vỏ ấy: nghiệp vụ ghi nhận, tính toán, các ngoại lệ và quy tắc đã tích lũy nhiều năm trong hệ thống cũ. Đó là lúc mọi thứ bắt đầu đổ vỡ. Không phải vì công nghệ kém, mà vì người ta không biết và không hiểu chính xác mình đang phát triển cái gì.

Đến hẹn lại hóa bí ngô

Còn một vấn đề thứ hai, ít dễ thấy hơn. Vài năm nữa, công nghệ mới sẽ không còn mới, và mã nguồn viết bằng nó sẽ hóa thành quả bí ngô — thành mã nguồn kế thừa, hay legacy. Hệt như mã nguồn hiện tại, thứ cũng từng ở đỉnh cao phổ biến vài năm trước.

Thế là hình thành một vòng lặp: hôm nay viết lại cái cũ bằng cái mới; vài năm sau, cái mới thành cái cũ; một đội ngũ khác xuất hiện — và lại vang lên câu: “Hay là viết lại tất cả”.

Tiền bạc và thời gian được dùng để thay lớp bao bì. Bản chất của hệ thống không vì thế mà tốt hơn hay dễ hiểu hơn.

Mô hình mới là thứ còn lại

Thứ không dễ biến mất chính là mô hình: mô hình toán học của miền nghiệp vụ, được xây dựng đúng đắn làm nền móng cho ứng dụng. Các thực thể, mối quan hệ, quy tắc và ràng buộc. Nó có thể không thay đổi về căn bản suốt hàng chục năm.

Một ví dụ đơn giản là kế toán. Ghi sổ kép, bên Nợ và bên Có, hệ thống tài khoản. Mô hình ấy có trước mọi chiếc máy tính. Trong thời gian đó, kế toán đã đi qua thẻ đục lỗ, máy tính lớn, phần mềm máy tính cá nhân, web và đám mây. Công nghệ thay đổi nhiều lần. Mô hình thì vẫn còn đó.

Viện sĩ Andrey Petrovich Ershov đã nói về điều này từ năm 1981 trong báo cáo “Lập trình — năng lực đọc viết thứ hai”. Ông viết rằng sách và máy tính đều là phương tiện mang mô hình thông tin của thế giới bên ngoài; nhu cầu hiện thực hóa mô hình ấy dưới dạng chương trình vừa đòi hỏi, vừa cho phép nâng cao đáng kể sức mạnh trí tuệ của nhân loại (A. P. Ershov, Bảo tàng Máy tính Ảo, tiếng Nga). Từ khóa ở đây là mô hình. Chương trình chỉ hiện thực hóa nó.

AI mang lại điều gì?

Giờ đây chúng ta có AI. Những trợ lý AI hiện đại — chẳng hạn Claude rất xuất sắc — nắm bắt công nghệ mới nhanh hơn bất kỳ ai trong chúng ta. Nâng dự án lên phiên bản framework mới, chuyển sang bộ công nghệ khác, dựng lại lớp vỏ — chúng làm những việc ấy rất sẵn lòng, trong vài giờ thay vì vài tháng.

Và đây là một ngã rẽ quan trọng.

Nếu nền móng là kiến trúc được mô tả rõ ràng và mô hình miền nghiệp vụ đúng đắn, việc chuyển từ công nghệ này sang công nghệ khác sẽ nhanh và đơn giản hơn bao giờ hết. AI dựa vào mô hình để chuyển nó sang nền tảng mới một cách cẩn thận. Đó mới là lợi ích thực sự.

Nếu không có mô hình, AI cũng sẽ vui vẻ mang mọi sai sót về khái niệm sang tất cả những công nghệ hiện đại. Nhanh chóng, tự tin và không hỏi thêm một câu nào. Sai lầm từng tồn tại trong hệ thống cũ giờ sẽ tồn tại trong hệ thống mới — chỉ là trông hiện đại hơn.

Có AI vẫn phải có nhật ký thay đổi

Từ đó có một kết luận thường bị bỏ quên: sự trợ giúp của AI không làm mất đi trách nhiệm của lập trình viên trong việc duy trì hai tài liệu cần thiết. Ngược lại, nó khiến chúng quan trọng hơn.

Thứ nhất là nhật ký thay đổi (changelog). Đã thay đổi gì, trong phiên bản nào, và vì sao. Khi AI viết mã, khối lượng thay đổi tăng lên nhiều lần. Không có nhật ký, một tháng sau sẽ chẳng ai — dù là con người hay chính AI — nói rõ được vì sao hệ thống lại có cấu trúc như hiện tại.

Thứ hai là bản tóm tắt dự án (project summary). Ngắn gọn: đây là hệ thống gì, mô hình của nó ra sao, ranh giới nằm ở đâu, những quyết định nào đã được đưa ra và vì sao. Đó là thứ lập trình viên mới đọc trong ngày đầu tiên. Và cũng là thứ cần đưa cho AI trước khi yêu cầu nó thay đổi điều gì. Không có mô tả ấy, nó sẽ tự suy diễn — dựa trên khuôn mẫu, chứ không phải miền nghiệp vụ của bạn.

Ở đây chẳng có gì mang tính cách mạng. Hệ thống thống nhất về tài liệu chương trình của Liên Xô (ЕСПД, ESPD), vẫn được sử dụng cho đến nay, từ năm 1980 đã yêu cầu việc sửa đổi tài liệu chương trình phải dựa trên thông báo thay đổi (GOST 19.603-78, Rosstandart, tiếng Nga). Cũng trong hệ thống đó, tài liệu “Mô tả chương trình” bao gồm mục đích, các giới hạn chức năng và mô tả cấu trúc logic (GOST 19.402-78, Rosstandart, tiếng Nga). Vẫn là nhật ký thay đổi và bản tóm tắt dự án, chỉ khác là trên giấy và có đóng dấu. Công cụ thay đổi. Ý nghĩa thì không.

Hãy tìm hiểu mô hình

Trong bài viết đầu tiên, tôi nhắc lại lối suy nghĩ thời sinh viên: hãy cho tôi một công cụ, tôi sẽ thay đổi cả thế giới.

Ngày nay, công cụ nhiều hơn bao giờ hết. AI sẽ khiến việc viết lại gần như miễn phí. Vì thế, câu hỏi không còn là dùng gì để viết. Câu hỏi là bạn đang viết cái gì.

Hãy tìm hiểu mô hình. Rồi hãy đi thay đổi thế giới.

  • Viết lại dự án
  • Kiến trúc phần mềm
  • Mô hình miền nghiệp vụ
  • Mã nguồn kế thừa
  • AI trong phát triển phần mềm
  • Nhật ký thay đổi
  • Bản tóm tắt dự án
  • ESPD
  • Ershov
Aleksandr Semiletov — Trưởng nhóm, phụ trách bộ phận phát triển phần mềm

Về tác giả: Aleksandr Semiletov

Trưởng nhóm, phụ trách bộ phận phát triển phần mềm

Hơn 20 năm kinh nghiệm phát triển phần mềm, tốt nghiệp Đại học Nghiên cứu Hạt nhân Quốc gia MEPhI. Phát triển full-stack — từ .NET/C# đến Angular và React. Chuyên về kiến trúc phần mềm, mô hình dữ liệu và các giải pháp AI. Xây dựng đội ngũ và quy trình phát triển phần mềm.

Bài viết được dịch từ bản gốc tiếng Nga của Aleksandr Semiletov.

Đọc bản gốc tiếng Nga →

Trao đổi chuyên môn và cộng tác bài viết: expert@a3imut.ru.