𝗛𝗼𝘄 𝗪𝗲 𝗗𝗲𝗰𝗶𝗱𝗲 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗥𝗲𝗳𝗮𝗰𝘁𝗼𝗿 𝗮𝗻𝗱 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗥𝗲𝘄𝗿𝗶𝘁𝗲

Mọi lập trình viên đều từng đối mặt với khoảnh khắc này.

Mã nguồn chạy chậm. Việc thêm tính năng mất quá nhiều thời gian. Nhân viên mới gặp khó khăn trong việc hiểu hệ thống. Cuối cùng, ai đó sẽ đề xuất viết lại toàn bộ.

Nhóm thường chia thành hai phe. Một nhóm muốn bắt đầu lại từ đầu. Nhóm còn lại lo sợ thất bại từ những lần viết lại trong quá khứ. Cả hai bên đều có những lý lẽ xác đáng.

Viết lại không phải là một giải pháp thần kỳ. Nó thường mất nhiều thời gian hơn dự kiến. Bạn sẽ kết thúc bằng việc phải duy trì cả hai hệ thống cùng một lúc. Thậm chí, bạn có thể lặp lại chính những sai lầm cũ trong phiên bản mới.

Việc viết lại chỉ hợp lý trong các trường hợp cụ thể sau:

• Mô hình dữ liệu sai lệch hoàn toàn so với nhu cầu kinh doanh. • Công nghệ đã lỗi thời và không còn các bản cập nhật bảo mật. • Nhu cầu kinh doanh đã thay đổi quá nhiều khiến hệ thống ban đầu trở nên lạc hậu. • Không ai trong đội ngũ hiện tại hiểu cách hệ thống vận hành.

Ngay cả khi đó, đừng thực hiện thay thế kiểu "big bang". Hãy sử dụng mô hình "strangler fig". Hãy xây dựng hệ thống mới từng phần một song song với hệ thống cũ.

Phần lớn thời gian, thứ bạn thực sự cần là tái cấu trúc (refactor).

Tái cấu trúc là lựa chọn đúng đắn khi:

• Bạn vẫn có thể thêm tính năng, ngay cả khi việc đó diễn ra chậm chạp. • Đội ngũ vẫn hiểu mã nguồn hiện tại. • Sự hỗn loạn chỉ giới hạn trong các module cụ thể. • Doanh nghiệp không thể ngừng việc ra mắt các tính năng mới.

Trước khi lựa chọn, hãy tự hỏi tại sao mã nguồn lại trở nên tồi tệ.

Nếu vấn đề là nợ kỹ thuật (technical debt), hãy tái cấu trúc những phần tồi tệ nhất. Nếu vấn đề là do thiếu quy trình kiểm duyệt mã (code review) hoặc văn hóa làm việc kém, việc viết lại sẽ không giúp ích gì. Bạn sẽ chỉ tạo ra một mớ hỗn độn mới với những thói quen cũ mà thôi.

Hãy đặt ra những câu hỏi này trước khi quyết định:

• Liệu chúng ta có thể sửa chữa những phần tồi tệ nhất một cách độc lập không? • Mô hình dữ liệu có đang bị lỗi so với nhu cầu kinh doanh hiện tại không? • Chúng ta sẽ mất đi những kiến thức gì nếu bắt đầu lại từ đầu? • Doanh nghiệp có đủ sự ổn định để trải qua một quá trình chuyển đổi dài hạn không?

Bắt đầu lại thì cảm giác rất tuyệt. Nhưng hoàn thành việc viết lại mới là phần khó khăn. Phần lớn thời gian, một kế hoạch tái cấu trúc có cấu trúc sẽ an toàn và hiệu quả hơn.

Nguồn: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk