Code cũ càng để lâu càng trở nên tồi tệ hơn

Code cũ không giống như rượu vang. Nó sẽ trở nên tồi tệ hơn sau mỗi ngày bạn phớt lờ nó.

Tuần trước, tôi đã mất ba tiếng đồng hồ để gỡ lỗi một vấn đề lẽ ra chỉ mất 20 phút. Thủ phạm là một module xác thực (validation module) từ năm 2019. Mọi người cứ để mặc nó vì nghĩ rằng nó vẫn đang chạy ổn. Nhưng thực tế là nó không hề ổn. Tôi đã tìm thấy một dòng chú thích "TODO: refactor this" từ tận năm 2020.

Nhiều người coi code cũ như một khoản nợ không bắt buộc. Họ nghĩ rằng họ sẽ trả khoản nợ đó khi có thời gian. Code cũ hoạt động giống như nấm mốc. Nó lan rộng. Nó lây nhiễm sang mọi thứ xung quanh. Bạn càng chờ đợi lâu, chi phí để dọn dẹp càng trở nên đắt đỏ.

Chu kỳ này rất dễ đoán:

  • Bạn tiếp nhận một tính năng lộn xộn nhưng vẫn đang hoạt động.
  • Bạn thêm một câu lệnh "if" nữa để làm cho nó chạy được.
  • Sáu tháng sau, một người khác cũng làm điều tương tự.
  • Một năm sau, tệp tin đó dài tới 800 dòng và không có lấy một bài kiểm tra (test) nào.

Chi phí ẩn này tác động đến bạn theo ba cách:

  • Tốc độ giảm. Bạn dành nhiều thời gian để hiểu ngữ cảnh hơn là viết code.
  • Lỗi phát sinh nhiều hơn. Một bản sửa lỗi lại làm hỏng thứ khác vì logic bị rối rắm.
  • Việc tiếp nhận nhân sự mới (onboarding) thất bại. Các lập trình viên mới gặp khó khăn trong việc hiểu tại sao cùng một logic lại tồn tại ở bảy nơi khác nhau.

Hãy chú ý đến những dấu hiệu cảnh báo sau:

  • Những dòng chú thích vô dụng như "HACK: do not touch this."
  • Logic nghiệp vụ bị trùng lặp giữa các tệp tin khác nhau.
  • Các phụ thuộc vòng (circular dependencies) khi các dịch vụ phụ thuộc lẫn nhau.

Đừng viết lại toàn bộ mọi thứ. Việc viết lại hoàn toàn thường thất bại trong 80% trường hợp. Thay vào đó, hãy sử dụng phương pháp tái cấu trúc (refactoring) từng bước kết hợp với các bài kiểm tra đặc tính (characterization tests).

Hãy tuân theo quy trình này:

  • Ghi lại hành vi hiện tại bằng các bài kiểm tra, kể cả những phần kỳ lạ.
  • Tái cấu trúc mã nguồn mà không làm thay đổi hành vi đó.
  • Lặp lại cho đến khi mã nguồn có thể đọc hiểu được.
  • Chỉ thay đổi hành vi sau khi bạn đã có các bài kiểm tra thực thụ.

Các quy tắc cần tuân thủ:

  • Đừng bao giờ tái cấu trúc mà không có các bài kiểm tra.
  • Tránh các cải tiến làm thay đổi cách mã nguồn hoạt động. Một lỗi có thể lại là một tính năng mà khách hàng đang dựa vào.
  • Hãy để yên những đoạn code "yên tĩnh". Nếu một module không thay đổi trong ba năm và không gây ra vấn đề gì, đừng chạm vào nó.

Hãy tập trung năng lượng của bạn vào những đoạn code mà bạn thường xuyên chạm tới.

Nguồn: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h