# 74: Con đường cải tiến hiệu năng đầy bom do code bẩn
Thông thường việc cải tiến hiệu năng của hệ thống bao giờ cũng yêu cầu bạn phải thay thế code cũ. Mỗi khi chúng ta muốn code, từng đoạn code mà chúng quá phức tạp hoặc rối rắm sẽ giống như những quả code bom bẩn nằm đó chờ đợi để ngăn cản mọi sự nỗ lực của bạn. Và điều đầu tiên mà bạn gặp đó chính là rắc rối với code bẩn. Nếu mục đích của bạn chính là khiến nó trở nên mượt mà hơn thì chúng ta có thể dễ dàng dự đoán được thời gian kết thúc. Tuy nhiên, khi chúng ta phải đối diện với những đoạn code bẩn không ngoài dự đoán sẽ khiến cho công việc ấy trở nên khó khăn hơn trong việc dự đoán chính xác thời gian kết thúc công việc.
Xét trường hợp bạn tìm thấy một thực thi nóng. Hành động bình thường chính là làm giảm sức mạnh của thuật toán của nó. Giả sử bạn bảo với quản lý của bạn là bạn cần khoảng 3–4 giờ để làm điều đó. Và khi bạn thực hiện điều đó, bạn nhanh chóng nhận ra bạn đã làm hỏng phần bị phụ thuộc. Và những thứ liên quan với nhau được phải được gắn kết với nhau, sự hỏng hóc này là điều có thể dự đoán và lo liệu được. Nhưng chuyện gì sẽ xảy ra nếu như sửa chữa kết quả phụ thuộc ấy trong những thành phần bị phụ thuộc khác đang bị hỏng? Hơn nữa, vấn đề trên cần phải khắc phục từ nguồn, bạn càng không tìm được nguồn gốc của nó thì sự dự đoán của bạn ngày càng trở nên không chính xác. Và rồi tất cả dự đoán của bạn từ 3–4 giờ bỗng tăng lên thành 3–4 tuần. Thông thường sự tăng trưởng không dự đoán trước về thời gian trong kế hoạch của bạn là 2–3 ngày tại một thời điểm. Thật dễ dàng để thấy sự sửa chữa “nhanh” này đột nhiên tốn đến vài tháng để hoàn thành. Những trường hợp như thế này gây thiệt hại nặng nề đến sự tín nhiệm cũng như là thể diện chung của team chịu trách nhiệm. Phải chi chúng ta có một công cụ giúp chúng ta xác định và đo lường khả năng này.
Thật ra chúng ta có nhiều cách để xác định, điều khiển mức độ cũng như chiều sâu của các liên kết và độ phức tạp code. Software metrics có thể được dùng để đến sự xuất hiện của các tính năng đặc biệt. Giá trị của các phép đo này tương tự với chất lượng của code. Hai giá trị trong metrics đếm sự liên kết là fan-in và fan-out.
Xét giá trị fan-out cho các class: nó được định nghĩa là số lượng các class là tham chiếu trực tiếp hoặc gián tiếp từ một class mà chúng ta xét. Bạn có thể xem nó như số lượng của tất cả các class cần phải được compile trước khi class bạn đang xét compile. Fan-in, mặt khác, là số lượng các lớp phụ thuộc vào lớp đang xét.
Dựa vào giá trị fan-in, fan-out ta có thể tính toán được nhân tố bất ổn bằng công thức:
I = fo / (fi+fo)
Khi mà I tiến đến 0 thì gói chức năng ta đang xét càng ổn định (stable) và càng bất ổn(instable) khi I tiến đến 1. Theo dữ kiện điều tra, các gói tính năng ổn định hầu như không chứa code bẩn và ngược lại. Mục đích trong việc sửa chữa chúng chính là khiến cho trị số I càng gần 0 càng tốt.
Khi sử dụng metrics chúng ta phải luôn nhớ rằng chúng chỉ là những quy tắc của ngón tay. Về mặt thuần toán học chúng ta có thể thấy gia tăng fi mà không thay đổi fo sẽ khiến cho I gần 0 hơn. Tuy nhiên, mặt trái của việc giá trị fan-in quá lớn sẽ khiến cho những lớp đó trở nên khó để thay đổi mà không làm hỏng sự phụ thuộc của chúng. Đồng thời việc không tác động đến fan-out, bạn thật sự không làm giảm nguy cơ ấy cho nên hay cố gắng cân bằng chúng.
Một mặt tối của việc sử dụng metrics chính là một mảng số khổng lồ do công cụ metrics sinh ra có thể là trở ngại đối với người mới. Họ nói, software metrics có thể là một công cụ mạnh mẽ trong công cuộc đấu tranh vì code sạch (clean code). Chúng có thể giúp ta xác định mà dự đoán bom code bẩn trước khi chúng trở thành mối nguy hại nghiêm trọng trong việc luyện tập hiệu chỉnh hiệu suất.